Re: [pkcs11] CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 4/11/2013 7:21 AM, Gil Abel wrote:
> 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.

There are only two places where this might be a problem.  RSA private 
keys where the internal storage form doesn't permit recovery of the 
public key, and EC keys where the curve doesn't have an OID that the 
module knows.

In the former, I'm going to write some language that says if you use 
CKA_PUBLIC_KEY_INFO on a C_CreateObject call for any private key, you 
have to verify key agreement between the public and private key before 
storing the attribute.

In the latter, although the choice of ecParameters has been deprecated 
in RFCs for actual SubjectPublicKeyInfo, I think its probably reasonable 
to provide here.  In which case you check to see if the ecParameters 
value in the CKA_PUBLIC_KEY_INFO is the same as the CKA_EC_PARAMS value 
for the key - if provided.  (Actually, if you provide 
CKA_PUBLIC_KEY_INFO and CKA_VALUE in a C_CreateObject for an EC private 
key, you've got all the data you need to create the private key.

When I get around to writing the key specific stuff, I'll provide more 
detail on what goes where.  I'm pretty sure I can define something that 
gets you consistent results.

Mike