RE: [pkcs11] CKA_PUBLIC_KEY_INFO

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

> 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!

The original problem of getting the public key data from a private key is somewhat different. Although the public key attribute cannot be just "written" to the private key object on the device, many (most?) devices have their own methods to extract the public key information from within the private key (e.g. by card specific commands) and then the p11 module can generate the SubjectPublicKeyInfo on the fly and return in C_GetAttributeValue(private-key).

Note that an implication of the above is that technically, returning the CKA_PUBLIC_KEY_INFO from a private key does Not necessarily require the CreateObject function to accept that attribute as a parameter (the data may be derived from the device no matter how the key was created).
I agree though that it may make sense to allow to pass the CKA_PUBLIC_KEY_INFO in CreateObject as well as suggested though, both because object should be well-formed and also because this mechanism looks elegant, but these could be 2 different decisions.

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....").

Gil.



-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Stef Walter
Sent: Thursday, April 11, 2013 8:23 AM
To: Michael StJohns
Cc: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO

On 10.04.2013 01:35, Michael StJohns wrote:
> Attached is an edit of the appropriate sections of PKCS11 v2.30 to add
> support for CKA_PUBLIC_KEY_INFO.
> 
> 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

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 addition I'd like to use it in a trusted certificate PKCS#11 model.

Cheers,

Stef


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php