RE: [pkcs11] CKA_PUBLIC_KEY_INFO

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

Apologies on the late reply -- I think that's true, but my comment was addressed towards the language which would allow the user specifying the public key info to a C_CreateObject() (e.g. don't have to supply the standard public key attributes) and the text which talked about how to handle the cases where the information contained in the public key info blob didn't agree with the object (I think it was on a private key?) -- sorry, I don't have the doc in front of me.

As I read your text below, it would seem you believe that the cases where DER decoding would be required to be few-and-far between.  That may indeed be true, but implementers have to consider all cases if they are going to support something.

Not dead-set against it, but just wondering if there might be an easier way.

Bob

> -----Original Message-----
> From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
> Sent: Thursday, April 11, 2013 8:27 PM
> To: msj@nthpermutation.com; pgut001@cs.auckland.ac.nz; Burns, Robert
> Cc: pkcs11@lists.oasis-open.org
> Subject: RE: [pkcs11] CKA_PUBLIC_KEY_INFO
> 
> "Burns, Robert" <Robert.Burns@thalesesec.com> writes:
> 
> >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
> 
> There's no need to do any decoding.  If the caller supplies it then you just
> memcpy() it somewhere without parsing it.  However in most cases it's not
> supplied (e.g. for C_CreateObject() and whatnot).  In either case though you
> don't need to do any parsing, and the encoding is the bare-bones stuff I
> posted in my previous message.
> 
> Peter.