Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

[Michael StJohns <msj@nthpermutation.com>]

On 6/5/2013 8:31 PM, Tim Hudson wrote:

Why do you have "

all pertinent key attributes" in the seal-key document? It needs to be all attributes with no exceptions to be useful IMHO if the intent is off-device storage that is application managed.

Actually, no.  I stated it this way because occasionally, some of the attributes are redundant to others, or aren't actually stored internally as PKCS11 attributes.  This was an attempt to not specify implementation.  Also, "pertinent" here means the attributes that are specific to that type of object (e.g. CKA_PUBLIC_MODULUS is not a pertinent attribute for an EC private key).

Why limit sealing to a SECRET_KEY only? Why a symmetric approach only?
Why not define an actual output format? A requirement to protect the integrity of the attributes?
You have done that for the certify output - in the global values proposal - why not for seal

Because the certify may need to verified by something besides the originating device, but the seal is designed specifically to prevent that key from being loaded on any token other than the token from which it was sealed.  Really and truly the definition of an OPAQUE object.

If there was an interop issue, I'd have defined a format.  There isn't.

As for why secret key only - again - this is designed specifically to allow an export of key material from a device and reimport to that self-same device.  I can think of no case in which having the wrapping key be an asymmetric key is useful in that scenario.    Would you care to suggest one?

With respect to the protection of the integrity of the attributes - it is necessary.   But that's sort of implicit in the statement:

The unwrap operation reverses the wrap operation and MUST produce exactly the same object as was wrapped.

But I can be more explicit here if necessary.  I *really* don't care how they do this - could be an embedded SHA, could be an integrity protected wrap algorithm, could be a combination of an encryption mode and an integrity mode.  It really is a don't care for the purposes of the spec. 

This does not however solve the export-from-one-device, import-to-another-device context which is the other problem that these proposals I think are not discussing.

At this point I'm confused about which proposals you're reading.  This proposal is ONLY to deal with the ability to import and export data that otherwise couldn't be imported or exported from the token.  The data CANNOT be re-imported to a token other than the originating token and that is by design (and the main point of the design).

What you want to do is supported for all CKA_EXTRACTABLE=true objects for all other key wrapping mechanisms.

As for your proposal - please write it up and I'll give it the same review treatment you're giving mine.  I don't actually think it will accomplish what I want to accomplish, but you haven't provided enough rigorous detail for me to make a reasonable determination either way.



Mike