Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 5/29/2013 7:07 PM, Andrey Jivsov wrote:
> Here are my concerns about CKA_PUBLIC_KEY_INFO, listed as features 
> with comments.
>
> 1. Linking public key / private key / certificate.
>
> The concern here is that there are current mechanisms that can 
> accomplish the same, such as CKA_ID. In my experience CKA_ID works in 
> practice. Relational database tables are routinely linked by a 
> "foreign" key. Why not tighten CKA_ID it to make it perfect?

This literally has NOTHING at all to do with linking these three 
objects.  It may be a side effect of that the attribute can be used for 
this purpose, but it's not the primary reason for doing this.


> 2. CKA_PUBLIC_KEY_INFO is a canonical ID, aka a key fingerprint.
>
> That is, it's the same ID for a given key pair. A nice idea, but this 
> restriction adds complexity. C_GenerateKeyPair must generate 
> CKA_PUBLIC_KEY_INFO (module's responsibility), while C_CreateObject 
> and C_Unwrap will need to supply it (client's responsibility). 
No.  Please see the revised version.  There is no requirement for a 
module to be able to parse the DER, but if it does, it needs to verify 
consistency.
> The thought here is: If the module must have the code to parse/make 
> CKA_PUBLIC_KEY_INFO for C_GenerateKeyPair, it could do so for the 
> other two and free up the client.

No. This is not an artifact of C_GenerateKeyPair, it is an underlying 
artifact of either the public or private key.  For a public key, its a 
simple matter to throw the various components into a DER template.  For 
the private key, there's generally a math problem to be solved to get 
the public key.  Of course for C_GenerateKeyPair, you're deriving the 
public key at the same time you're generating the private key, so it's 
pretty easy to make a note of that data and save it with the private key.


> 3. DER support.
>
> Does this introduce dependency on ASN.1 / DER? If the answer is no, 
> the PKCS#11 standard will need to specify the memory dump of ASN.1/DER 
> SubjectKeyIdentifier, the appropriate OID for the public key, and the 
> spec for how to inject the subjectPublicKey OCTET STRING into the 
> structure. This will need to be done for each key type. It seems like 
> a maintenance burden. 
No.  The document specifies SubjectPublicKeyInfo as the standard 
representation.  It is up to the implementer to determine how he wants 
to form that implementation - e.g. by template, by DER encoder, by 
magic, etc.  Each of the key types has a document which specifies how a 
public key is encoded into a SubjectPublicKeyInfo - that doesn't need to 
be written yet again.
> My suggestion is to try think about removing the requirement that the 
> client must create DER of CKA_PUBLIC_KEY_INFO. It SHOULD "replay" it 
> whenever possible, but not required to construct. 
Again - implementation detail not appropriate to the document.  And 
someone somewhere has to create the DER.

> The reason for the burden shifted to the module is because of 
> C_GenerateKeyPair (if one wants a transnational behavior or a single 
> call).

Not really.  But this is such a slippery statement that I'm going to 
avoid trying to parse it and refute it, because I'm not quite sure I 
understand exactly what you mean.

Later, Mike