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?