Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

Title: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

On 5/29/2013 8:19 PM, Burns, Robert wrote:

Mike,

Ah-ha -- progress!

So yes, as you say, private objects which are sensitive do now allow access to private bits in order for the app to calculate/derive the public bits. So, as I see it, we are down to 4 things your proposal is trying to accomplish:

1) Adding SPKI to certificate, just because it *might* be useful, although it is redundant info.
2) Adding SPKI to public keys, again because it *might* be useful, although it is redundant info.
3) Adding CKA_PUBLIC_EXPONENT to an RSA private key so that users can extract the public key from the private key object (which will work in this case, regardless of the sensitivity of the key).
4) Adding SPKI to private keys so that users can derive/deduce the public key from the private key object.

For the interest of clarity, let's ignore #'s 1-3 for now, and focus on #4 because *that* is the root of my concern.

I don't believe that obtaining the public key from a private key is (currently) a reasonable expectation. If a user wants the public bits, they need either the corresponding public key object, or the certificate. Lots of applications work this way, and this is not something that P11 hid from users -- it is very explicit and easily deduced from all the specs from day 1. Expecting the public bits from a private object has never been implied by P11.

What I just heard you say was:  "If it was good enough for granddad, it's good enough for me". 

There are a lot of things that were never implied by PKCS11 v2.0 that are in V2.10, V2.20 and V2.30.   If the current spec were perfect, we wouldn't be having this discussion.

So, your proposal is trying to change that behavior -- fair enough. I'm not against trying to solve that problem -- I just don't think a solution which hides all the public key info in a marshaled data structure is not the way to go and is inconsistent with the way that P11 deals with user accessible attributes on objects -- it's incongruent with existing behavior (e.g. our solution should show some synergy with existing public key object attributes themselves!) in that P11 avoids dealing with marshaled data structures. Again, not against evolution and changing behavior, I just want to understand the issue and fix it in an architecturally consistent way -- and to do that right, I feel the solution is too big for a 2.40 release and will take a little more than adding an additional object attribute.

I get the feeling that you missed the earlier discussion.  There are something like 5 or 6 different types of public key pairs defined in PKCS11.  Each of them has a distinct set of data that comprises a private key.  I had two choices - leave the data format undefined for CKA_PUBLIC_KEY_INFO in the general case and go back for each and every key type and specify a format specific to that key type, OR specify CKA_PUBLIC_KEY_INFO as a SubjectPublicKeyInfo blob  as the general case which meant that the rest of the definitions came in by reference.  I did the latter as being "cleaner" and being applicable for all key pair types.

What Peter originally proposed (See a message dated 4/2 subject "info for OASIS...") was to use C_DeriveKey with a mechanism CKM_GET_PUBLIC_KEY.  That message and subsequent explains how we got to CKA_PUBLIC_KEY_INFO and why.  If you would prefer one of the other options we discussed, feel free to write it up.

So in conclusion, I still don't like the marshaled data in the SPKI attribute on private objects for the reasons mentioned above;

Got that - but those appear to be style comments rather than technical comments.

not sure it's necessary (e.g. what customers have a system which requires public attributes but only have the private key???? seems like a broken system to me),

Um. you mean public keys but only have the private key?  Keep in mind that the creator of the token may not be the client that actually uses the token.   Also consider something like a TPM which doesn't actually store the public key for a key pair in an object separate from the private key (you can extract the public key from the private key and use it as a separate object, but the generate key pair function only generates the single private key object).  I wouldn't consider that broken.

and if it is, the solution should be implemented at a more fundamental/architectural level so as to apply more universally across the objects, rather than just for a private key (e.g. new object type like KeyPair?, or adding all public attributes to private objects so they can be read?, or creating a 'Collection' object type where objects can be intrinsically grouped in a single reference?, etc. -- just some 'for example' thoughts).

This seems like "If I can't do everything, I'm not going to do anything" sort of argument.  If you have specific proposals rather than "but how about this" comments, it would be helpful if you actually made them, even if they might be deferred to 3.0. 

Finally, I do appreciate you taking the time to explain your position and to try to 'bring me around', but for future reference, I would try bribing with Guinness rather than concessions! ;-) At the end of the day we're a diverse group and although it is nice to have consensus across the board, it certainly isn't a requirement to get your changes into the spec. And if it does make it, I'll do my best to implement it better than any one else!

Thanks,

Bob