pkcs11 — archive

[Robert Burns]

Title: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO 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. 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. So in conclusion, I still don't like the marshaled data in the SPKI attribute on private objects for the reasons mentioned above; 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), 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). 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