[Opendnssec-develop] (long) My personal thoughts about identifiers, attributes and formats.
roy at nominet.org.uk
Thu Mar 12 13:43:53 UTC 2009
To help the discussion surrounding the identification of objects in a
pkcs11 enabled environment, I have put my thoughts here. Please skip the
blurb below to the "QUESTIONS" section if you do not wish to submerge into
the boring material.
(1) Unique Identifiers
All key-pairs should be uniquely identifiable. They need to be unique, as
Jakob and John tell me, across "time and space". Though I found this
argument too strong before, I have reconsidered this thought. Unique
across time essentially means that key identifiers must be unique over
time. This restriction is important, since a key generator might not have
knowledge of prior generation of keys. Unique across space essentially
means that key identifiers must be unique in the presence of multiple
storage environments. This restriction is important, since a key generator
might not have knowledge of all available key storage.
The scenario that convinced me is that an organisation might migrate
storage of keys from a special purpose HSM to a general purpose HSM. That
is, an organisation might already have an HSM for SSL termination and/or
acceleration, and wants to use it to store DNSSEC related objects. Though
we might highly recommend a separate "security world", slot, keystore or
what not, for DNSSEC, the reality is, that the general HSM has objects
that should not confuse OpenDNSSEC, and OpenDNSSEC related objects should
not confuse existing applications (users).
Also, since key-generation and key-using events are unrelated (apart from
the order ;-) ). I can generate a key on HSM x, for zone y, but when
actually continuously signing records in bulk, for various zones, there
might be more than one HSM present.
UUID's satisfy this requirement, and I'm not unwilling to use it for this
purpose, so lets have a look:
(2) The source of identifier
UUID's are of fixed length (128 bits), and are not extendable. I'm sure
128 bits is more than enough. Then there is the question of how to
determine (or calculate) UUID's, and there is some guidance in rfc 4412 on
this. There are 5 defined ways of 'sourcing' uuids. There can be more but
have not been defined. There is no IANA registry for UUID versions, nor is
there a designated template for defining new versions.
I also like the UUID itself to be completely independent of the content of
the object. This avoids that an object is generated, and then need to be
re-read to determine an UUID. So, as a source for the UUID, I think that a
prng would do. The obvious choice is then version 4. Version 5 doesn't add
anything, as it would only hash the random number, ergo, if the random
number generator is not actually random enough, than hashing it won't make
it more random. This also avoid dependency on a hash algorithm and the
subsequent crypto grandstanding around it.
(3) Which attribute to use.
We still have to determine which pkcs11 object attribute (CKA_bladibla) we
will use to store the identifier.
The CKA_LABEL attribute is common across all objects of the storage class.
This storage class is inherited by the key class. The CKA_ID attribute
belongs to the KEY object class. PKCS11 generalizes between KEY and
CERTIFICATE classes. To clarify, the KEY object class refers to the
CERTIFICATE class when discussing CKA_ID usage. I've quoted the specific
On CKA_LABEL usage:
a) 10.4 Storage objects
The CKA_LABEL attribute is intended to assist users in browsing.
On CKA_ID usage:
b) 10.7.2 Overview (10.7 Key objects)
The CKA_ID field is intended to distinguish among multiple keys. In the
case of public and private keys, this field assists in handling multiple
keys held by the same subject; the key identifier for a public key and its
corresponding private key should be the same. The key identifier should
also be the same as for the corresponding certificate, if one exists.
Cryptoki does not enforce these associations, however. (See Section 10.6
for further commentary.)
subsequently (since the previous quote refers to Section 10.6 for further
c) 10.6.3 X.509 public key certificate objects
The CKA_ID attribute is intended as a means of distinguishing multiple
public-key/private-key pairs held by the same subject (whether stored in
the same token or not). (Since the keys are distinguished by subject name
as well as identifier, it is possible that keys for different subjects may
have the same CKA_ID value without introducing any ambiguity.)
The term "browsing" (from 'assist users in browsing') is undefined, but it
implies that it can be used by a user (application) to distinguish an
object when more than one is present. I would recommend against using a
combination of both. As for as formatting goes, CKA_LABEL is UTF-8 encoded
unicode, while the CKA_ID is an array of bytes, both do not restrict
usage. It seems that CKA_LABEL is persistent across all storage objects.
When I look at practises in other applications, it seems that CKA_ID is
used to tie key (objects) to certificate (objects). The quoted text seems
to substantiate that thought.
(4) Storage format.
Lastly, we have to determine if we store the source of the UUID, or the
UUID itself. My personal preference is to store the UUID itself. If we
only store the 128 bit value, we require all encompassing software that
relates the object identifier to a value to translate the identifier to
UUID and back. The UUID is then solely a presentation format.
After extensive sieving through the spec, I have the following questions:
(1) Can I use UUID as an identification format.
(2) Can I use UUID version 4 (random numbers) as the source.
(3) Can I use the CKA_LABEL attribute to store the identifier.
(4) Can I store the UUID string without special formatting.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Opendnssec-develop