Short Term Work Items

This page documents short term work items for possible inclusion in the initial (2.40?) version of the PKCS#11 spec produced by this technical committee.

Obtaining public key components for private keys

Due to the overloading of CKA_VALUE for y in public DLP objects and x in private DLP objects, it's impossible to obtain public key components from private-key DLP objects. This leads to awkward workarounds like trying to find a certificate corresponding to the private-key object and parsing the value from that, or performing a modexp using the x value to recover the y value (which doesn't work if you don't have your own native crypto code outside the PKCS #11 library or your token supports the private operation but not the corresponding public one, see DocumentClarifications). For ECDSA it's even worse, the private-key object doesn't contain CKA_EC_POINT so it requires even more convoluted processing in order to obtain the information.

Consider the following situation (based on a true story): A CA ships out tokens with ECDSA private keys pre-loaded into them (since they're subject to stringent signature-legislation-based requirements for key generation and can't use the onboard keygen) to users, who are given the token PIN via a separate channel. They then apply for a certificate from the CA, with the ability to sign the request being used as proof-of-possession of the private key. This works fine when used with the CA's systems during testing.

Problem is that since third-party systems don't have access to the public-key material that the CA's systems do (since the token only contains a private key), they're useless once shipped to anyone else. This problem never occurred with the RSA keys that were originally used, since they don't have this weird asymmetry of key components.

One solution to this is to provide a new C_DeriveKey() mechanism CKM_GET_PUBLIC_KEY which, given a private-key object, returns the corresponding public-key one. This is new functionality rather than a clarification, but it's so desperately needed that it should be added to 2.30 if possible.

A much better solution though would be to require that private-key objects make available the public-key data required for things like certificate requests in order to avoid this problem in the future, as RSA already does. Is there any reason why DSA/ECDSA don't follow the pattern established by RSA keys?

For now this doesn't even require a change in the specification, if vendors could just ignore the fact that CKA_EC_POINT and CKA_EC_PARAMS are only valid for the ECC public key that would be a good start. For DSA it's a bit more difficult since CKA_VALUE does two completely different things, and would require the addition of a new attribute.

The specification should also include guidelines for mechanism developers warning them against doing this (making it impossible to derive public keys from private keys) in the future.

CKA_CERTIFICATE_CATEGORY and CKA_JAVA_MIDP_SECURITY_DOMAIN constants

We should define Missing constants for CKA_CERTIFICATE_CATEGORY. And perhaps also CKA_JAVA_MIDP_SECURITY_DOMAIN.

Constant for (CK_ULONG)-1

PKCS#11 uses (CK_ULONG)-1 all over the place. We should have defined constants for null/empty/not-set values, either a universal one like CK_INVALID or CK_NULL or ones that follow the existing naming pattern. Currently it's useful to have (at least) CKM_NONE, CK_OBJECT_NONE, and CKA_NONE.

Constants should be unsigned longs

All of the constants in Appendix A (and the headers) should have 'UL' after them. This makes a difference when applications use these constants in places where they do not get cast, such as passing them to varargs functions. Seen crashers in the wild because of this.

Multiple Callers per Process

Some of the fixes on the MultipleCallersPerProcess long term page are appropriate for short term work.

ShortTermItems (last edited 2013-04-02 04:46:16 by pgutmann)