On 4/16/2013 11:24 AM, Burns, Robert
wrote:
Peter,
Sorry for the late response -- traveling.
I understand now where you're coming from.
So a couple of follow up statements and then perhaps this will be
a
discussion that needs to happen 'out-of-band'?
I'm having difficulty imagining other use cases where a user will
only have access to the private key, yet needs access to the
public
bits as well. I do understand your experiences with tokens which
fit this mold, but the error (it seems) is in the fact that the
token distributors were not also including the public key object
as
well?
You're missing the case where the private key is generated off
token, and the form of the private bits does not include sufficient
information to recover the public bits. (The one that springs to
mind is the { n, d } form of an RSA private key).
Here's what the decision tree for a C_CreateObject for an RSA
private key looks like:
if (CKAPUBLICKEYINFO_IS_SUPPORTED) {
switch (keyformat) {
case RSA_N_D_FORM:
if (attributes include CKA_PUBLIC_KEY_INFO) {
-- verify the data represents a valid RSA public key
-- verify this public key matches the private key
represented by CKA_MODULUS,
-- CKA_PRIVATE_EXPONENT on this call
-- save the opaque CKA_PUBLIC_KEY_INFO data for later use
} else { // no public key data provided
-- set the value of CKA_PUBLIC_KEY_INFO for this private
key to zero length
}
break;
case RSA_N_D_P_Q_FORM:
case RSA_CRT_FORM:
if (attributes include CKA_PUBLIC_KEY_INFO) {
-- verify this is a valid RSA public key
-- verify this public key matches the private key
represented by CKA_MODULUS,
-- CKA_PRIVATE_EXPONENT, P, Q and possibly the CRT data
-- save the opaque CKA_PUBLIC_KEY_INFO data for later use
} else { // no public key data provided
-- derive the public key from the private key data (e.g. p
and q) provided
-- encode it as a DER SubjectPublicKeyInfo
-- set CKA_PUBLIC_KEY_INFO for this private key to that
value
}
break;
}
}
Seems like we're hacking P11 to make up for the
deficiencies
in how someone decided to deploy their tokens. Again, I don't
doubt
that this is a real problem that you're facing, just not sure if
this is one which P11 needs to solve?
Secondly, I'm still feeling like adding SPKI to a private key
object is not keeping within the spirit of P11 objects -- the
public key bits should be on a separate object (yes, I know RSA is
the exception in this case, but it is only a single attribute
(public exp) and relatively small). Putting in a marshaled form of
the public key bits is relatively straight forward, but introduces
ambiguities, etc. For example, how much time will pass before
people start asking for the ability to do signature verifications
using the SPKI info on a key?
You do a C_GetAttributeValue for CKA_PUBLIC_KEY_INFO to get that
value.
Then you do a C_CreateObject for a public key using
CKA_PUBLIC_KEY_INFO in the template
and THEN you do a signature verification using that brand new public
key.
One of the purposes of having two unique objects in P11 for
asymmetric keys was to be able to support different permission
attributes, as well as different user ACLs. By shoving everything
(even marshaled and 'opaque') onto a private object introduces a
number of *potential* ambiguities which will become more difficult
to manage going forward.
Nope. The public key info on the private key is just data on the
private key. It is not a key. It has the permissions appropriate
to data associated with a private key (and I'm ok if that data is
Private - I think it should be public though ala CKA_LABEL and
CKA_ID).
I definitely understand where you're coming from, and I'm trying
to
take a pragmatic view, but at some point we do have to honor the
P11 model or else we end up with an unmanageable specification.
So is the problem really that there are definite cryptographic
reasons for needing the public key attributes on a private key, or
is this just a convenient way to solve the problem that token
vendors have introduced by not providing enough objects on their
tokens?
There's also the case where someone accidentally deletes the public
key by accident (e.g. I didn't need the public key because I have a
certificate - what do you mean I don't have a certificate???) ...
it would really be nice if your private key were still useful.
Later, Mike
Thanks,
Bob
-----Original Message-----
From: Peter Gutmann [pgut001@cs.auckland.ac.nz]
Sent: Saturday, April 13, 2013 01:44 AM Eastern
Standard Time
To: msj@nthpermutation.com; pgut001@cs.auckland.ac.nz;
Burns, Robert
Cc: pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] CKA_PUBLIC_KEY_INFO
"Burns, Robert"
<Robert.Burns@thalesesec.com> writes:
>You are proposing this mechanism to fix the issue of
non-RSA
keys not having
>the appropriate public bits, rather than the mechanism for
tying the keys
>together with a cert? (e.g. the ECDSA private key
issue...)
Absolutely. The "tying keys together" seems to have gotten
added later, but
it was never the original intent, which was to fix the problem
that
if you
have a token with a private key object that's anything but RSA
then
you pretty
much can't use it because you can't get the public key for
it. The most
obvious example of this is that you can't get a certificate
for the
key
because the CSR requires the public-key components.
>If my interpretation is correct, shouldn't this be solved
similar to how the
>RSA private key handles it? That is, but requiring the
public key attributes
>on the object too?
Yes, but it evolved over time:
Step 1: Slightly abuse the derive functionality to get a
public-key
object
from the private-key object.
Objection: It's a bit of a misuse of derive, and in any case
we
don't need all
that, just the public components.
Step 2: Add public-key values to private-key objects.
Objection: Since the only real need for them is as
subjectPublicKeyInfo for
certificates, why not just return the SPKI directly?
Step 3: Add SPKI as an attribute.
>Finally, tangent to our DER discussion, using these public
key
blobs on the
>private keys would then REQUIRE all tokens be able to DER
decode them to make
>effective use of the public bits, contradicting the
assertion
that most
>tokens won't need to DER decode anything.
There's no need to decode them since the token never uses
them,
they're there
purely for the convenience of PKCS #11-using applications. In
fact there's no
need to store them at all, you just generate the SPKI on the
fly
from whatever
public-key data you have in the token.
Peter.
|