OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [pkcs11] HSS discussion


Thank you Philip for pointing this out! Clearly I wasnât looking carefully enough. 😊

 

Michelle

 

From: Philip Lafrance <Philip.Lafrance@isara.com>
Sent: Tuesday, April 6, 2021 6:40 AM
To: Michelle Brochmann <mbrochmann@infoseccorp.com>; tjh@cryptsoft.com
Cc: pkcs11@lists.oasis-open.org
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)

â
Each LMS tree within the hierarchy is associated with a distinct LMS

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
Sent: April 2, 2021 11:10 AM
To: tjh@cryptsoft.com
Cc: pkcs11@lists.oasis-open.org
Subject: [External]RE: [pkcs11] HSS discussion

 

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:

 

  1. For input values to key gen, are we going with option 1 or option 2, or an ECC style âCHOICEâ where we allow both?
  2. For return values (what is in the public/private key object), are we going with option 1 or option 2?
  3. Is there any intent to accommodate levels/algorithms beyond those approved by NIST/in the RFC? This would require our own encoding, which could result in conflicts with future NIST-approved algorithm IDS, especially given the RFC specification for the XDR structure of the signature. I believe there was some discussion about this but I didnât catch what the conclusion was!

 

Michelle

 

From: Tim Hudson <tjh@cryptsoft.com>
Sent: Thursday, April 1, 2021 5:52 PM
To: Michelle Brochmann <mbrochmann@infoseccorp.com>
Cc: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] HSS discussion

 

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                   CK_LMOTS_TYPE;

typedef CK_ULONG_PTR               CK_LMS_TYPE_PTR;
typedef CK_ULONG_PTR               CK_LMOTS_TYPE_PTR;

 

typedef struct CK_HSS_PARAMS {
  CK_HSS_LEVELS     ulLevels;
  CK_LMS_TYPE_PTR   pLMSAlgorithmTypes;
  CK_LMOTS_TYPE_PTR pLMOTSAlgorithmType;

} 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 {
  CK_HSS_LEVELS      L;   /* or could use "levels" */
  CK_LMS_TYPE_PTR    lms_algorithm_types;
  CK_LMOTS_TYPE_PTR  lmots_algorithm_types;

} 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:

Thanks very much for the writeup Tim, and thank you everybody for the discussion yesterday â these really help a newbie like me get a much better understanding of the goals and context of PKCS!

 

One minor amendment to the struct of parameters (option 1) and the individual attributes (option 2) is that the LMS/LMOTS types will be arrays of length L. Does this affect the discussion around what can be returnable by C_GetAttributeValue for a public vs. private key (second to last, and third to last, paragraphs in Timâs writeup).

 

Was there a final decision as to whether we were using option 1 or 2? Would an approach like ECC where both options are allowed be viable?

 

One thing Iâd like clarification on (and will speak to whether an approach like ECC would even make sense): The signature structure, as specified in RFC 8554 using XDR, has the LMS and LMOTS types expressed as 4-byte strings (u32str) from the encodings specified in RFC 8554 and NIST SP 800-208. Do we intend to allow types (and levels) that are *not* specified by the RFC/NIST, and if so, how can those be put into the signature in a way that makes sense (and wonât conflict with potential future additions to the table by NIST)?

 

Michelle

 

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Tim Hudson
Sent: Wednesday, March 31, 2021 5:51 PM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] HSS discussion

 

We have a range of choices we can make on this and we have discussed a few different options on the rather lengthy call today as we need to make decisions about HSS.

I believe I've captured all the main elements of the discussion on the call and I've expanded on things to make the discussion items clearer to those who didn't have the documents in front of them or aren't familiar with HSS.

 

We want to avoid having to maintain tables of values that match tables in other specifications that we would have to track. Our preference is to directly use those values and not have to have another set of mapping tables from PKCS#11 identifiers to a different set of identifiers defined in another standard. We want to just use the values in the standard directly where possible.

 

The HSS RFC at https://www.rfc-editor.org/rfc/rfc8554.html defines the binary representation of public keys and signatures using XDR. It is not ASN.1. Any provider implementation producing signatures or checking signatures or importing public keys needs to be able to handle parsing (and producing) XDR encoded information.

 

The NIST document https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf has a superset of information covering more than HSS. It also continues (despite being "final" and no longer draft) to have TBD values in place.

 

These types of schemes have multiple parameters and there are multiple schemes in the NIST document going beyond HSS.

 

