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.
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.)
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.
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.
bob
Mike
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
