Re: [pkcs11] CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 4/10/2013 6:49 PM, Peter Gutmann wrote:
> "Burns, Robert" <Robert.Burns@thalesesec.com> writes:
>
> > Based on this proposal, it appears that now every token that wants to work
> > with public keys will be required to have DER encoding/decoding functions for
> > all public keys.
> The entirety of the encoding consists of something close to:
>
>    data[ 0 ] = 0x30;
>    data[ 1 ] = length_msb
>    data[ 2 ] = length_lsb
>    memcpy( data + 3, key_component(s), key_components(s)_length );
>
> (with an extra BIT STRING wrapper in some cases, probably about 20-30 lines of
> code in all).  That really isn't a killer requirement given how much other
> stuff PKCS #11 drivers are required to do.

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.

For example, an EC key gets encoded as (RFC5480):

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}
         }
     }
}


The nice thing is that for any given length of key (RSA), or curve type 
(EC), you can build a template where you just plug in the key data.   So 
you can a) not implement, b) implement a full ASN1 encoder/decoder, c) 
implement a minimal encoder decoder (to deal with differing lengths), or 
d) implement multiple static templates to cover all types of keys you 
support.

> > That way, tokens can support the field, or choose not to.
> Tokens that don't support the field are going to be chosing not to work with a
> large range of applications, for example anything that requires certificates.
> It's only the fact that DSA and ECDSA are virtually unused at the moment
> compared to RSA that this problem hasn't been more visible.
>
> Peter.