Re: [pkcs11] CKA_PUBLIC_KEY_INFO

[Robert Relyea <rrelyea@redhat.com>]

On 04/17/2013 05:53 PM, Andrey Jivsov wrote:

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 agree with your assessment I'm sure how the proposal violates this. You don't actually need the certificate to create an SPKI, you only need the public key and a der encoder (A simple one would work). The latter is the difficulty.

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?

(without endorsing the plan), CKA_PUBLIC_KEY_INFO is a DER SPKI, which is completely independent of any certificate. It is simply a DER encoded bare public key. It happens to be embedded in a certificate.

Clearly the application creating the private key with C_CreateObject() should set that value. Presumably the application which does a C_Unwrap() of a key also needs to specify the object. The module can enforce the existance of CKA_PUBLIC_KEY_INFO in these cases.

You definately have a point, though, if the private key is *generated* with C_GenerateKeyPair(). The application can't supply it in the template because it does not yet know the public key. So does the application have to set it after the key creation? (It would if it needs to be opaque), or do we require the module to set it on generate?

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.

This, I agree with, in almost all instances the public exponent should be available at key creation (either during C_GenerateKeyPair() in the module, or in C_CreateObject and C_Unwrap in the application).

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.

OK, this says the value is created by the module in the C_GenerateKeyPair() case, and by the application in the other two cases (since the application has access to the public key, but the module wouldn't necessarily yet).

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 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature