RE: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

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

Mike,

I appreciate you addressing the points I raised with respect to DER parsing, but I think I might have done you a disservice by bottoming out that argument because it appears that my broader objections to the CPKI attribute were lost in the details of those specific discussions.  So in the interest of removing the ambiguities, let me be clear by stating that I think the CPKI attribute is unnecessary and introduces complexity and compatibility issues which will fragment future P11 token implementations.  I will find it difficult to get behind a specification which includes these new attributes.

The proposal is adding an OPTIONAL attribute to every public and private key object from 2.40 forward (and I believe that there have been assertions that this is only relevant for RSA keys?).  Do we really want to make fundamental changes to a base class (in essence) in an incremental release which does not address a fundamental fix for a previous omission?  I have yet to hear an argument that this functionality is anything more than a convenience for linking RSA keys to each other, to certificates, and to allow for tokens to have only the private key instead of both the private & public keys.  Is that a fundamental problem?  I think not.

Furthermore, this functionality will force applications which wish to utilize this attribute, to have to implement logic to determine if a token supports it or not.  And what will an application do if it is not supported by a token?  My guess is it will rely upon another field to do the same thing, and if it's going to do that, it won't bother with the new fields and just utilize a field that every token has to support, like CKA_ID/CKA_LABEL, ("lowest common denominator").  Also, the specification implies that tokens which implement it will have to ensure some integrity between 'linked' objects -- meaning, tokens will have some responsibility for ensuring referential integrity, (e.g. "SHOULD be consistent with the private key")?  And then we have to determine how the CKA_MODIFIABLE attribute interacts with this attribute (e.g. can it be updated/changed based on this attribute)?  And I'm sure there are many more questions which will arise once people starting trying to implement this functionality.  Bottom line, this is not as innocuous as it seems -- there are far-reaching implications to this proposal, and I don't think the reward justifies such a change at this point, given that applications can already implement this by encoding the CPKI into the CKA_ID, (or CKA_LABEL for that matter....).

I'm certainly in favor of addressing deficiencies as well as coming up with a robust way of solving the 'object linking' issue in a holistic fashion, but it seems like this proposal is too prescriptive in some ways, and then doesn't go far enough in others.  That's a recipe for fragmentation, inconsistencies between vendors, and application specific functionality which will devalue P11 as a standard.

Just my 2 cents.

Bob

> -----Original Message-----
> From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On
> Behalf Of Michael StJohns
> Sent: Tuesday, May 28, 2013 1:35 PM
> To: Peter Gutmann
> Cc: pkcs11@lists.oasis-open.org
> Subject: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO
> 
> New version.
> 
> The change between this one and the previous version is simply that a token
> may or may not support the use of CKA_PUBLIC_KEY_INFO in templates of
> commands that create a private key - token's choice.  If a token does support
> that attribute for those commands, it is required to validate the relationship
> between the public key info and the private key before creating the private
> key.
> 
> This I think addresses both Peter's concern about being able to figure out
> what is going on (and dealing with inconsistency) and Robert's concerns
> about needing to implement a DER parser.
> 
> Unless I hear further on this with specific proposals for change in the next 2
> weeks, I'm going to declare victory and move on.
> 
> Mike
>