Allow call with null pointer for handle key and template

[placintaalexandru]

Some calls to Thales Luna HSMs allows the following call of C_DeriveKey:

const CK_RV rv = C_DeriveKey( session, &mech, parent, NULL, 0, NULL );

One example is when trying to do bip32 derivation using CKM_BIP32_CHILD_DERIVE CK_BIP32_CHILD_DERIVE_PARAMS. The call works as follows:

• pTemplate and phKey are null pointers
• private and public key handles are found in CK_BIP32_CHILD_DERIVE_PARAMS.hPublicKey and CK_BIP32_CHILD_DERIVE_PARAMS.hPrivateKey

At the moment this is not expressable by the cryptoki crate so I was thinking it would be nice to allow it.

I tested this against a Thales Luna Network HSM

If there is interest in this, I can work on making the tests pass as well, which is trivial

Downsides

1. It breaks the API of derive_key
2. When allowing the above call, the returned handle contains 0 as value so the return type should be changed as well to better reflect user's intention

[hug-dev]

Hello!

Would be nice if cryptoki could support this as well!

The intended use of the C_DeriveKey function with this mechanism is so different from a "normal" call that I am wondering if we should really modify the generic wrapper function in a big way to allow that... Specifically, as you said, since we would also need to return some kind of Option<ObjectHandle> (to make it safe) and also indicate that the phKey parameter should be NULL!
The hard part is that this is also a vendor defined mechanism so we can't really make a special case just for this one.

To make this cleaner, maybe we should add a new derive_key variant (under a new feature maybe?) that would have the presets you wrote: NULL pTemplate and phKey and not returning anything.

What do you think?

[wiktor-k]

I wonder if this could be:

Suggested change

	template: Option<&[Attribute]>,
	template: impl Into<Option<&[Attribute]>>,

and then somewhere below:

let template = template.into();

This would allow existing clients to use normal syntax and also allow passing None.

Example in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e16ba050b6c7d7736801d3b552e3dbd

(it seems it requires explicit lifetime there)

[placintaalexandru]

Thank you for wiligness to support this, since it's something vendor dependent ^^'

I was sharing the same idea @hug-dev , but since IDK if there would be any situation when the user would need both I was thinking maybe the following:

// current one remains unchanged
pub fn derive_key(...) { ... }

#[cfg(feature = "SOME_MEANINGFUL_NAME")]
pub fn derive_key_vendor(...) { ... }

[hug-dev]

Thank you for wiligness to support this, since it's something vendor dependent ^^'

I was sharing the same idea @hug-dev , but since IDK if there would be any situation when the user would need both I was thinking maybe the following:

// current one remains unchanged
pub fn derive_key(...) { ... }

#[cfg(feature = "SOME_MEANINGFUL_NAME")]
pub fn derive_key_vendor(...) { ... }

Yes I think that is a reasonable approach! Or at least a good way to start until more of those appear and we see a better way to do it.
In the implementation one could check if the mechanism is not vendor defined and then re-use the other one.