Re: [pkcs11] CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 4/11/2013 2:04 AM, Peter Gutmann wrote:
> Michael StJohns <msj@nthpermutation.com> writes:
>
> > It's probably a bit more than that.  It may make sense (in the sections for
> > each type of public key) to provide DER templates that can just be filled in.
> It's actually not that bad, if you look at:
>
> > Sequence {
> >      Sequence {
> >          Object Identifier,  id-ecPublicKey
> >          Object Identifier   id for the curve
> >       }
> >       Bit String (0 extra bits) {
> >           Encoding of Octet String {
> >                 X9.63 representation of an uncompressed point  { 0x04 | X | Y}
> >           }
> >       }
> > }
> then the token (well, lets face it, the driver) already has to provide the OID
> and the encoded point as DER data (so the no-DER rule is already violated),

> which means that the inner SEQUENCE and the OIDs are a static blob, as is the
> encoded point.  All the "DER encoder" needs to add is the inner BIT STRING
> header and the outer SEQUENCE header.  In addition for all but P521 curves the
> length will be encodable in a single byte, so the encoding is just:
>
>    data[ 0 ] = 0x30;
>    data[ 1 ] = length;
>    data[ ... ] = OIDs blob
>    data[ n ] = 0x03
data [n + 1] = 2 * key size  + 4  (1 for spare bits, 2 for octet string 
header, 1 for ec point format byte)
data [n + 2] = 0x00
data [n + 3] = 0x04
data [n + 4] = 2 * key size + 1
data [ ... ] { 0x04 | X | Y }
>    data[ n+1 ] = 0x00
>    data[ ... ] = point blob
>
> In practice you'd probably have an "encodeSequence()" and "encodeBitString()"
> that inserted the tag + length and use that for RSA, DSA, ECDSA, etc.
>    
> Peter.
I think we're in violent agreement though that this is minimal work, 
even inside a token.  But that's not required.  As a minimum, the low 
level code in the HSM has to do a "generatePublicKeyFromPrivate()" and 
return that value to the driver.  The driver can then (in user space) 
format the SubjectPublicKeyInfo.
>