Inconsistency with PKCS#11 v2.40 CKM_AES_KEY_WRAP_PAD There appears to be some inconsistencies between the PKCS#11 v2.40 Current  Mechanism Specification and the specification for AES Key Wrap Pad as defined in SP800-38F.

First, according to PKCS#11:


  The mechanisms will accept an optional mechanism parameter as the Initialization vector which, if
  present, must be a fixed size array of 8 bytes, and, if NULL, will use the default initial value defined in
  Section 2.2.3.1 of [AES KEYWRAP].
  
  The type of this parameter is CK_BYTE_PTR and the pointer points to the array of 8 bytes to be used as
  the initial value. The length shall be either 0 and the pointer NULL, or 8, and the pointer non-NULL.


However, according to SP800-38F, the ICV2 value for AES-Key Wrap PAD must be four bytes in order to correctly pad the input to the cipher routine (section 6.3 algorithm 5).

Secondly, PKCS#11 specifies that CKM_AES_KEY_WRAP_PAD is used for Encryption/Decryption only, not for Wrapping/Unwrapping operations (Table 65, in section 2.14 in the PKCS#11 current mechanism specification).  This seems inconsistent with the goals of the AES KEY Wrap Pad algorithm.

So my questions are:


Is this a known inconsistency and has Cryptoki released any updates to how the CKM_AES_KEY_WRAP_PAD algorithm can be used?  I cannot find anything on Google but maybe I missed something.
In my PKCS#11 implementation, can my solution be to inform the user (through documentation) that the IV for CKM_AES_KEY_WRAP_PAD will be truncated to 4-bytes?
I know this appears to be out of spec, but can I in my PKCS#11 implementation allow the user to use CKM_AES_KEY_WRAP_PAD for Wrapping/Unwrapping as well as Encryption/Decryption.
The PKCS#11 technical committee is currently working on standard version 3.0. You can find the latest working draft here: https://www.oasis-open.org/committees/download.php/64968/pkcs11-curr-v3.0-wd09.docx

In fact, reworked section "AES Key Wrap" (now 2.16) solves your problems:


It allows all mechanisms to be used with Encrypt&amp;Decrypt and Wrap&amp;Unwrap.
It clarifies that CKM_AES_KEY_WRAP and CKM_AES_KEY_WRAP_PAD actually refer to NIST SP800-38F section 6.2 ("KW"), which in fact require an 8 byte IV.
It introduces new CKM_AES_KEY_WRAP_KWP, which is algorithm KWP of NIST SP800-38F section 6.3 you are looking for.


Header files for the working draft can be found here: https://github.com/oasis-tcs/pkcs11/tree/master/working/3-00-wd-01