Subject: RE: [pkcs11] Key Import proposal update
Sorry for the delay . Some clarifications below
Sent: Wednesday, May 29, 2013 3:50 PM
To: 'Cohen, Doron'
Subject: RE: [pkcs11] Key Import proposal update
>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?
[Doron Cohen] While encoding the OAEP parameters in the wrapped result is possible - but I prefer to avoid it. The main motivation was to keep
the wrapped result simple and there are a bunch of issues around integrity and data encoding that we should avoid . I also believe Keeping the
OAEP parameters as part of the parameters also keeps it more consistent with the rest of the specification
> 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.
[Doron Cohen] I agree, error should be thrown . Any ambiguity may lead to security weakness/exploit
> 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?
[Doron Cohen] Point taken . I agree, there should be a unique error to indicate the error is in the in unwrapping the transient AES key rather than the
>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).
[Doron Cohen] Makes sense .
>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?
[Doron Cohen] I wanted to get our cryptographer comment on that point and his view is this is fine cryptographically – “ There is a proof that
if you use a CCA-secure scheme for RSA to encrypt a symmetric key, and then a CCA-secure symmetric scheme to encrypt the message (in our
case another key) then the result is CCA secure. (CCA security means "chosen-ciphertext security" and it guarantees security against padding
oracle attacks.)” . So it looks like we should be fine .
> 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?
[Doron Cohen] I agree this should be a separate thread. I am ok with adapting the encoding recommendation in this proposal to whatever is agreed
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.