OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CKM_SEAL_KEY


Thanks Michael.

You are suggesting this usage:

rv = C_UnwrapKey(
hSession,
CKM_SEAL_KEY,
hUnwrappingKey,
pWrappedKey,
ulWrappedKeyLen,
NULL_PTR, /* pTemplate */
0, /* ulAttributeCount */
&hKey /* handle to the unwrapped key blob */
);

And, any application calling this function with CKA_SEAL_KEY should NOT receive error codes such as:
CKR_ARGUMENTS_BAD
CKR_TEMPLATE_INCOMPLETE,
CKR_TEMPLATE_INCONSISTENT
?

If that's the case, I think the above will work!

------------------------------------------------------------------------------------------------------------------
But, say, once we call C_Finalize, and how do we C_FindObjects of that hKey later ?




Best,
Oscar












On 07/ 2/13 08:47 AM, Michael StJohns wrote:
On 7/2/2013 2:25 AM, Oscar So wrote:
Michael,

For your proposal on CKM_SEAL_KEY, at the 9th paragraph you wrote:
"When this mechanism is used with C_UnwrapKey, ulAttributeCount should be 0."

Could you explain more about this ?
Why does it have to be zero ?

Thanks,
Oscar

Hi Oscar -

The general contract of this mechanism is that what is wrapped is the internal, vendor-specific data related to the object being wrapped and that you get exactly the same thing back when you do the unwrap operation. E.g. if K is all the data that describes a key in a vendor specific way then the following is true for this mechanism:

K' == unwrap(wrap(K)) == K

where K' is the unwrapped key. K is indistinguishable from K' (key data, attributes etc) except for the handle of the key.


Normally with a C_UnwrapKey the template provides all (or most of) the information about the key material you're unwrapping, possibly along with the CKA_UNWRAP_TEMPLATE on the unwrapping key. In the case of a private key some attributes (should) get set from the PKCS8 structure that contains the private key. So you possibly have three different sources for any given attribute. AND you have to get the combination of attributes correct for any given wrapped key blob.

For this mechanism, the only source of attributes is the opaque blob that you wrapped. You don't need to specify any attributes on unwrapping because the blob carries all the information necessary regardless of the underlying type of the key or object. I briefly considered allowing mix-ins for other attributes (via the C_UnwrapKey call and via a CKA_UNWRAP_TEMPLATE on the unwrapping key), but came to the conclusion that it would violate the general goal of the mechanism and possibly provide some paths to manipulate the policy markers associated with PKCS11.

Is there a use case you can think of where having attributes mixed in on unwrap makes sense and doesn't weaken the security goals?

Mike




--

Best,
Oscar



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]