OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO


On 4/11/2013 11:04 AM, Burns, Robert wrote:
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.
Actually, I think this should be mandatory for 2.40, but that it's perfectly ok to return an empty value and to reject it as an attribute on C_CreateObject templates.
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?
Not exactly. The purpose of this field is to find the public key that corresponds with a private key, given that some tokens only store the private key. The rest of this is just useful additions.
  If so, wouldn't an opaque field configurable by the application make more sense?
Nope. See above. Its possible that some drivers may implement it this way, but they shouldn't.
  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.
Basically, if you want something like this, define a field for it. This is CKA_PUBLIC_KEY_INFO and it's there because there's usually enough info in the private key storage to extract the public key.

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.
The capability exists in the spec, but is implemented in wildly different ways in reality. The combination of CKA_LABEL and CKA_ID are supposed to be used to indicate those types of relationships, but the implementers are free to do it anyway they want.



Thoughts?






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]