SoftHSMv2 does not list 0x210B CKM_AES_KEY_WRAP_KWP as a supported mechanism - when in fact it is implemented but misnamed as 0x210A.
PKCS11 v3.1: SoftHSMv2 implements RFC5649 but uses 0x210A CKM_AES_KEY_WRAP_PAD as the mechanism: it should be 0x210B CKM_AES_KEY_WRAP_KWP.
0x210A CKM_AES_KEY_WRAP_PAD is a different mechanism: the data is PKCS7-padded and then RFC3394 is applied. This mechanism is deprecated due to confusing implementations. The PKCS7-padded version is now 0x210C CKM_AES_KEY_WRAP_PKCS7 .
This is not terribly serious in itself — the RFC5649 mechanism is simply (mis)named CKM_AES_KEY_WRAP_PAD — but it affects our code testing and interoperability with Thales Luna which uses *_KWP constants.
SoftHSMv2 does not list 0x210B
CKM_AES_KEY_WRAP_KWPas a supported mechanism - when in fact it is implemented but misnamed as 0x210A.PKCS11 v3.1: SoftHSMv2 implements RFC5649 but uses 0x210A
CKM_AES_KEY_WRAP_PADas the mechanism: it should be 0x210BCKM_AES_KEY_WRAP_KWP.0x210A
CKM_AES_KEY_WRAP_PADis a different mechanism: the data is PKCS7-padded and then RFC3394 is applied. This mechanism is deprecated due to confusing implementations. The PKCS7-padded version is now 0x210CCKM_AES_KEY_WRAP_PKCS7.https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/pkcs11-spec-v3.1-os.html#_Toc111203510
This is not terribly serious in itself — the RFC5649 mechanism is simply (mis)named
CKM_AES_KEY_WRAP_PAD— but it affects our code testing and interoperability with Thales Luna which uses*_KWPconstants.