[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Latest revision to HSS spec with questions
Hi Michelle, looks good to me. I hope somebody else did also have a look and provided feedbackâ Wrt. the attribute names this is my opinion: Iff attributes are probably for a single attribute / key type only, the algorithm should be part of the attribute names. For Double Ratchet all attributes start with âCKA_X2RATCHETâ. Nevertheless, a new algorithm might come up with an attribute whose acronym is, for example, âHKSâ. So, we need to introduce
CKA_NEWALGO_HKS. When the algorithm name is left out the data type of the fields has to be the same for all algorithms using that field. This cannot be assumed. Therefore, my vote is for CKA_HSS_LMS_TYPE and CKA_HSS_LMOTS_TYPE. For the template it should be: CK_ULONG hssLevels = 123; CK_ULONG lmsTypes[] = { 123, ... }; CK_ULONG lmotsTypes[] = { 123, ...}; The definition of the actual attribute array can remain as is. Compare this with, for example, how CKA_ALLOWED_MECHANISMS is used in this test code:
https://fossies.org/linux/softhsm/src/lib/test/ObjectTests.cpp#l_672 The replacement for the explanation of the public keyâs CKA_VALUE attribute make sense. For the descriptions of
CKA_LM(OT)S_TYPES âmechanismsâ should be replaced by âencodingsâ or âtypesâ IMO. Also the number of the elements in the array must match CKA_HSS_LEVELS, which would be good to add there. Proposal: âThe number of encodings in the array
is the ulValueLen component of the attribute divided by the size of CK_ULONG. This number must match the CKA_HSS_LEVELS attribute value.â I hope to get an agreement in todayâs call. Regards, Daniel From: Michelle Brochmann <mbrochmann@infoseccorp.com>
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>
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 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!
Questions:
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]