<font size=2 face="sans-serif">I've discussed the issue with David Miller
and Dr Stephen N Henson.</font>
<br>
<br><font size=2 face="sans-serif">It seems that there is indeed much confusion
in the field about CKA_ID's and CKA_LABELs. As an example, there exist
pkcs11 libraries that will promiscuously match CKA_ID's while the search
template specifies CKA_LABEL and vice versa. On the uniqueness of identifiers
they advised that we can't uniquely assign identifiers per object, since
some objects need to match other objects. In our case, we need to match
CKO_PRIVATE_KEY with CKO_PUBLIC_KEY. Two different, independent objects
from a PKCS11 perspective, though they need to be matched. For that purpose,
we need to have CKA_ID to match the two, hence they need to be equal. So
the uniquely identifiable pragma holds only for CKO_PRIVATE_KEY and CKO_PUBLIC_KEY
Pairs. There are some implementations that ignore CKA_ID, and some that
ignore CKA_LABEL. Even to the point that the attribute is present, but
can't be used for C_FindObjects. </font>
<br>
<br><font size=2 face="sans-serif">Another issue is that often CKA_LABEL
needs to be non-empty, as there are some applications that use the empty
CKA_LABEL to match all objects for a certain purpose. Their conclusion
is to be pragmatic. Though the theory is that CKA_LABEL can well be used
for searching, CKA_ID needs to be present anyway to match the private object
with the public object. Hence forcing the use of CKA_LABEL is overkill.</font>
<br>
<br><font size=2 face="sans-serif">So it seems that the experts (rick,
roland, david and steve) agree. I'll step off my high-horse and conform.
CKA_ID it is. Next time we meet (RIPE?) , beer is on me, to compensate
for the wasted time. (Rick, lets do that soon).</font>
<br>
<br><font size=2 face="sans-serif">That leaves us with the encoding. do
we put a string like "254F9220-7B9C-4386-ABC2-F8230E3843B3" in
the CKA_ID or do we put the 128 bit value in the CKA_ID. There is no restriction
here, other than the requirement of the signer for translating the 128
bit value to UUID when we decide to store the 128-bit value. (the translation
does not need to be done in the signer when we use the UUID overall).</font>
<br>
<br><font size=2 face="sans-serif">We still need the CKA_LABEL to be non-empty.
I'll just put "OpenDNSSEC DNSKEY" in there, unless told otherwise.</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>
<br>