Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO

[Michael StJohns <msj@nthpermutation.com>]

On 5/29/2013 11:55 AM, Burns, Robert wrote:
> 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
I understand you believe this.  I'm still having problems understanding why.
> and introduces complexity and compatibility issues which will fragment future P11 token implementations.
I don't understand this point at all.   I understand you think this is 
complex, I don't understand where you think compatibility comes into it.
>   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
My preference is for a mandatory attribute, but I went with optional to 
try and buy your vote. :-)  If it can't be bought, I'll change it back 
to mandatory.
> (and I believe that there have been assertions that this is only relevant for RSA keys?).
No.  Let's try this one more time.   The private key data for all 
private keys as defined by the current PKCS11 spec is sufficient to 
regenerate the public data  for the public key with the single exception 
of the definition of the PKCS11 RSA private key object. HOWEVER, there 
is no mechanism to actually extract the public key data from the PKCS11 
private key object, hence this proposal.

The RSA private key object class is allowed to have a 
CKA_PUBLIC_EXPONENT attribute, but that attribute is not mandatory. The 
data needed to derive an RSA public key from an RSA private key is 
basically the modulus (which *is* always part of the PKCS11 RSA private 
key) and the public exponent (which may or may not be).  So this draft 
changes the requirements for RSA private keys to REQUIRE the 
CKA_PUBLIC_EXPONENT as an attribute when the key is created and as part 
of the data stored when the key pair is generated.

Once that is done, then you don't even need CKA_PUBLIC_KEY_INFO to get 
the RSA public key data from a PKCS11 RSA private key, but it makes no 
sense not to do it for that key type as well as all the others.

>   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 don't believe this is a fundamental change.   This is an attribute of 
with a particular set of values that applies to a particular class of 
objects.  There are well known ways to deal with transitions where you 
may or may not be able to retrieve particular attributes.
>   I have yet to hear an argument that this functionality is anything more than a convenience for linking RSA keys to each other,
No.  The primary functionality is to be able to figure out what the 
public key data (not PKCS11 public key object) is if all you have is a 
private key.   That argument has been made repeatedly.
> to certificates,
No.  But there is no reason not to include this as a possible attribute 
for a certificate.
>   and to allow for tokens to have only the private key instead of both the private & public keys.
No.  It's to ensure that the private key on the token remains useful, 
even if the public key (which might never ever have been on the token) 
gets lost. [And this argument has also been made repeatedly].

>   Is that a fundamental problem?  I think not.
The problem as you stated it is not fundamental.  The corrected 
statement I made above is.
> 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?
FUD.  I don't know how you might want to use this field, but it's 
probably not the way either Peter or I may want to use it.  And 
generally, you're going to go "get attribute for a specific key" not 
"does this token suppot it"  The handling for that will vary based on 
whether or not the public key data is critical or just nice to have for 
the specific application.
>   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")?
*sigh*  Nope, I missed that SHOULD in the table.  It's now MUST - I'll 
provide some additional info in v4 document.

The basic thing here is that if you're going to provide public key info 
as a CKA_PUBLIC_KEY_INFO to a private key, then you have to do some 
basic things to ensure that data and the rest of the data in the private 
key match up.  There is NO, repeat NO inter-object requirement for 
referential integrity and I can't understand where you think this 
document requires this.

>   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)?
Please look at the footnote references for this attribute.  I think I 
got it right.  The attribute is read-only.  It can be provided only 
during object creation.  If provided, the data in it needs to be 
consistent with the overall private key.  That consistency check can 
either be by derive and compare, or by sign and verify - up to the token 
implementer and not specified here.

> 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.
OK - this is the first time I've heard that from you.  Care to expand on 
"doesn't go far enough"?
>    That's a recipe for fragmentation, inconsistencies between vendors, and application specific functionality which will devalue P11 as a standard.
>
> Just my 2 cents.

Just my buck and a half.

Mike

> 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