On 4/16/2013 11:33 AM, Burns, Robert
wrote:
Peter,
So going back to my original thought, perhaps the way forward is
to
add some sort of opaque attribute to public/private/certificate
objects which can be application defined?
The CKA_VALUE attribute of a certificate object is opaque. It's
just by convention an X509 (or WTLS or xxx) encoded blob.
That way, it could be
used to interlink all three (e.g. assigning the hash of the public
bits) for easy lookup, or could be used to hold the SPKI info in
your cases?
Seems like a win-win that keeps it lite on the P11 spec side (e.g.
won't need language about how to interpret, parse, etc.) and
affords the applications the ability to use this attribute as
needed -- furthermore, we could make it required, but default to
'empty' making the implementation less ambiguous.
Possibilities attribute names: 1) CKA_KEYPAIR_INDEX, 2)
CKA_KEYPAIR_ID, 3) CKA_KEYPAIR_INFO -- other suggestions?
This is what CKA_LABEL and CKA_ID were supposed to be used for. And
some applications do use them in a way that does the linking you
need.
What do you think?
Mostly no.
Mike
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.
|