Strange CKA_VALUE_LEN handling in key encapsulation (ML-KEM) #885

I've been working on enabling ML-KEM in python-pkcs11. That project tests against SoftHSMv2 and opencryptoki. Unfortunately both of these implementations disagree on the handling of CKA_VALUE_LEN when calling C_DecapsulateKey, and after digging a little deeper, I think SoftHSMv2 is in the wrong here.

I think there are actually two bugs in play here.

Bug 1: C_DecapsulateKey rejects CKA_VALUE_LEN with CKR_ATTRIBUTE_READ_ONLY

C_DecapsulateKey calls CreateObject with OBJECT_OP_UNWRAP, which forbids setting CKA_VALUE_LEN:

SoftHSMv2 seemingly assumes that the intended output length is 32 bytes (i.e. the natural output length of the ML-KEM decapsulate operation) and returns that unconditionally.
Assuming the semantics of C_UnwrapKey in the spec also apply to C_DecapsulateKey, I believe CKA_VALUE_LEN should be allowed, and it's actually the only way to unwrap a key that is less than 32 bytes long.

Bug 2: C_EncapsulateKey stores a CKA_VALUE_LEN that disagrees with the actual key material

The created object inherits CKA_VALUE_LEN from the caller template, but at the same time, the byteLen in this code is initialised to 32 and never updated, so this branch is never taken:

Expected behaviour

Unlike C_UnwrapKey, C_DecapsulateKey doesn't take a key length parameter, only a ciphertext length, so CKA_VALUE_LEN is the only way to convey the expected plaintext length.
I think this is the way things should work given what the spec says:

• CKA_VALUE_LEN absent: produce a key of the full 32-byte ML-KEM output.
• CKA_VALUE_LEN present, value <= 32: truncate the key material to that length; both CKA_VALUE and the CKA_VALUE_LEN attribute on the resulting object must reflect the truncated size.
• CKA_VALUE_LEN present, value > 32: return CKR_WRAPPED_KEY_LEN_RANGE as required by the spec.

One could possibly also validate whether the resulting length makes sense for the mechanism requested (e.g. limit AES keys to 16, 24 or 32 bytes). As it happens, opencryptoki does this, and that's how I found out about this issue: the way the check is implemented over there errors out if CKA_VALUE_LEN is not present in the template.

I hope this makes sense.