RE: [pkcs11] CKA_PUBLIC_KEY_INFO

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

Mike,

Quite right -- whenever DER/BER is involved, it never quite ends up being as simple as you think.

Although encoding has some steady-state paths which can be specifically coded which short-circuits the need for a full blown encoder/decoder, I'm more concerned with having tokens *parse* incoming DER encoded blobs and interpret the data correctly -- it has been my experience that one of the first places a pen tester attacks is the DER/BER decoding routines, because it is something that is easy to get wrong when handling exceptions.  DER is a necessary evil in many contexts, but I'm not yet convinced that having tokens deal with DER/BER data is the only way to go in this instance.

Additionally, as your text accurately captures, there are some ambiguities with respect to how objects are instantiated now -- we now have two paths -- one which supplies all the attributes as enumerated key values, and the other is by supplying the DER encoded 'blob' and having the token sus-out all the relevant bits for this particular object type.  So we are now adding object instantiation code/test paths just to satisfy object relation requirements?  Feels overly invasive for what we're trying to accomplish.

Aren't there easier ways to interrelate these objects without having redundant data (e.g. marshaled forms of the same attributes already stored on the object) and requiring encoding/decoding primitives?

Thanks,

Bob

> -----Original Message-----
> From: Michael StJohns [mailto:msj@nthpermutation.com]
> Sent: Wednesday, April 10, 2013 9:37 PM
> To: Peter Gutmann
> Cc: pkcs11@lists.oasis-open.org; Burns, Robert
> Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO
> 
> 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.
> >
> >