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

[armpribb]

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]

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")

• My mood was more like "The more the merrier!". If somebody wants to use the key later for (un)wrapping it should be possible.
• It works with all other libs. They accept the flag and I'm pretty sure not all of them support key wrapping.
• You could also accept the flag and later fail on an attempt of C_WrapKey C_UnwrapKey until it is supported by your lib.
• You could drop the flags by a manufacturer-special exception like

  xca/lib/pkcs11.h

  Lines 100 to 109 in 128f7d9

  	bool force_keygen_named_curve() const
  	{
  	// Workaround for "www.CardContact.de" bug
  	return manufacturerID() == "www.CardContact.de";
  	}
  	bool need_SO_for_object_mod() const
  	{
  	// Yubikey Need SO Pin to modify objects
  	return manufacturerID() == "Yubico (www.yubico.com)";
  	}

A pull request will be accepted.