On 06/12/2013 02:44 PM, Tim Hudson
wrote:
On 13/06/2013 7:24 AM, Robert Relyea wrote:
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.
And what will NSS do if it gets a PKCS#8 with a set of attributes
contained in it which reference an unknown OID arc?
Short answer: pass it to the token to unwrap;).
Longer answer: Softoken parses the attributes and discards them, so
the rest of the key would import. Of course you would get this if
you wrap using Mike's mechanism, then try to unwrap using
CKM_AES_CBC_PAD, since softoken doesn't support Mike's new proposed
mechanism.
Without defining a way to carry the attributes between tokens the
wrapping mechanism is not going to achieve what MikeS is looking
for as I understand it - which is cross-vendor export and import
of keys retaining their PKCS#11 attributes.
Right, but it's a new mechanism so we don't actually have
compatibility issues, unless we are talking about stuffing the
result back into a PKCS #12 bag. I don't know if any other software
is using attributes. It may be if we use PKCS #8 attributes we would
have something that could be used in PKCS #12 as well (just not with
the guarrentees that the attributes would be properly set when the
key is imported.
This is basically two proposals wrapped into one:
- wrap using a temporary AES key saving some steps in what can
already be done
- carry the PKCS11 attributes across in the wrapped format
Tim.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
