PKCS11 Future Work Items

Initially populated with items left on the 2.40/3.0 wiki, some may be done. TC to review.

Owners

Issue Summary

Detailed Description

Link to Proposal

.

Key lookup issues

Some of this is addressed by the CKA_ID/CKA_LABEL clarification in DocumentClarifications, but at the moment it's far too painful to deal with object lookup, and deletion is even worse (there can be multiple related objects linked to a given object, so saying "Delete the key MyKey" requires complex iterated lookups and probing to find associated public keys, private keys, and certificates to delete.

.

Key lookup issues

Some of this is addressed by the CKA_ID/CKA_LABEL clarification in DocumentClarifications, but at the moment it's far too painful to deal with object lookup, and deletion is even worse (there can be multiple related objects linked to a given object, so saying "Delete the key MyKey" requires complex iterated lookups and probing to find associated public keys, private keys, and certificates to delete.

ECC suport

The way ECC support is currently handled is awful. First, applications need to check a whole slew of CKF_EC_xxx flags to check whether the general type of curve that they want is supported. After that it's basically guesswork, if you want to use (say) the near-universal NIST P256 then after checking all the flags to see whether named Fp curves are supported the only way to tell whether you can actually do P256 is to encode an ASN.1 OID for that curve (!!!), set it as CKA_EC_PARAMS for an object, and then see whether you can perform an operation with the resulting object. As far as I can see the only way to use this is to hope that the more common curves are supported and fail if not.

This area needs a serious cleanup. There should be some means of querying whether standard curves are supported that only requires querying a CKC_xxx ('C' = curve) value, i.e. "is CKC_NIST_P256 supported?") without having to check assorted flags and then performing probing to see whether you can actually use that curve.

In line with this complexity, the bug density in PKCS #11 ECC implementations is higher than usual (see CommonBugs). For example one ECC implementation currently under evaluation claims to do signatures but not signature verification (so you have to take it on faith that if you see a signing key and associated cert, that the cert is actually valid), claims not to do NIST named curves (via the CKF_EC_xxx flags) but comes with sample code that uses them, and returns the catch-all template-inconsistent if you try and use the template given in the PKCS #11 spec.

Potential need for high-volume API

Many functions take session handles, which force serialisation through the session. Scatter/gather and select()-capability would be useful for high-volume use, currently this almost always requires the use of vendor-specific APIs.

Multiple Callers per Process

Some of the stuff needed to make multiple callers in a single process is longer term work: MultipleCallersPerProcess

Authenticated Attributes for Key Wrap

In 2.40 a new key mechanism was added to allow key attributes to be included (and authenticated) along with the wrapped key blob using RSA OAEP encryption (CKM RSA AES KEY WRAP). We should have a counterpart using symmetric key encryption, I propose to do it using the new AES GCM mechanism that was also added in 2.40. Full proposal here.

FutureWorkItems (last edited 2017-05-30 17:49:39 by bubbva3)