Re: [pkcs11] CKA_PUBLIC_KEY_INFO

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 04/17/2013 09:06 AM, Michael StJohns wrote:

After reviewing the bidding, I'm thinking that Bob's issues are mostly 
on the "parse and decode" side, rather than the "read out and encode" side.

Given that how about:

1) CKA_PUBLIC_KEY_INFO can't be used in C_CreateObject templates for 
public or private keys.  It *may* be used for certificates, but is 
opaque there.  This eliminates the need to parse the DER, and then do a 
consistency check between the public key info and private key info for 
the private key.

We have a product, over 10 years old now, that generates PGP keys on a smartcard with any brand of PKCS#11 token that I encountered. These PGP keys don't necessarily have X.509 certificates, definitely not at the time of generation.

It's common in PKI world that the public + private key doesn't have 1:1 relationship to the X.509 certificate. In practice, keys are often reused, thus creating the situation of 1 (key) : M (certificates ). Adding PGP keys here, it's 1 (key) : * (certificates).

That's the reality of keys and certificates today. Prior PKCS#11 standards and their implementations worked well with this reality.

I will also second the concern that PGP is an example where DER is a foreign encoding. When DER is needed in OpenPGP, as in PKCS#1 signatures, it is actually specified as a byte stream in http://tools.ietf.org/html/rfc4880 sec 5.2.2 with places to insert the values.

So far CKA_PUBLIC_KEY_INFO seems to match the existing features of PKCS#11.

A question: whose responsibility it is to form CKA_PUBLIC_KEY_INFO. Is the current state of the proposal to always generate it on the fly or return if stored by the library, any time it's read, except that it can be set by the client for the certificate object only?

2) The data required to be stored for each private key shall be reviewed 
and changes made to ensure that the appropriate attributes sufficient to 
regenerate the public key shall be stored with the private key, and if 
needed provided with any call to C_CreateObject for that type of private 
key.  For the RSA case, this means that CKA_PUBLIC_EXPONENT MUST be in a 
template for an RSA private key and stored with that private key.

3) CKA_PUBLIC_KEY_INFO  can be used in a call to C_GetAttributeValues 
for all public and private keys.  It will be encoded from the data 
available for those keys.  (Which should mostly involve stuffing the 
public key data into a template).  If an implementation doesn't wish to 
support this it will return the empty value.

Comments?  (Ideally from others besides myself and Bob)

Mike







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