Thank you Daniel for the feedback.
Iâve made almost all the recommended changes to the spec but would like to confirm some things:
I am using CKA_HSS_LEVELS and CKA_HSS_KEYS_REMAINING, however, I left the HSS out of CKA_LMS_TYPE, CKA_LMOTS_TYPE, and CKA_VALUE. My reasoning for the first two is that LMS/LMOTS implies HSS (as RFC 8554, section 6 says: âSince HSS with L=1 has very little overhead compared to LMS, all implementations MUST support HSS in order to maximize interoperability.â) and for CKA_VALUE, to match the many other places it is used, for example in Elliptic curve private key objects. I will add the âHSSâ to these if that is preferred.
For the CK_ULONG_PTR, can that be passed directly in the template or should the reference to it be passed? Currently I am passing the reference. I think that is all that is needed for the private key template example to compile, but I would particularly appreciate feedback on the highlighted portions here:
In addition, would a replacement such as that shown in red here be preferable to actually spelling out the contents of the public key value, since it is given in RFC 8554?
And finally, Iâd like to check that the description of CKA_LMS_TYPES and CKA_LMOTS_TYPES in the âHSS Private Key Object Attributesâ table shown here makes sense:
Thanks! I have updated the latest not-quite-finalized version in the usual spot, and will update it as I get feedback.
Michelle
From: Daniel Minder <Daniel.Minder@utimaco.com>
Sent: Wednesday, April 28, 2021 2:21 PM
To: Michelle Brochmann <mbrochmann@infoseccorp.com>; pkcs11@lists.oasis-open.org
Subject: 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
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO
This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.