RE: [pkcs11] CKA_PUBLIC_KEY_INFO

["Burns, Robert" <Robert.Burns@thalesesec.com>]

Peter,

Oh, ok -- perhaps I was looking at this wrong.

You are proposing this mechanism to fix the issue of non-RSA keys not having the appropriate public bits, rather than the mechanism for tying the keys together with a cert?  (e.g. the ECDSA private key issue...)  If so, I got that wrong.

If my interpretation is correct, shouldn't this be solved similar to how the RSA private key handles it?  That is, but requiring the public key attributes on the object too?  Maybe easier said than done, but given this is something you're intimate with, what are the issues associated with adding all the public bits to each private key object?

Finally, tangent to our DER discussion, using these public key blobs on the private keys would then REQUIRE all tokens be able to DER decode them to make effective use of the public bits, contradicting the assertion that most tokens won't need to DER decode anything.

Bob

> -----Original Message-----
> From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
> Sent: Thursday, April 11, 2013 8:23 PM
> To: msj@nthpermutation.com; Burns, Robert
> Cc: pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] CKA_PUBLIC_KEY_INFO
> 
> "Burns, Robert" <Robert.Burns@thalesesec.com> writes:
> 
> >So I now understand you wish to make this optional, which I think is a
> >better default position rather than requiring it for all new
> >public/private key objects.
> 
> It's actually a really bad position because non-RSA private keys without this
> information are essentially unusable.  The fact that they're barely used at the
> moment is hiding the problem, if they ever get widely deployed across
> different applications there will be... feedback from users.
> 
> Peter.