[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] HSS discussion
Greetings all, Apologies, I was off on Friday and Monday. The restriction to at most 8 layers is noted in SP 800-208 in Footnote 3 on page 9, Section 3.3 (I do not like that they make it a footnote). “While this section only describes two-level trees, HSS allows for up to eight levels of trees, and XMSSMT
allows for up to 12 levels of trees.” And it is in the main body of the RFC 8554 text (section 6)
public key, private key, signature, and identifier. The number of levels is denoted as L and is between one and eight, inclusive.”
Aside: I tend to use “levels” to refer to the horizontal slices within a given tree, and “layers” to refer to the horizontal index of the tree. Best regards, Philip From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Michelle Brochmann Indeed, I also couldn’t find anything in either RFC 8554 or the SP 800-208 limiting the number of levels, besides the signed_keys array in the XDR for the signature and in the implementation. If there is no limit, a fixed
array (as I originally had in the CK_HSS_PARAMS) is not a good way to go, but the “*TYPE_PTR” or “*ALGORITHM_TYPES” array would accommodate it.
Before moving forward, I believe I need the following information:
Michelle From: Tim Hudson <tjh@cryptsoft.com>
Good point - that we need to have L (levels) of the input parameters for key generation. I noted that your previous proposal had an allowance for levels in the range 1-8 and I don't see that limitation in the RFC - does that exist? Also in the RFC I note within hss_signature there is a signed_keys<7>
which would seem to indicate a length limitation of 8 does exist. The Cisco reference code certainly has that length limitation wired into it. If there is no limitation on levels then we would have to have this as arbitrary sized. Option 1 (parameters) typedef CK_ULONG CK_HSS_LEVELS; typedef CK_ULONG CK_LMS_TYPE; typedef CK_ULONG_PTR CK_LMS_TYPE_PTR; typedef struct CK_HSS_PARAMS { (or below without the Hungarian prefix notation and using precisely the same naming approach from RFC8554 which would be my
preferred approach) typedef struct CK_HSS_PARAMS { Option 2 (no parameters, only attributes) CKA_HSS_LEVELS (CK_ULONG) CKA_HSS_LMS_ALGORITHM_TYPES (CK_ULONG ARRAY) CKA_HSS_LMOTS_ALGORITHM_TYPES (CK_ULONG ARRAY) CKA_HSS_DIGEST_MECHANISM_TYPE (CK_MECHANISM_TYPE) This raises an interesting question in that we haven't got the concept of attributes that are a variable array of CK_ULONGs as such - although I don't see a problem with that being supported myself. And when it comes to the public key value itself, in the XDR in the RFC the public key does not contain the details of the input parameters to key generation - it only has the top-level information - i.e. it is a single
LMS and LMOTS value in the public key for HSS. The other details are maintained within the private key information (which includes the sets of public keys which don't need to be kept secret but aren't included in the noted representation) so to know the properties
of the HSS keypair as such you need access to information that the defined public key format does not contain so it cannot just be parsed out of the CKA_VALUE of the public key. That would indicate we must maintain it as being available in attributes. Tim. On Thu, Apr 1, 2021 at 11:23 PM Michelle Brochmann <mbrochmann@infoseccorp.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]