OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] CKA_PUBLIC_KEY_INFO


Title: RE: [pkcs11] CKA_PUBLIC_KEY_INFO
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? 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?

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.

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?

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]