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

Roy Arends roy at nominet.org.uk
Thu Mar 12 14:43:17 UTC 2009

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 03/12/2009 
03:12:36 PM:

> Hi Roy,
> > 
> > (3) Can I use the CKA_LABEL attribute to store the identifier.
> What other objects do you think you will be storing on the HSM other
> than keys? If all you are using is keys, then I would suggest that you
> used CKA_ID for machine readable identifiers (e.g. UUIDs) and CKA_LABEL
> for human readable identifiers (a descriptive string "Private KSK for
> zone ladila.org").

It seems that CKA_ID is used to tie a key object to a certificate object. 
In short, you'd identify a certificate first, by using CKA_SUBJECT, and 
then you use CKA_ID of the certificate object find the associated key 
object. This is exactly why most applications use the modulus as an 
identifier in CKA_ID, as it is persistent among the two objects. Though in 
essence, you could use CKA_ID, but it seems that CKA_LABEL is the defacto 
method of identifying an object. I say defacto, because pkcs11 goes out of 
its way to have a single identifier or method to identify keys. 

To answer your question though, I do not foresee the OpenDNSSEC project to 
store anything other than keys in an HSM, though the HSM might have other 
users as well.
> > (4) Can I store the UUID string without special formatting.
> CKA_LABEL uses UTF8 encoding, which means that you cannot store
> arbitrary byte values without breaking the encoding (values above 127
> (0x7F) have a special meaning); I would therefore suggest that you use a
> hexadecimal string representation of the UUID according to the commonly
> used formatting (fields separated by dashes: abcd-1234-56a... etc)

I meant using the UUID string (like 
"e62d9060-0f11-11de-8b30-0002a5d5c51b") in the CKA_LABEL, instead of using 
any other special formatting.


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

More information about the Opendnssec-develop mailing list