Seal key/CKA_GLOBAL - maybe another approach.

[Michael StJohns <msj@nthpermutation.com>]

After having the two ballots defeated for the above objects, and after 
thinking about other approaches to control the wrapping of key material, 
I started looking at alternate approaches.

The general goal I have is to control the export of certain keys so they 
can only exported under certain circumstances in a controlled manner, 
they can only be restored to the same token, and the restoration of the 
key results in a key that's identical to the wrapped key with the only 
exception being the handle.

After worrying the problem a bit more, I stepped back from the last two 
and re-looked at "exported under certain circumstances".  The current 
key wrapping approach is tied to the CKA_TRUSTED, CKA_WRAP_WITH_TRUSTED, 
CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE attributes.    E.g. if the key 
to be wrapped has CKA_WRAP_WITH_TRUSTED, then the wrapping key needs to 
have CKA_TRUSTED=true and the wrapping key can only wrap keys where its 
CKA_WRAP_TEMPLATE "matches" the key to be wrapped.


What I want to be able to do is create a symmetric key as a 
CKA_LOCAL=true,  CKA_WRAP/CKA_UNWRAP=true, CKA_EXTRACTABLE=false plus a 
few more attributes and then make sure that other keys can only be 
exported by this key.  There are a number of problems with using 
CKA_WRAP_WITH_TRUSTED to do this - not the least of which is that it's 
pretty difficult for a non-SO to mark a symmetric key trusted, and for 
an SO to mark a CKA_PRIVATE=true symmetric key trusted.


So let's concentrate first and only on specifying which key is allowed 
to wrap which other key.  Let's throw away CKA_WRAP_WITH_TRUSTED and 
CKA_WRAP_TEMPLATE as the mechanisms for giving permission for a key to 
be wrapped.

First, let's define an attribute CKA_PERSISTENT_HANDLE.  This is a 8-16 
byte octet string (UUID) that is unique to a storage object. It changes 
anytime any of the attributes change.  It can't be used in place of 
hHandle in various calls, but it can be used in C_FindObject to find 
that object even across session boundaries (for token objects).  This is 
on all objects, but is important here for the next attribute.

The second attribute we define is CKA_WRAPPER_PERSISTENT_HANDLE. This is 
also a byte octet string of the same length as above.  It can be set 
during object creation to indicate the ONLY key wrapping key allowed to 
wrap this key.  If this is present, CKA_WRAP_WITH_TRUSTED cannot be.   
When used with C_WrapKey, if this attribute is on the key to be wrapped 
and does not match the value of the CKA_PERSISTENT_HANDLE of the key 
doing the wrapping, then the wrapping fails.

A possible usage scenario:

Create 2 persistent wrapping keys on the token, one with 
CKA_DESTROYABLE=true and one with CKA_DESTROYABLE=false.  (This 
represents one wrapping key used for the lifetime of the token, and 
another that can be destroyed and replaced, but is persistent unless 
destroyed. The first key is used for keys that you want to be around in 
wrapped form as long as the token is initialized.  The second key is 
used for keys that need to persist between sessions, but that you might 
want to zeroize say after a month - you might have a few of these).

Create a third wrapping key that is a session key.  This is used to 
extend key storage for a single session.

Grab the CKA_PERSISTENT_HANDLE from each of these and remember it in 
your application.  Make sure the key attributes on those keys match the 
policy attributes you care about (e.g. only does a single key wrap 
mechanism of a strong type, only does key wrap, is a local etc).

If you need additional key storage for a key, you can set 
CKA_WRAPPER_PERSISTENT_HANDLE to one of those values as part of the key 
creation mechanism, and then wrap the key to your heart's content.

If you want to, compare this to CKA_WRAP_WITH_TRUSTED and 
CKA_WRAP_TEMPLATE as the difference between role based authorization and 
identity based authorization.


______________________________________
There's more language around this in C_WrapKey, but basically this 
covers the authorization thing and is separable from CKM_SEAL_KEY.

CKM_SEAL_KEY then becomes simply a specification of a mechanism that as 
part of the wrapping/unwrapping mechanism includes the attributes of the 
keys.  The authorization model no longer talks about seal keys with 
special powers, but just uses the stuff above.

The mechanism MIGHT allow special settings for the CKA_ALWAYS_SENSITIVE 
and CKA_NEVER_EXTRACTABLE on an unwrapped key depending on specific 
values of the wrapping key - based on the values of CKA_LOCAL and 
CKA_EXTRACTABLE in the wrapping key.  That's assuming the mechanism DOES 
restore the key to the identical state to which it was prior to wrapping.