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] Updated CKA_PUBLIC_KEY_INFO


On 5/30/2013 3:10 PM, Andrey Jivsov wrote:
On 05/30/2013 08:14 AM, Michael StJohns wrote:
On 5/29/2013 7:07 PM, Andrey Jivsov wrote:
Here are my concerns about CKA_PUBLIC_KEY_INFO, listed as features
with comments.

1. Linking public key / private key / certificate.

The concern here is that there are current mechanisms that can
accomplish the same, such as CKA_ID. In my experience CKA_ID works in
practice. Relational database tables are routinely linked by a
"foreign" key. Why not tighten CKA_ID it to make it perfect?
This literally has NOTHING at all to do with linking these three
objects.  It may be a side effect of that the attribute can be used for
this purpose, but it's not the primary reason for doing this.

OK, so you are saying the primary reason is to get a public key from the private key. I had to guess.

No need to guess, this has been stated multiple times going back to the first exchange between me and Peter.



2. CKA_PUBLIC_KEY_INFO is a canonical ID, aka a key fingerprint.

That is, it's the same ID for a given key pair. A nice idea, but this
restriction adds complexity. C_GenerateKeyPair must generate
CKA_PUBLIC_KEY_INFO (module's responsibility), while C_CreateObject
and C_Unwrap will need to supply it (client's responsibility).
No.  Please see the revised version.  There is no requirement for a
module to be able to parse the DER, but if it does, it needs to verify
consistency.

...that's what's what the optional "means". I am focusing on cases when these structures are created.

The thought here is: If the module must have the code to parse/make
CKA_PUBLIC_KEY_INFO for C_GenerateKeyPair, it could do so for the
other two and free up the client.
No. This is not an artifact of C_GenerateKeyPair, it is an underlying
artifact of either the public or private key.  For a public key, its a
simple matter to throw the various components into a DER template.  For
the private key, there's generally a math problem to be solved to get
the public key.  Of course for C_GenerateKeyPair, you're deriving the
public key at the same time you're generating the private key, so it's
pretty easy to make a note of that data and save it with the private key.

I think you are talking about the module side. If your description above applies to what a module suppose to be doing for the implementation of the C_GenerateKeyPair -- I agree with you and was not referring to these steps.

I was saying that for the other APIs: C_CreateObject, C_Unwrap, if I understand this correctly (and this is how Robert Relyea understood it too), it's the client who suppose to create the DER and pass the DER blob to these two APIs.

So, C_GenerateKeyPair -- module creates it; C_CreateObject, C_Unwrap -- client creates it. Is my understanding correct?
Yes.

The ability to supply CKA_PUBLIC_KEY_INFO for C_CreateObject (and C_UnwrapKey) was more suspenders and belt to deal with the case where the token may not support generation of a key pair, but supports import of the private key. I don't know of any tokens like this, but I wouldn't be surprised to find them. I'm happy to remove it if it no one needs the functionality.



3. DER support.

Does this introduce dependency on ASN.1 / DER? If the answer is no,
the PKCS#11 standard will need to specify the memory dump of ASN.1/DER
SubjectKeyIdentifier, the appropriate OID for the public key, and the
spec for how to inject the subjectPublicKey OCTET STRING into the
structure. This will need to be done for each key type. It seems like
a maintenance burden.
No.  The document specifies SubjectPublicKeyInfo as the standard
representation.  It is up to the implementer to determine how he wants
to form that implementation - e.g. by template, by DER encoder, by
magic, etc.  Each of the key types has a document which specifies how a
public key is encoded into a SubjectPublicKeyInfo - that doesn't need to
be written yet again.

Let me suggest an alternative. Why can't a few already defined attributes be added to the private key so that the public key can be reconstructed?

Please see the first and second messages on this topic - dated back on 4/2 I believe (see the reference in my last note to Robert). Basically, Peter proposed the use of C_DeriveKey, I countered with the proposal you just suggested (adding per-object-type attributes) and the proposal I ended up submitting. Peter agreed that CKA_PUBLIC_KEY_INFO was the better choice and I went ahead and wrote and submitted.

The alternative, as I said above, is going into each and every definition of a private key and adding an attribute specific to that private key class - e.g. CKA_EC_PUBLIC_POINT, CKA_DSA_PUBLIC_INFO, etc. AND specifying the format of that data (e.g. an EC point in X9.63 uncompressed point form, a <mumble blob> formatted per <mumble> FIPS186-3 spec). And then making sure as new public key types are added in the future that we make sure they follow this convention. A lot more text to write, to get right and to ensure can't be misinterpreted.


PKCS#11 is written to communicate using a set of CK_ATTRIBUTE structures. It's a step away to start passing the information in DER-encoded structures.

We already do some of this. See for example the format of an ECDSA signature - SEQUENCE { INTEGER r, INTEGER s}. See also CKA_OBJECT_ID, CKA_SUBJECT, CKA_ISSUER, CKA_OWNER, CKA_AC_ISSUER, etc etc etc.

Like it or not ASN1 is pretty much the language of cryptography because it's fairly unambiguous. I'd actually like it if I could get ASN1 signature algorithm OIDs as part of the mechanism info - rather than trying to guess exactly which document describes the underlying implementation.



In particular:

CKK_RSA: private key must have CKA_PUBLIC_EXPONENT.

Define a key-specific attribute for key types where this is needed. (e.g. DSA public and private keys use CKA_VALUE, perhaps add CKA_PUBLIC_VALUE, which is a copy of the CKA_VALUE of the public key)...


That ship has sailed (way back in April even). If you feel strongly about this, please feel free to submit an alternate proposal.


My suggestion is to try think about removing the requirement that the
client must create DER of CKA_PUBLIC_KEY_INFO. It SHOULD "replay" it
whenever possible, but not required to construct.
Again - implementation detail not appropriate to the document. And
someone somewhere has to create the DER.

It's not accurate to say that PKCS#11 is not viable without understanding of DER or X.509. Such DER-less applications exist. Think about PGP or SSH keys on the tokens / HSMs.

It's not accurate to say that PKCS11 is viable without an understanding of DER or X.509. If you're programming against an HSM, it's pretty much a requirement that you understand how to convert to/from PKCS11 and various BER/DER representations.

And saying that an HSM vendor need not understand this seems so far wrong as to make me think I'm misunderstanding what you're saying.



The reason for the burden shifted to the module is because of
C_GenerateKeyPair (if one wants a transnational behavior or a single
call).
Not really.  But this is such a slippery statement that I'm going to
avoid trying to parse it and refute it, because I'm not quite sure I
understand exactly what you mean.

Hopefully, my earlier comments clarify this.






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