<font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">(1) Unique Identifiers</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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). </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">UUID's satisfy this requirement, and
I'm not unwilling to use it for this purpose, so lets have a look:</font>
<br>
<br><font size=2 face="sans-serif">(2) The source of identifier</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">(3) Which attribute to use.</font>
<br>
<br><font size=2 face="sans-serif">We still have to determine which pkcs11
object attribute (CKA_bladibla) we will use to store the identifier.</font>
<br>
<br><font size=2 face="sans-serif">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:</font>
<br>
<br><font size=2 face="sans-serif">On CKA_LABEL usage:</font>
<br>
<br><font size=2 face="sans-serif">a) 10.4 Storage objects</font>
<br><font size=2 face="sans-serif">The CKA_LABEL attribute is intended
to assist users in browsing.</font>
<br>
<br><font size=2 face="sans-serif">On CKA_ID usage:</font>
<br>
<br><font size=2 face="sans-serif">b) 10.7.2 Overview (10.7 Key objects)
</font>
<br><font size=2 face="sans-serif">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.)</font>
<br>
<br><font size=2 face="sans-serif">subsequently (since the previous quote
refers to Section 10.6 for further commentary):</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">c) 10.6.3 X.509 public key certificate
objects </font>
<br><font size=2 face="sans-serif">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.)</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">(4) Storage format.</font>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">After extensive sieving through the
spec, I have the following questions:</font>
<br>
<br><font size=2 face="sans-serif">QUESTIONS:</font>
<br>
<br><font size=2 face="sans-serif">(1) Can I use UUID as an identification
format.</font>
<br><font size=2 face="sans-serif">(2) Can I use UUID version 4 (random
numbers) as the source.</font>
<br><font size=2 face="sans-serif">(3) Can I use the CKA_LABEL attribute
to store the identifier.</font>
<br><font size=2 face="sans-serif">(4) Can I store the UUID string without
special formatting.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br>
<br><font size=2 face="sans-serif">Roy Arends</font>
<br><font size=2 face="sans-serif">Sr. Researcher</font>
<br><font size=2 face="sans-serif">Nominet UK</font>