[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Updated CKA_PUBLIC_KEY_INFO
On 05/30/2013 01:47 PM, Michael StJohns wrote:
...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.
One observation here is that the impact of the feature is widespread. Ideally, a proposal would be have a property that only a module needs to generate it, while the client can treat is as a binary blob (or perhaps vice versa). See bellow.
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.
I will accept some blame here for the late comments.
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.
I think I understand now some of the motivations behind the CKA_PUBLIC_KEY_INFO proposal. It is doing the "outsourcing" of the definitions to PKI standards. This makes it easier to define it in the PKCS#11 spec, but the reality is that It's unavoidable that one needs to manage public key-specific fields in algorithm-specific fashion, whether they are packed in a DER of CKA_PUBLIC_KEY_INFO or go directly into the PKCS#11 object.
The advantage of the latter is that the fields can be copied verbatim. To me, that's a fundamental benefit that is lost with CKA_PUBLIC_KEY_INFO proposal for implementers.
E.g. what I was proposing is that the the DSA public key has CKA_VALUE that will need to *copied* into the corresponding attribute of the private key with memcpy. That's it. With CKA_PUBLIC_KEY_INFO I need to wire the DER packer to accomplish this and learn OIDs that go along. There is certainly more to verify as well.
The addition of the DER encoding over to the set of CK_ATTRIBUTE may have some aesthetic value, given that CKA_PUBLIC_KEY_INFO is a single field, but like you said earlier, CKA_PUBLIC_KEY_INFO needs to be created and whoever creates it will need to deal with this complexity. Overall, the DER is an addition that is not necessary.
Note that the flip side of this is that the PKCS#11 then becomes well-specified and remains (mostly) self-contained.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.
If the structure CKA_PUBLIC_KEY_INFO is complex and its definition is elsewhere, consider hidden dangers when one side creates the structure that another one refuses to validate it.
On the ECC side, I would definitely respectfully insist on using the uncompressed representation of the point as a canonical form (at all cost; unless this is prohibited, which would be very odd: consider IPR issues) ...
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.
Most of my experience is with RSA keys and there there is no need for DER at all. Still, the sequence for {r,s} is unfortunate. Nonetheless, it's easy to hand-fill SEQUENCE { INTEGER r, INTEGER s}. It's in the same category with PKCS#1 tag for signatures. This would be acceptable to me.
Note the other fields you mention are for the CKC_X_509 object. Obviously, whoever handles the DER-encoded object is expected to support DER. As a side note, please observe that CKA_VALUE of CKC_X_509 actually has less impact than CKA_PUBLIC_KEY_INFO (assuming that CKA_PUBLIC_KEY_INFO is supported). Only the client may heed to understand the certificate, while for the module it's an opaque blob.
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.
While the widespread use of ASN.1 is undisputed, I will observe that PKCS#11 interface fundamentally works with a set CK_ATTRIBUTE. IMO CKA_PUBLIC_KEY_INFO makes the leap into DER world too quickly.
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.
OK, if you say that this is a proper procedure to handle this.My comments here then are for the criticism of the CKA_PUBLIC_KEY_INFO. It's important, though, to keep the alternatives in mind when one evaluates the merits of the CKA_PUBLIC_KEY_INFO.
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.
PGP Desktop is known to work with any brand of smartcard and HSM we could get out hands on for a over a decade (It only does RSA keys on tokens). There is no DER encoding capability needed for PGP keys generated on the tokens / HSM,
If keys are X.509-based, i.e. a key pair has an X.509 certificate, that's another story.
Fundamentally, the major feature of the PKCS#11 interface is that it provides access to private keys that are locked in hardware. DER/ASN.1 encoding is an orthogonal "formatting" that can be done in the application.
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.
A vendor's goal is to support the broadest client base. I will agree with you here. That's why I think that tweaks to CKA_PUBLIC_KEY_INFO proposal to constrain the parsing of CKA_PUBLIC_KEY_INFO to the module would strengthen this proposal.
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.
Thank you.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]