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:
X-NONE
X-NONE
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?
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.
Mike
