Open armpribb opened 1 month 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.
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:
Let me know about anything I may have overlooked or what you think about this issue in general...