Information to be excluded from the HSS portion of the PKCS #11 spec

Hi all,

Here is a bit more information in response to the previous meeting’s discussion about whether to include certain items in the HSS portion of the PKCS#11 spec.

CK_LMOTS and CK_LMS_TYPE values:

If I understand correctly, the idea is that the PKCS#11 spec should only provide explicit guidance for things that are not specified elsewhere, so we don’t want to specify values that are provided in NIST SP 800-208, RFC 8554, or future versions of these documents, and instead we should just provide references to those documents where appropriate. Therefore we can get rid of the CK_LMS_TYPE and CK_LMOTS_TYPE value tables.

Does this *also* mean that we should not include those values in the pkcs11f.h header file?

The CKA_HSS_PARAMS object:

This does seem unnecessary to me: while the CKA_VALUE for the public key only contains information about the top level LMS tree in the HSS tree, even if different LMOTS and LMS types are used for different levels, the CK_LMS_TYPE and CK_LMOTS_TYPE for each level are contained in the signature, though one does have to parse the signature to get at it. See * at the end of the email for partial overview of the structure of the signature. I included *only* enough information to show that the necessary information is obtainable from the signature.

Should we also refrain from *describing* the contents of CKA_VALUE in the table, since this information is contained in RFC 8554?

Private key object:

Furthermore, as we discussed in the past, private keys are not exportable by PKCS methods (although vendors** may provide ways to distribute portions of the HSS hierarchy between modules). Because of this, can we also pare down what information we give in the private key section? It seems the only truly necessary information is that the private key is not exportable via PKCS mechanisms:

Given that PKCS does not allow exporting the private key, it seems to me that the “sample template for creating an LMS private key object” as well as either of the attributes in the table titled “HSS Private Key Object Attributes” are unnecessary.
Given 1), we may not need to say anything about a CKA_SENSITIVE and CKA_EXTRACTABLE attribute, since there is no PKCS context where it will be used.

**Is it correct that the PKCS spec is *not* going to say anything about how this distribution is done?

Michelle

*From RFC 8554 we find the form of the signature:

HSS signature:

u32str(L-1) || signed_pub_key[0] || ... || signed_pub_key[L-2] || signed_message

where:

u32str(L-1) is a 32-bit string encoding a number that tells how many signed public keys are to follow (one for every level, except the top level, in the hierarchy of LMS trees).

signed_pub_key[i] is the LMS public key (described below) of level i+1, preceded by its LMS signature generated using the LMS keypair of level i (the LMS tree directly above the LMS tree whose public key is being signed).

signed_message is the LMS signature (described below) of the message generated using the LMS keypair of level L-1 (the lowest level LMS tree).

Note that the signature in signed_pub_key[0] was generated using the top level LMS tree, whose corresponding public key is in the HSS public key. To understand what is in the signed_pub_key[i] and signed_message we need to look at the structure of the LMS public key and the LMS signature:

LMS signature:

u32str(q) || ots signature || u32str(type) || path[0] || … || path[h-1]

where:

u32str(q) is a 32 bit string encoding the index of the private key used to generate the signature. (Specifies a leaf of the Merkle tree.)

ots_signature is ots_sig_size (can be determined from CK_LMOTS_TYPE of the corresponding LMS public key) bytes containing the one time signature (of the public key for the LMS tree one level down, or the message) generated using the private key at index q.

u32str(type) is a 32 bit string encoding the Merkle tree height (i.e. the CK_LMS_TYPE).

path[i] is 32 bytes containing the sibling hash values at the ith node (counted from the bottom up) along the authentication path up the Merkle tree used for this signature.

h is the height of the Merkle tree not including the root.

LMS public key:

u32str(type) || u32str(otstype) || bytes[16](I) || bytes[32](T[1])

where:

u32str(type) is a 32 bit string encoding the Merkle tree height (i.e. the CK_LMS_TYPE).

u32str(otstype) is a 32 bit string encoding the Winternitz parameter specifier (i.e. the CK_LMOTS_TYPE).

I is a 16 byte generated string which is the private key that identifies and specifies the Merkle tree.

T[1] is the hash value at the root of the specified Merkle tree.

pkcs11 message