[Opendnssec-develop] *blush* The experts agree. CKA_ID it is.

[Roland van Rijswijk]

Excellent idea! Agreed :-)

Cheers,

Roland

Jakob Schlyter wrote:
> I recommend that we use the ASCII representation of the UUID to ease
> access with 3rd party tools for debugging and monitoring.
> 
> --
> Sent from my iPhone, hence this mail might be briefer than normal.
> 
> On 12 mar 2009, at 18.45, "Roy Arends" <roy at nominet.org.uk
> <mailto:roy at nominet.org.uk>> wrote:
> 
>> I've discussed the issue with David Miller and Dr Stephen N Henson.
>>
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> 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).
>>
>> We still need the CKA_LABEL to be non-empty. I'll just put "OpenDNSSEC
>> DNSKEY" in there, unless told otherwise.
>>
>> Thanks,
>>
>> Regards,
>>
>> Roy Arends
>> Sr. Researcher
>> Nominet UK
>> _______________________________________________
>> Opendnssec-develop mailing list
>> Opendnssec-develop at lists.opendnssec.org
>> <mailto:Opendnssec-develop at lists.opendnssec.org>
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl