RE: [pkcs11] CKA_PUBLIC_KEY_INFO

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

Michael,

You are quite right, I had missed it -- being that the statement was all the way at the end and subtly indicating it's optional nature, I guess it is not too surprising?  Furthermore, that text only appears at the end of the PRIVATE key section, not the public key section.  I suspect that many implementers would miss that as well, given that 99% of the attributes in P11 are mandatory.  But the notion of 'optional' parameters is a discussion for a separate thread, so I'll create a new one to dive into that one.

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.

Having said that though, as I understand it, the purpose of this field is to create a mapping between public keys, private keys, and their corresponding certificates -- correct?  If so, wouldn't an opaque field configurable by the application make more sense?  That way tokens do not have to know anything about the context of the data and yet applications will be able to easily program what makes sense for them-- meaning, application could be free to push in the subjectpublickeyinfo structure, or they could push in the hash of some fields, or even the object IDs of the things they care about.  This will minimize the amount of 'context sensitivity' each token will have to implement or worry about.  So I think this approach will meet the spirit of what you are trying to do, without putting DER encoding/decoding responsibilities on the token, because no matter how 'simple' we might perceive DER/BER encoding rules for an object to be, the reality is that the token gets absolutely nothing out of having a DER encoded blob of the same exact parameters which are already on the object itself -- my feeling is that tokens should only be engaged in activities which benefit the integrity/operation of the token and servicing P11.  Since there is no P11 notion of object linking, I'm concerned we're artificially putting responsibility on the tokens which doesn't benefit the token itself, and isn't extensible beyond public keys and certs.

As a separate topic, perhaps what we need to explore is an integral P11 capability to interrelate objects?  Is the ability to query a token and get all related objects something which extends beyond public/private/cert objects?  It *feels* like there is a use case there worth exploring that if we solve it generically, will satisfy the PKI use cases.

Thoughts?

Bob

> -----Original Message-----
> From: Michael StJohns [mailto:msj@nthpermutation.com]
> Sent: Wednesday, April 10, 2013 9:13 PM
> To: Burns, Robert
> Cc: pkcs11@lists.oasis-open.org
> Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO
> 
> On 4/10/2013 2:11 PM, Burns, Robert wrote:
> > Michael,
> >
> > 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.
> No.  Did you miss the "If support for this attribute is implemented...."
> comment.  The spec does two tangible things - it assigns a code point for
> CKA_PUBLIC_KEY_INFO and defines an encoding for that data.  It doesn't
> require any token to support it.  I think that at some point this gets added to
> one or more PKCS11 profiles as part of their mandatory to support attributes
> though.
> >    In the (somewhat distant) past, specific care was given to support tokens
> which only needed to work with the objects themselves by ensuring that the
> standard did not force tokens to implement DER/BER encoding rules (many
> reasons for this).  Is there a way in which we could support having this field
> default to "empty" so that tokens are not forced to DER encode their public
> keys if they don't want to?  That way, tokens can support the field, or choose
> not to.
> See above.  If you ask for a CKA_PUBLIC_KEY_INFO on a key that doesn't
> have that info, then you return an error code of a missing attribute.
> 
> But thanks for your comment - It reminded me that I need to add text for
> C_CreateObject for private keys and support for CKA_PUBLIC_KEY_INFO as
> part of the template.
> 
> 
> 
> >
> > Thanks,
> >
> > Bob
> >
> >
> >
> >> -----Original Message-----
> >> From: pkcs11@lists.oasis-open.org
> >> [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Michael StJohns
> >> Sent: Tuesday, April 09, 2013 7:35 PM
> >> To: pkcs11@lists.oasis-open.org
> >> Subject: [pkcs11] CKA_PUBLIC_KEY_INFO
> >>
> >> Attached is an edit of the appropriate sections of PKCS11 v2.30 to
> >> add support for CKA_PUBLIC_KEY_INFO.
> >>
> >> Additions are highlighted.  Assuming this is acceptable, I'll provide
> >> the appropriate edits for the public key sections to describe the
> >> encoding of the public key info field in SubjectPublicKeyInfo
> >>
> >> Mike
> >
> >