FW: [pkcs11] Key Import proposal update

["Burns, Robert" <Robert.Burns@thalesesec.com>]

Sorry, I forgot to do a 'reply-to-all' on this one and it just went back to Doron.

Bob

-----Original Message-----
From: Robert.Burns@thalesesec.com 
Sent: Wednesday, May 29, 2013 3:50 PM
To: 'Cohen, Doron'
Subject: RE: [pkcs11] Key Import proposal update

Doron,

I like the proposal and just have a couple of questions/comments:

1) At the risk of overcomplicating things, should we be also adding the OAEP parameters encoded in the wrapped result?  It would certainly make things easier on the receiver of the key blob, but at the risk of complexity in the encoding of the data, as well as potentially requiring an authentication (MAC) over the encoded data, which doesn't have a real easy/clean solution on first blush.  But just curious about this one as other standards (such as CMS) do encode the OAEP parameters as part of their 'envelopes', so not sure what would be the best option for this solution.  Was this considered?

2) What should be the technique for disambiguating the case where the caller to C_UnwrapKey() provides an object attribute template, and the encrypted key contains Attributes in the PrivateKeyInfo structure?  My opinion is that an error should be thrown and allow the caller decide what to do, but that's a bit complicated because the caller then has no idea what the actual attributes might be, because they are encrypted.

3) Given that there are now 3 keys involved in unwrapping, (instead of two), is there any need/desire to deal with the ambiguities in the return codes; meaning, some error codes refer to the wrapping key, and others to the wrapped key -- in this case, we have one unambiguous unwrapping key (the RSA private key), one unambiguous unwrapped key (the object in the PrivateKeyInfo struct), but then one very confusing AES key which is both an unwrapping key, and an unwrapped key?  Seems like errors in unwrapping these objects might result in confusing messages.  For example, if I try to unwrap one of these keys and get a CKR_WRAPPED_KEY_INVALID, what does it indicate?  That my RSA wrapped key was bad (let's say a transmission error?) or that my key I really want unwrapped is bad somehow?

4) Just to conform to other parts of the spec, we should probably refer to the PrivateKeyInfo structures consistently to avoid ambiguities, (e.g. "For wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type." -- see Section 12.6 for examples).

5) Finally, I do like the security attributes of using RSA PKCS OAEP for wrapping an AES key, and then the AES_KEY_WRAP_PAD for using the AES key for transport, but something is bugging me, although I can't put my finger on something specific.  And that is the fact that there is no explicit cryptographic binding between the OAEP wrapped key and the AES wrapped key.  Sure, there is an implicit link in that the OAEP and AES Key Wrap have intrinsic 'MAC's built-in, but it just *feels* like the lack of an explicit link between the two makes it somehow 'less strong'.  Again, not saying it is bad, just that it *feels* like we're leaving ourselves exposed here.  Anyone else have an opinion on this?

Finally, I hate to beat this drum again, but this solution is of course relying upon DER/BER encoding -- perhaps this is a discussion for a separate thread, but perhaps we should be considering alternative encoding methods which are easier to document and implement?

Thanks,

Bob

> -----Original Message-----
> From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] 
> On Behalf Of Cohen, Doron
> Sent: Tuesday, May 28, 2013 5:38 AM
> To: pkcs11@lists.oasis-open.org
> Subject: [pkcs11] Key Import proposal update
> 
> I am attaching two documents with the new mechanisms proposal for the 
> secure key import .
> 
> The first is an updated description for key import using an RSA key . 
> This copy only includes minor and typo  fixes - it updates the 
> unwrapping description to indicate the use of CKM_AES_KEY_WRAP_PAD  
> (rather than
> CKM_AES_KEY_WRAP) .
> 
> The second is a first cut of the ECC variant  .
> 
> Doron
> 
> 
> -----Original Message-----
> From: Cohen, Doron
> Sent: Monday, May 20, 2013 3:46 PM
> To: 'pkcs11@lists.oasis-open.org'
> Subject: RE: [pkcs11] RSA Key Import proposal
> 
> Here is an update to the proposal  taking into account additional 
> input from Mike .
> 
> Doron
> 
> 
> -----Original Message-----
> From: Cohen, Doron
> Sent: Thursday, May 09, 2013 11:28 AM
> To: pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] RSA Key Import proposal
> 
> On 4/2/2013 7:12 PM, StJohns, Michael wrote:
> >
> >If you're worried about misuse of the AES key, then instead, how 
> >about
> defining a mechanism - CKM_RSA_AES_KEYWRAP?   This defines a
> mechanism
> >which first unwraps the AES key using RSA, and then uses the AES key 
> >wrap mechanism to unwrap the actual data?  The AES key gets implicit 
> >attributes  (and actually never gets a public handle) when unwrapped, 
> >and
> goes away once the other key is unwrapped.  The template on the 
> original RSA private key applies to the finally unwrapped new RSA private key.
> >
> >On the wrapping side, the AES key is generated internally, wraps the 
> >data, is
> encrypted under the RSA public key, and then zeroized.
> >
> >For an elliptic curve equivalent you probably need something like
> CKM_ECIES_AES_KEYWRAP.
> 
> Attached is the first draft of the proposed mechanism for secure key 
> import using an RSA key.
> Assuming this is acceptable, I will provide the elliptic curve 
> equivalent so both merged with the 2.4 new mechanisms document .
> 
> 
> Doron
> 
> 
> 
> 
> 
> The information contained in this electronic mail transmission may be 
> privileged and confidential, and therefore, protected from disclosure. 
> If you have received this communication in error, please notify us 
> immediately by replying to this message and deleting it from your 
> computer without copying or disclosing it.
>