OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO


On 11.04.2013 10:35, Gil Abel wrote:
>> Additions are highlighted.  Assuming this is acceptable, I'll
>> provide the appropriate edits for the public key sections to
>> describe the encoding of the public key info field in
>> SubjectPublicKeyInfo
> 
> I agree it will important to described the ASN.1 encoding for each
> key to assure interoperability.
> 
>> Can we have this attribute on X.509 certificates as well? That
>> would be a good way of detecting whether a certificate and key
>> match cryptographically.
> 
> In my opinion this will be a problem. Need to remember that
> certificates on devices may include only the CKA_VALUE and the p11
> module may be generating on the fly other fields. This depends on the
> actually implementation of the library and on the device itself and
> its internal file system. In case of smart cards, the file system on
> the card is derived by other standards (e.g. ISO 7816.15 but also
> other), so a library cannot simply add more attributes to the object
> in the device itself!

Right, obviously many p11 modules would just read the
tbsCertificate.subjectPublicKeyInfo field from the X.509 certificate and
return exactly that.

Implementation of this for X.509 certificates would be trivial in
comparison to doing it for public and private keys.

> As mentioned before, I also agree that we should add the "(default
> empty)" in the Meaning field of the attribute (regardless of the
> later statement that "If support for this attribute is
> implemented....").

Agreed.

Stef


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]