RE: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

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

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






-----Original Message-----
From: Michael StJohns [msj@nthpermutation.com]
Sent: Wednesday, May 29, 2013 06:21 PM Eastern Standard
Time
To: Burns, Robert
Cc: Peter Gutmann; pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

On 5/29/2013 5:52 PM, Burns, Robert wrote:
> Mike,
>
> Ok, it seems like we're going in circles here -- let me try a different tack....let me ask a question in order to hear what you're saying in a different context.  Perhaps then I will understand where you're coming from.
>
> Let's assume that we are in agreement over requiring the CKA_PUBLIC_EXPONENT attribute on all RSA Private objects in 2.40.  I then believe that all P11 private objects have sufficient attributes to derive the public key from the object, (which you indicated in your email as well).

Ah - now I understand where you're tripping up.  This has to do with
whether or not an attribute is actually retrievable by a client from a
private key object.

For RSA, both CKA_MODULUS and CKA_PUBLIC_EXPONENT are non-sensitive for
an RSA private key.  You can extract them even if CKA_SENSITIVE is TRUE
for the private key.

For all the rest of the private key types, (and let's take an EC private
key as the specific example), if the private key is CKA_SENSITIVE =
TRUE, then you can't extract the necessary private key value (stored in
CKA_VALUE for an EC key) to do the calculation to derive the public key
as that (CKA_VALUE) attribute is considered sensitive.   (See Table 15,
item 7 tag).

So posit a private key that is CKA_SENSITIVE = TRUE (or CKA_EXTRACTABLE
= FALSE), even if the private key contains sufficient data to regenerate
the public key, it is NOT available directly to you, it can't be
retrieved by a call to C_GetAttributeValue, and  you cannot regenerate
the public key with the publicly available attributes of the private key.

CKA_PUBLIC_KEY_INFO basically does:  "In a secure manner, regenerate and
return the public key from the private key OBJECT without compromising
any of the private key sensitive data.  You may do the regeneration once
when the private key is created, or do it on demand when the attribute
is retrieved."



>
> Then my question to you is, do you still *need* the SPKI attribute on all Public, Private, and Certificate objects?  If so, why?
You need it on the private key.  You might as well have it on the public
key, and for the certificate it's just additional data that may or may
not be useful.   For the last two, it's mostly a don't care for me.  I
added the text more based on other comments.  But it's going to stay now.

>
> Thanks,
>
> Bob
>
>