|
On 4/17/2013 11:26 AM, Burns, Robert
wrote:
Mike,
Thanks again -- I do appreciate the time you're taking on this
dialog.
So we're in violent agreement that the proposal for SPKI requires
formatted marshaled data that the token has to deal with (e.g.
definitely not opaque).
Never been a disagreement. The only disagreement has been how much
work this is.
We're also in agreement that there is nothing in P11 which
requires
that public keys and private keys be inextricably tied together
(which is a good thing and a desirable trait as there are real use
cases for having access to only one or the other).
*buzzer sounds* Wrong answer. I agree that the current version of
P11 is (mis)defined this way.
This started out specifically to ensure that the public key was
always available for the private key. That's the minimal
requirement. Someone else said "what about public keys and certs"
so I added language for those.
The CKA_PUBLIC_KEY_INFO is an *attribute* to one of three types of
objects. It does NOT "inextricably tie..." public and private keys
together. It CAN be used to generate a public key object from a
private key object if necessary.
Therefore, my opinion is that the CKA_PUBLIC_KEY_INFO proposal
does
not add anything that is already there today and only increases
the
implementation requirements on tokens.
Please go back to Peter's original discussion. If all you have is a
EC private key object, there is no defined way to get the public
key. If all you have is an RSA private key object and that object
is missing the CKA_PUBLIC_EXPONENT attribute, you have no way to get
the public key. I haven't looked at the rest of the key types.
CKA_PUBLIC_KEY_INFO provides a standard mechanism to read out the
public key info for a private key.
It does change what needs to be stored with private keys slightly,
but improving cohesion seems useful.
For every use case where the
calling API can provide the SPKI info, the application can decode
it itself and create a separate public key object. For those cases
where the token generates a key pair, the public key is (by
definition) available at that instant and can be extracted by the
application, and bundled into an SPKI blob, and then assigned to
the CKA_ID field of a private key object as required.
A typical use case is to delete the public key after generation, and
rely on the certificate. Sometimes data gets lost. We're trying to
avoid having that happen.
Sometimes you can't actually find the public key on the token after
its generated (generate today, comeback tomorrow and try and figure
out which public key matches up with that private key, and that
program is written by someone else).
This is an application use case issue, not a token issue (or a
problem with the P11 model). This is a corner case that can be
easily solved by any application, if implemented correctly.
Nope. It is a data consistency problem that lacks enforcement by
P11 to the detriment of real world usages.
Thanks,
Bob
-----Original Message-----
From: Michael StJohns [msj@nthpermutation.com]
Sent: Tuesday, April 16, 2013 09:11 PM Eastern Standard
Time
To: Burns, Robert
Cc: 'Peter Gutmann'; 'pkcs11@lists.oasis-open.org'
Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO
On 4/16/2013 6:51 PM, Burns, Robert
wrote:
Mike,
Firstly, the word 'opaque' means that the token has no
requirement
to decode/dissect/encode/interpret the data stored in that
object.
Your descriptions require both encoding and decoding of this
data
-- that is the opposite of 'opaque'. So no, as you've described
it,
this field is not opaque.
I said that CKA_VALUE on an X509 cert object was opaque. I
stand by that statement. There is no requirement in PKCS11 to
enforce that this object actually parses as X509 (or WTLS or X509
attribute cert, etc, or maps to a private key).
I was NOT referring to CKA_PUBLIC_KEY_INFO. But as both Peter
and I have said, in most of the RSA cases, and in all of the ECDSA
cases, both the parsing of such DER encoding and the encoding of
such data are fairly trivial.
Secondly, this attribute is on ALL public and private key
objects,
not just RSA -- so a use case for RSA rings
hollow.
Still don't quite understand this. For EC private keys, you
can *always* generate the public key. I don't know if this is
the case for DH keys, for DSA keys or for GOST keys - I just know
that there is at least one form of RSA private key where you can't
regenerate the public key. And if this attribute is going to
be implemented for C_CreateObject for private keys, you need to
insure coherence between the private key and the public key.
Why is this such a difficult concept?
Thirdly, if the APPLICATION has the subject public key info
data,
it can itself decode it and provide the necessary public
attributes
during C_CreateObject() -- why is this the token's
responsibility?
This doesn't make sense. Furthermore, if the application does
not
have the relevant fields, then too bad so sad -- they can't
create
the object then.
Because the entity that stores the key, may not be the entity that
retrieves the key. If the token doesn't understand the
CKA_PUBLIC_KEY_INFO attribute for C_CreateObject for private
keys then it throws an error. If it does understand the
attribute, then it has to do minimal validation that the data in
this attribute matches the private key.
Seems like we're hacking P11 to support poorly constructed P11
applications, and that just seems like the wrong approach to
me.
Nope. P11 does NOT require/enforce that you always have both
the public and private key objects on the token. We've
already talked about the whole CKA_ID and CKA_LABEL mess where it
may actually not be possible to relate the the public and private
keys that DO exist to each other and to a certificate.
The whole idea here is to place key pair information on the
private
key. It probably should have been there all along, but I
can't fix 2.20 and before.
Later, Mike
Bob
-----Original Message-----
From: Michael StJohns [msj@nthpermutation.com]
Sent: Tuesday, April 16, 2013 03:31 PM Eastern Standard
Time
To: Burns, Robert
Cc: 'Peter Gutmann'; 'pkcs11@lists.oasis-open.org'
Subject: Re: [pkcs11] CKA_PUBLIC_KEY_INFO
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.
|