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 06/12/2013 03:21 PM, Michael StJohns wrote:
On 6/12/2013 5:24 PM, Robert Relyea wrote:
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.

You know - I do remember this section, but I missed it when reviewing Doran's document because it's in the mechanisms section rather than the base section.  (Why??). 

Note that there are issues with wrapping certain sub types of keys (e.g. the RSA private key that doesn't store all the possible CRT data).  Should that be addressed or just mentioned as an exception? 

So I think the current PKCS #1 spec (referenced by the PKCS #8 spec) does not make the CRT values optional. That being said, you can recalculate (at some expense) all the CRT values as long as you have both exponents and the modulus. The question is who would be responsible for doing it (the module that is doing the wrap or the module that is doing the unwrap unwrap). Doing the former maintains compatibility with all existing uses (including non-PKCS #11 software). Doing the latter saves effort if both tokens don't support storing CRT values.

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.)

Yeah - mostly the wrap/unwrap stuff for symmetric keys was all about external protocols.  They needed to wrap a key for transit to someone who knew exactly what they were getting.  E.g. a raw wrapping.   For things like token to other vendor's token, it would be useful to have some sort of a structured wrapper with useful attributes I think.

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.

Maybe.  It's possible that we just do a raw wrap on the bits of the underlying key material, but that raises my security hackles.  I'd *really* like to know that a set of bits are associated with AES and not a generic HMAC key for example.  TBD.

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.

Yeah - I'm confused as well.    :-)

I think the simplest (maybe not the most correct) way of resolving this is to delete the OID arc stuff and sticking a symmetric key in a PKCS8 wrapper.  

Thanks for reminding me of this.  Too many crevices in this document.


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

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