[Opendnssec-develop] (long) My personal thoughts about identifiers, attributes and formats.

[Roy Arends]

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 
sections below:

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 
commentary):
 
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:

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.

Thanks,

Regards,

Roy Arends
Sr. Researcher
Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090312/4493abb0/attachment.htm>