Subject: [cicm] Key Metadata and Fill Events

From: "Novikov, Lev" <[email-masked]>
Date: Thu, 20 Jan 2011 14:05:28 -0500

As I mentioned last week, a few issues have come up as part of the last review of the document. Here's one:

Imagine a scenario where we need to apply metadata to keys after they are filled into a cryptographic module.

The CICM::AsymKeyManager::get_key_last_filled() and CICM::SymKeyManager::get_key_last_filled() methods provide reference the most recently filled key. 
See: http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-4.1.2 
 and http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-5.1.2

However, these methods are expecting a key of known type (Sym or Asym). How do you know which key was filled last? Moreover, what if several keys were filled of both types? How can you access them to apply the appropriate metadata?

One possible solution is to extend the module events. Currently, we have three module events related to key fill: 
 - C_MODULE_KEY_FILL_CONNECTED, 
 - C_MODULE_KEY_FILL_INITIATED, and 
 - C_MODULE_KEY_FILL_COMPLETE. 
See: http://tools.ietf.org/html/draft-lanz-cicm-mm-00#section-9.2.1

In theory, there could be a vendor-supplied parameter to the C_MODULE_KEY_FILL_COMPLETE event that would indicate the type of key that was loaded. However, we propose that two additional module events be added: 
 - C_MODULE_KEY_FILL_COMPLETE_SYM and 
 - C_MODULE_KEY_FILL_COMPLETE_ASYM.

These "KEY_FILL_COMPLETE" events would indicate that one or more keys of the specified type was loaded. When the event is called, the client program would then be able to use the appropriate iterator (SymKeyIterator or AsymKeyIterator) to enumerate all of the keys on the module and determine which keys are new.
See: http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-4.3
 and http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-5.3

The disadvantages of this approach is that the ::get_key_last_filled() methods only work when there's a single key filled and the onus on detecting which keys are new is pushed off to the client program.

The advantages are that the CICM driver can choose to fire these events after each key is filled (e.g., when using sporadic, network-based keying) OR after a large batch of keys are filled (e.g., when using a fill device).

* What are other advantages / disadvantages to this approach?
* Are there better approaches?

Lev