OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 0-padding attribute values of Big integer data type


Hi,

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) ?

Thanks.

BR,
Patrick


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]