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] Groups - Proposal for Secure Key Import using an RSA key uploaded

On 05/30/2013 08:31 AM, Michael StJohns wrote:
On 5/29/2013 4:39 PM, Tim Hudson wrote:

These are the two sections I find somewhat strange within the proposal - raised on the call.

The recommended format for an asymmetric target key being wrapped is as a PKCS8 PrivateKeyInfoThe recommended format for a symmetric target key being wrapped is also as a PKCS8 PrivateKeyInfo, where the PrivateKey OCTET STRING is the secret target key's data. 


The use of Attributes in the PrivateKeyInfo structure  is OPTIONAL. 


The OBJECT IDENTIFIER arc { oasis pkcs11 attributes } is reserved to identify PKCS11 attributes encoded as PKCS8 Attribute objects.  The last component of such OID shall be the same as the value assigned to the corresponding CKA_ enumeraton.  I.e. the OBJECT IDENTIFIER for CKA_ENCRYPT is { oasis pkc11 attributes CKA_ENCRYPT (260) }.  It is recommended that only BOOLEAN attributes be included in the Attributes field of PrivateKeyInfo.

One of my peeves with C_WrapKey and the wrapping mechanisms currently specified is that they specify neither what part of the key info gets wrapped, nor the format for the data to be wrapped.  That means that C_Wrap/Unwrap are mostly only useful between two HSMs of the same manufacturer (and sometimes not even then).

Wrapping of private keys are specified generically in Section 12.6 "Wrapping/Unwrapping Private Keys" (version 3.20, section 12.11 in PKCS #11 3.11, section 6.5 in PKCS #11 Mechanisms 2.30 draft 7). They are wrapped in PKCS #8. NSS depends on this because it puts the resulting wrapped key directly into a PKCS #12 bag.

The above statement on what gets wrapped for this mechanism means that everyone who implements it knows exactly what they're getting when the data is unwrapped, and that the data is explicitly tagged with typing information (e.g. its an RSA key, its an EC key on the P256 curve).  Since there wasn't actually a standard form for a Secret Key, I could have either made one up (a SEQUENCE of an OID and an OCTET STRING, where the OID types the key data in the octet string), but it made sense just to throw it in the same type of key structure as the private key.  Since the structure of the OCTET STRING in the PrivateKeyInfo is dependent on the OID in that structure, all you really need is that statement of format that I included.

Symmetric Keys aren't very well defined, mostly because when we first did the spec we thought it was obvious that symmetric keys were just bits. If you actually wrapped the symmetric key in something, you'd likely break NSS, which (again) would just stuff the resultant wrapped key in whatever protocol it's using (SSL, S/MIME, etc.)

Now this wrapping mechanism is different from the other ones we typically use. The other wrapping mechanisms are simply encryption/decryption mechanisms forced into service to wrap the keys. In this case you are defining a mechanism that includes more data than just the key, so of course you will need to define how that data is stored.

For the OID arc - the private key info structure provides space for ASN1 Attributes.  I noted that the use of them was optional, but if used, I wanted to make sure it was something that could easily be decoded by a receiver.  If this seems too weird, we can change the OPTIONAL to PROHIBITED, but ignored on input.

So it may look strange, but it's addressing the shortfalls in the specs for C_WrapKey and C_UnwrapKey in a way that will allow you to wrap a key on an HSM from manufacturer A and unwrap on an HSM from manufacturer B and actually work.

So I'm still confused, because I thought it was pretty well defined (though not under each mechanism). I agree your new mechanism should specify what the wrapping value is.



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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