Re: [FORGED] [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 5/10/2013 9:58 PM, Peter Gutmann wrote:
> Michael StJohns <msj@nthpermutation.com> writes:
>
> > SHOULD be consistent with the private key)
> Only "SHOULD"?  Shouldn't this be a "MUST"?
I'd like it to be, but this was a compromise based on a push back from 
one of the members.
> > All other private key types described in this specification contain
> > sufficient information to recover the associated public key.
> Uhh, not as far as I know, they contain no information at all that can recover
> the public key.  A pure private-key object for the (EC)DLP algorithms (e.g.
> DSA, ECDSA) is essentially useless because there's no way to get at the public
> key components.

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.  [I'm making the assumption that the key is 
never stored with the "implicitlyCA" choice, and that the token knows 
what the underlying curve parameters are for the "namedCurve" choice for 
CKA_EC_PARAMS].

 The math that governs DSA and DH keys also allows the recovery of the 
public key from the private key given what is required to be stored.  
For RSA, what's missing in the data required to be stored with the RSA 
private key needed to reconstitute the public key is the public exponent.

I wasn't able to confirm this property for GOST key pairs, but 
apparently GOST key pairs are in the same math family as DSA and EC key 
and I *think* this property applies as well given what is stored.  I 
think I noted that I wasn't sure though and suggested an expert review it.

> > (MAY be empty
> Making this a MAY (rather than a MUST) doesn't really communicate what the
> consequences are.  If it's not a MUST then there should be text saying that if
> this information is omitted then the private-key object is essentially
> unusable unless a corresponding public-key object also happens to be present.
> To give an example of how messy this makes things:
>
>    The only way to verify that the public key of the cert matches the private
>    key on the HSM-token is "probe signing". For this you need software
>    RSA/ECDSA verification. If there are multiple private keys installed on the
>    token you need to sign a probe-hash with each key until the public key of
>    the cert verifies it.

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.

> I think I'd just declare a vendor's product broken before I jumped through
> those hoops to get it to work.
>
> Peter.