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