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

Hi Michelle,

some quick thoughts. Overall, looks quite good.

I would use prefix CKA_HSS_ for all attributes. Then, itâs clear to which key they belong and there will be no collision.

The CKA_LEVELS and CKA_HSS_LEVELS of public and private key are actually the same thing. So, they can have the same name?

What about footnotes 2+4 for the other three attributes of the public key? They must not be given on createobject and generatekeypair.

Footnotes 2+4 also apply to CKA_KEYS_REMAINING of the private key, and footnotes 1+3 to LEVELS and LM(OT)S_TYPES.

Since CKA_VALUE for the private key is vendor defined we cannot give any value here. But in fact, none of the other templates in the spec gives a value here, even if it would be possible.

Do we need to prevent people from shooting themselves in the foot by requiring CKA_SENSITIVE==true and CKA_EXTRACTABLE==false? In that case, also CKA_COPYABLE must be false.

IMO if a value is part of the template, the mechanism (here CKM_HSS_KEY_PAIR_GEN) does not contribute them to the key (here LEVELS and LM(OT)S_TYPES to the private key).

For LM(OT)S_TYPE a CK_ULONG_PTR is fine. The description should be similar to, for example, CKA_ALLOWED_MECHANISMS. âThe number of CK_ULONGs in the array is the ulValueLen component of the attribute divided by the size of CK_ULONG.â And the code of the template needs some rework to compile.

It should not be a problem if an attribute is changing. Look at the monotonic counter objects. No extra mechanism to retrieve CKA_KEYS_REMAINING should be necessary.

Best,

Daniel

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Michelle Brochmann
Sent: Sonntag, 25. April 2021 16:47
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Latest revision to HSS spec with questions (WARNING!!! S/MIME with incorrect signature)

Hi all,

Iâve uploaded my latest version of the HSS Spec. It isnât quite in its finished form as I have a few questions. Iâll describe the changes I made here â if something is different than what was intended please let me know!

Removed HSS_PARAMS from the public key object since this information isnât even available from the public key.
Added CKA_LEVELS, CKA_LMS_TYPE, and CKA_LMOTS_TYPE attributes to the public key object with the assumption that the device will parse the public key and make these values easily available to the application. The latter two attributes are the information about the top level tree which is contained in the public key, and which the application might use to decide what it thinks the security level of the scheme is.
Added CKA_HSS_LEVELS, CKA_LMS_TYPES, and CKA_LMOTS_TYPES attributes to the private key object. The latter to attributes are of type CK_ULONG_PTR.
Removed CKA_HSS_PARAMS from the private key object as we now return its contents in separate, more conveniently accessible attributes.
Added CKA_KEYS_REMAINING to the private key object.
Modified the sample private key template to contain the new CK_HSS_LEVELS, CK_LMS_TYPES, and CK_LMOTS_TYPES.
Switched from using âCK_LMOTS_TYPEâ and âCK_LMS_TYPEâ to âCK_ULONGâ since I donât think there is a need for a special typedef. (?)
Added CKA_KEYS_REMAINING attribute to the private key object. (Not sure this is the right way to do it, please see my question below.)
Modified the description of mechanism contributions in the HSS key pair generation section.

Questions:

For the sample template for creating an LMS private key object, should we be passing in the CKA_VALUE? What would it contain when the template is used for key generation?
Should CKA_KEYS_REMAINING be an attribute in the private key object, or should there be a separate mechanism that returns it (since it changes with use)?
I was not sure exactly how to give the example input for the CK_ULONG_PTR inputs lmsTypes and lmotsTypes in the template. I used â[{123],â]â. Is there a better choice?
I wasnât sure if I should call the levels attribute âCKA_LEVELSâ or âCKA_HSS_LEVELSâ. (I was actually inconsistent from table to table in this as well.) What would be best? Similarly for âCKA_LM(OT)S_TYPESâ vs âCKA_HSS_LM(OT)S_TYPESâ.

The only new definition that is needed is the CKA_KEYS_REMAINING attribute, of type CK_ULONG.

I also need to let you all know that I will be moving to a different industry (biometric data!) in a few weeks, so May 14 will be my last day with ISC. Iâve enjoyed working with all of you and I really appreciate all the support you have given me in developing the HSS spec! Iâm hoping I can get it into final form â or at least a form where only a few tweaks will be needed before I leave! 😊

Michelle

pkcs11 message