RE: [pkcs11] CKA_PUBLIC_KEY_INFO

[Gil Abel <gil@athena-scs.com>]

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

Agree, it is indeed different.  For certs it requires ASN.1 parsing and for keys, it is device specific, but the library should obviously know how to communicate with its device. For modules that do not have asn.1 parsing capabilities (I've read such concerns about it in this thread), it may be a problem though, the certificate object itself is complex and not a simple SEQUENCE. 

I would like to ask a clarification question. Is the intend to add an attribute that can be passed to while creating the object and have it retuned while in C_GetAttributeValue? What happens if one passes (in create or set attribute) an attribute with a value that is different from what's being coded in the CKA_OBJECT itself? If the module would return the value coded in CKA_VALUE, then the value pass to C_CreateObject (or C_SetAttributeValue) is actually meaningless, and would never be returned/used. It is true that there are already other attributes today that are "doubly defined", like the subject field, which are a source of incompatibility between different modules. It would be good to solve this inconsistency too, maybe in a next standard version.

Gil.

-----Original Message-----
From: Stef Walter [mailto:stefw@redhat.com] 
Sent: Thursday, April 11, 2013 1:27 PM
To: Gil Abel
Cc: Michael StJohns; pkcs11@lists.oasis-open.org
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