RE: [pkcs11] Recent Comment

All,

It seems pkcs11-base is underspecified here. IMO leading 0 bytes should not be allowed:

Imaging there is a public RSA key with {0x00, 0x01, 0x00, 0x01} stored as modulus. Now, you export this key. Export requires DER encoding, which removes the leading 0. When you import the key at another token this results in modulus {0x01, 0x00, 0x01}.

So, the same happens as with Jonathanâs previous EC key example: you need to search for both {0x01, 0x00, 0x01} and {0x00, 0x01, 0x00, 0x01} (and even more leading 0s) to find all keys with modulus 0x10001. Or a token silently removes leading 0s on import so that the first token in the example already stores the same modulus as the second token â and the same should happen when searching for such a modulus.

However, this seems cumbersome from an implementers point of view. Maybe we should just forbid leading 0s here.

Best,

Daniel

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Tony Cox
Sent: Donnerstag, 11. Juni 2020 04:55
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Recent Comment

Hi folks,

The following was sent to the pkcs#11 comment list (copied below for convenience). We agreed to discuss this on our next call.

pkcs11-base (4) defines attribute values of Big integer data type as follows:
"a string of CK_BYTEs representing an unsigned integer of arbitrary size, most-significant byte first (e.g., the integer 32768 is represented as the 2-byte string 0x80 0x00)"

Does "most-significant byte first" in this context mean that an Big integer attribute's pValue must actually point to the most-significant byte, or may pValue point to a buffer of arbitrary size holding the big-endian encoding of the number (i.e., aligned to highest address and 0-padded from lowest address) ?

Regarding the example from the above definition:

With respect to pkcs11, is an attribute with pValue pointing to {0x80, 0x00} and ulValueLen=2 the unique representation of 32768, or
would an attribute with {0x00, 0x00, 0x80, 0x00} and ulValueLen=4
be a valid representation of 32768 as well ?

If not, are implementations ecouraged to still handle such values (for robustness reasons) or to reject them (with an appropriate error code e.g., template invalid) ?

You can view the original comment at https://lists.oasis-open.org/archives/pkcs11-comment/202006/msg00002.html

Best Regards,
-Tony Cox

pkcs11 message