RE: [pkcs11] Latest revision to HSS spec with questions

Michelle,

With âCK_ULONG lmsTypes[] = {123,...};â sizeof(lmsTypes) really returns the total size needed by the array and not the size of the pointer. Thatâs why we wrote âThe number of encodings in the array is the ulValueLen component of the attribute divided by the size of CK_ULONGâ. So, this is completely fine.

This is one of the few exceptions according to the C standard where an _expression_ that has type âarray of typeâ is not automatically converted to an _expression_ with type âpointer to typeâ.

This also holds for the address operator. So, both of the following lines will work since they both assign the same address to the pValue element in the CK_ATTRIBUTE struct:

{CKA_HSS_LMS_TYPES, lmsTypes, sizeof(lmsTypes)},

{CKA_HSS_LMS_TYPES, &lmsTypes, sizeof(lmsTypes)},

But semantically there is a difference: the first line assigns the address of the first element to pValue, the second lines assigns the address of the whole array to pValue. We actually mean the second since the whole array is the parameter and not just the first element. But since pValue is a void* this type information is lost anyway.

It seems weâre ignoring this subtle difference in the PKCS#11 spec completely and are using always the first version in our code examples. So, the last HSS draft is perfectly in line with the spec. And Iâve just noticed that the CKA_ALLOWED_MECHANISMS example Iâve referenced in my last mail is actually inconsistent since it uses & with CKA_ALLOWED_MECHANISMS but no & for CKA_VALUE.

tl;dr: Latest HSS spec is completely fine IMO.

(Ok, almost, there is a single â,â missing at the end of the CKA_VALUE line in the private key object example.)

Regards,

Daniel

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Michelle Brochmann
Sent: Mittwoch, 12. Mai 2021 22:55
To: Daniel Minder <Daniel.Minder@utimaco.com>; pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] Latest revision to HSS spec with questions (WARNING!!! S/MIME with incorrect signature)

Thanks again Daniel for the feedback. I have applied the requested modifications and uploaded the latest draft.

I did however have one remaining concern that Iâm hoping I can get feedback on:

What Iâm concerned about is the meaning of passing âsizeof(lmsTypes)â â this looks like it would be the size of the pointer, and *not* the size of the array. This does match the way we have treated the byte array for the CKA_VALUE attribute (which is the same as what is done for the ECDSA private key object). But the way we handle the arrays â passing the array pointer, and then sizeof(pointer) is different from the way we handle single value attributes, such as CKA_HSS_LEVELS, where we pass the pointer to the value, and also the size of the value â not the size of the pointer.

Given that this is how it is done elsewhere in the PKCS#11 spec, Iâm guessing itâs probably ok, but I just wanted to confirm.

Another minor issue â is it better to say CK_ULONG_PTR in the table as we currently do, or do we want to say âCK_ULONG arrayâ to match the entry below it that says âByte arrayâ?

Other than these two (perhaps non?) issues, I think everything is good to go!

Michelle

pkcs11 message