Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 05/30/2013 08:14 AM, Michael StJohns wrote:
> 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.
OK, so you are saying the primary reason is to get a public key from the 
private key. I had to guess.

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

...that's what's what the optional "means". I am focusing on cases when 
these structures are created.

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

I think you are talking about the module side. If your description above 
applies to what a module suppose to be doing for the implementation of 
the C_GenerateKeyPair  -- I agree with you and was not referring to 
these steps.

I was saying that for the other APIs: C_CreateObject, C_Unwrap, if I 
understand this correctly (and this is how  Robert Relyea understood it 
too), it's the client who suppose to create the DER and pass the DER 
blob to these two APIs.

So, C_GenerateKeyPair -- module creates it; C_CreateObject, C_Unwrap -- 
client creates it. Is my understanding correct?

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

Let me suggest an alternative. Why can't a few already defined 
attributes be added to the private key so that the public key can be 
reconstructed?

PKCS#11 is written to communicate using a set of CK_ATTRIBUTE 
structures. It's a step away to start passing the information in 
DER-encoded structures.

In particular:

CKK_RSA: private key must have CKA_PUBLIC_EXPONENT.

Define a key-specific attribute for key types where this is needed. 
(e.g. DSA public and private keys use CKA_VALUE, perhaps add 
CKA_PUBLIC_VALUE, which is a copy of the CKA_VALUE of the public key)...

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

It's not accurate to say that PKCS#11 is not viable without 
understanding of DER or X.509. Such DER-less applications exist. Think 
about PGP or SSH keys on the tokens / HSMs.

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

Hopefully, my earlier comments clarify this.

> Later, Mike
Thank you.
> ---------------------------------------------------------------------
> 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