search

chris2511 / xca

X Certificate and Key management
http://xca.hohnstaedt.de
Other
1.56k stars 205 forks source link

feature request: do not set wrap/unwrap attributes in public/private key templates when generating new key pair (or make it configurable) #564

Open armpribb opened 4 months ago

armpribb commented 4 months ago

Issue

We are developing & maintaining a PKCS#11 library and use it together with XCA to manage keys and certificates on our hardware token. Unfortunately we do not support key wrapping/unwrapping in our library and token (yet).

The cryptoki specification states in section 5.13 Key management functions: "[...] If a call to C_GenerateKeyPair cannot support the precise templates supplied to it, it will fail and return without creating any key objects. [...]".

So in order to be compliant with the specification we currently have to fail any key pair generation operation initiated via XCA, as XCA's current implementation has the CKA_WRAP attribute set to true in the public key template and the CKA_UNWRAP attribute set to true in the private key template (see lib/pkcs11.cpp). That means we cannot use XCA with our PKCS#11 library to generate key pairs on our hardware token and have to use separate tools (e.g. pkcs11-tool, or proprietary tools).

Is there a specific reason why XCA sets the wrap/unwrap attributes in the public/private key templates? They are not mandatory but optional, according to the cryptoki mechanism specification (see section 2.1.4 PKCS#1 RSA key pair generation): "[...] Other attributes supported by the RSA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values. [...]"

Or is there another feature of XCA that I am not aware of that requires these attributes to be set to true?

Possible solution / Feature Request

I could think of two possible solutions:

  1. Do not set these attributes in the public / private key templates for key pair generation operations at all and let any PKCS#11 library apply their own sensible default. (That's what we currently do, we patched out the two lines lines and built our "custom" XCA for internal usage. We would rather not ship a forked XCA though, as we would prefer if users of our library are able to use the official one).
  2. Make the wrap/unwrap attribute(s) configurable in the UI (e.g. via checkbox) in the generate key pair dialog.

Let me know about anything I may have overlooked or what you think about this issue in general...

chris2511 commented 4 months ago

Storing keys on the token is done with the same flags. As long as you also support importing private keys in your lib it should be patched there, too. My own commit messages are not very helpful (despite the fact that I tell everyone "Write proper commit messages")

A pull request will be accepted.