Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

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?

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

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. 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. The 
reason for the burden shifted to the module is because of 
C_GenerateKeyPair (if one wants a transnational behavior or a single call).

On 05/28/2013 10:34 AM, Michael StJohns wrote:
> New version.
>
> The change between this one and the previous version is simply that a
> token may or may not support the use of CKA_PUBLIC_KEY_INFO in templates
> of commands that create a private key - token's choice.  If a token does
> support that attribute for those commands, it is required to validate
> the relationship between the public key info and the private key before
> creating the private key.
>
> This I think addresses both Peter's concern about being able to figure
> out what is going on (and dealing with inconsistency) and Robert's
> concerns about needing to implement a DER parser.
>
> Unless I hear further on this with specific proposals for change in the
> next 2 weeks, I'm going to declare victory and move on.
>
> Mike
>
>
>
> On 5/13/2013 12:25 AM, Peter Gutmann wrote:
> > Michael StJohns <msj@nthpermutation.com> writes:
> >
> > > For DSA and EC keys, the public key can be derived from the private key info.
> > > For example, the  public key for an EC private key is Pub = priv * G where G
> > > is the generator point on the curve and "priv" is the scalar that makes up the
> > > EC private key.  This is a multiplication on the curve.  Given that the curve
> > > info (including G) is part of the required info for an EC private key in
> > > PKCS11, you can always derive the public key from a private key.
> > This works OK in a software-only implementation where you've got access to
> > both the key components and a set of bignum maths routines, but how is it
> > supposed to work for hardware?  In software it's easy enough to calculate
> > y = g^x mod p (for DLP) or Q = d * G (for ECDLP), but if your x or d are
> > locked up in hardware (which I assume they are) then your token will need to
> > perform the operations, you can't do them in your driver and you definitely
> > shouldn't be asking the user to do them in their application (which they can't
> > anyway, since they can't get at x/d).
> >
> > > Again - this was a compromise based on a push back.  I'm perfectly happy to
> > > make this a MUST, but there was sufficient FUD being tossed about that I just
> > > punted.  I agree with you, but I wasn't willing to force all products to
> > > comply.
> > As an application developer I would rather have it a MUST and some vendors can
> > choose to be non-compliant, rather than have it a MAY and have to guess at
> > which vendors do it, add kludges if possible, and otherwise just tell users
> > "you can't use tokens from this vendor".  If the vendor doesn't implement the
> > MUST then it makes it obvious that you can't use their tokens, with a MAY you
> > have to experiment around with every token to see what it does and how it
> > reacts to attempts to get the public components.
> >
> > Peter.