HSS discussion

[Tim Hudson <tjh@cryptsoft.com>]

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.