For HSS we need the levels and the LMS algorithm and LM-OTS algorithm for key generation so there has to be a way to pass that information into a provider. Our choices are to use a params blob (binary information understood from some other standard), a params structure which we define within PKCS#11, or to use template attributes. We have different approaches for different mechanisms within PKCS#11 so there is no single correct answer as to what approach should be used for a given algorithm.

 

In the context of HSS, a public key contains L, lms_algorithm_type, and lmots_algorithm_type (and also I and K). 

 

The magic numbers for lms_algorithm_type and lmots_algorithm_type are maintained in a separate registry which is referred to by the RFC and NIST at https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml

 

We can define a params structure (HSS_PARAMS) that contains the information required for key generation or alternatively we can provide that information via the template attributes as individual attributes.

 

The advantage of individual attributes is that they can then be made available to C_GetAttributeValue for any user wanting to query that information without having to otherwise parse the XDR representation of the public key (which will be its CKA_VALUE) or parsing out the details from a signature (also an XDR representation output format).

 

As the algorithm strength value is useful to be able to return, having an attribute that returns that value saves users from having to have their own mapping table just for this purpose - a mapping table that will have to be continually updated (in applications) rather than having module implementers being able to report what they must already know to be able to handle. 

 

This would be another attribute and its value would be the CK_MECHANISM_TYPE using our existing definitions of digest algorithms. 

 

In summary we have two options for how we handle HSS:

 

Option 1

(parameters)

 

typedef CK_ULONG                   CK_HSS_LEVELS;

typedef CK_ULONG                   CK_LMS_TYPE;
typedef CK_ULONG                   CK_LMOTS_TYPE;

 

typedef struct CK_HSS_PARAMS {
  CK_HSS_LEVELS  ulLevels;
  CK_LMS_TYPE    ulLMSAlgorithmType;
  CK_LMOTS_TYPE  ulLMOTSAlgorithmType;
} 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 {
  CK_HSS_LEVELS  L;   /* or could use "levels" */
  CK_LMS_TYPE    lms_algorithm_type;
  CK_LMOTS_TYPE  lmots_algorithm_type;
} CK_HSS_PARAMS;

 

Option 2

(no parameters, only attributes)

 

CKA_HSS_LEVELS (CK_ULONG)

CKA_HSS_LMS_ALGORITHM_TYPE (CK_ULONG)

CKA_HSS_LMOTS_ALGORITHM_TYPE (CK_ULONG)

CKA_HSS_DIGEST_MECHANISM_TYPE (CK_MECHANISM_TYPE)

 

All of the attributes should be able to be provided for both an HSS public key and an HSS private key in terms of a consumer being able to return the values via C_GetAttributeValue.

Internally, a provider implementation has to have that knowledge and mapping.

 

I'm in favour of being able to return this information about HSS keys so the consumer doesn't have to parse things out and if we are returning any attribute that requires a provider implementation to return, using that same approach of attributes for key generation makes sense to me (consistency). 

 

In terms of what option 2 would mean for API usage, the following is a quick summary:

 

For C_CreateObject you have to pass in the binary (XDR encoded) HSS public key as the only way to load in a public key (unless we added I and K as attributes which we could). We do not allow import of an HSS private key (it's format is not defined and migration of HSS keys between tokens has been explicitly disallowed). 

 

For C_GenerateKeyPair you pass in  CKA_HSS_LEVELS,  CKA_HSS_LMS_ALGORITHM_TYPE,  CKA_HSS_LMOTS_ALGORITHM_TYPE.

 

For C_GetAttributeValue for an HSS public key the CKA_VALUE is the binary (XDR encoded) HSS public key and CKA_HSS_LEVELS, CKA_HSS_LMS_ALGORITHM_TYPE, CKA_HSS_LMOTS_ALGORITHM_TYPE, CKA_HSS_DIGEST_MECHANISM_TYPE are all returnable (available).

 

For C_GetAttributeValue for an HSS public key the CKA_VALUE is sensitive (unavailable) for the HSS private key and CKA_HSS_LEVELS, CKA_HSS_LMS_ALGORITHM_TYPE, CKA_HSS_LMOTS_ALGORITHM_TYPE, CKA_HSS_DIGEST_MECHANISM_TYPE are all returnable (available).

 

This I think is where the underlying usability concern of mine is - if we say that the consumer has to parse things themselves to figure out what they are dealing with then they cannot tell anything about the private key itself - they have to have a corresponding public key.

 

 

Tim.

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]