Re: [FORGED] [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

We're still talking past each other a bit.  Let me try again.

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?
Sorry - I assumed it was understood that the hardware (or rather the 
firmware on the hardware) would have to be updated to provide the data 
for the CKA_PUBLIC_KEY_INFO object.  The actual formatting of such data 
into a DER blob could either be done on the token side or completed on 
the driver side.  Any token that can generate key pairs has sufficient 
library routines to regen the public key from the private data.

What I meant to convey from the above is that the underlying 
representation of the data for each type of private key EXCEPT RSA had 
enough information to regenerate the public key.  With RSA, what was 
missing was the public exponent, so that needed to be added.  As a nice 
side effect, simply adding that data makes the RSA public key accessible 
from PKCS11 from the private key thanks to both the modulus and public 
exponent being public data.
>   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).
Yup.

> > 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.
Heh.  And some token developers would like it just the opposite. When it 
gets to the point, I'll cast a vote for MUST though.

It may be the case that this is an absolute MUST for a FIPS 140-2 
profile compliant token.

If we're close enough on the current draft, I'll go through it and 
extract the MUST/MAY/SHOULD points for argument and vote.

> Peter.