Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
obsoletes
- rfc-8708 — Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
Extracted elements (23)
HSS/LMS is considered post-quantum secure because its security relies on second-preimage resistance of a hash function rather than on discrete logarithms or integer factoring, which are vulnerable to cryptographically relevant quantum computers (CRQCs).
HSS uses a hierarchy of LMS trees so that subordinate trees can be generated on demand by the signer, avoiding a scenario where generating the entire tree at once might take weeks or longer.
The pk-HSS-LMS-HashSig definition was updated to specify no ASN.1 wrapping for the public key (HSS-LMS-HashSig-PublicKey ::= OCTET STRING) to align with emerging conventions for carrying the public key in X.509 certificates, resolving errata Err7960 and Err7963 from RFC 8708.
RFC 9708 resolves Err7960 and Err7963 against RFC 8708 by updating the pk-HSS-LMS-HashSig PUBLIC-KEY definition to specify no ASN.1 wrapping for the HSS/LMS public key, making it consistent with X.509 certificate conventions.
The id-alg-hss-lms-hashsig OID is a synonym for id-alg-mts-hashsig, the latter being based on terminology from an early draft of RFC 8554. Implementations may encounter both names for the same algorithm identifier.
An implementation MUST ensure that an LM-OTS private key is used to generate a signature only one time and cannot be used for any other purpose.
Implementations MUST protect the HSS/LMS private keys and MUST keep track of which leaf nodes in the tree have been used. Loss of integrity of tracking data can cause a one-time key to be reused, breaking security.
In SignerInfo, the digestAlgorithm MUST contain the one-way hash function used in the HSS/LMS tree (SHA-256 or SHAKE256), and signatureAlgorithm MUST contain id-alg-hss-lms-hashsig with absent parameters.
When computing signatures, the same hash function SHOULD be used to compute the message digest of the content and the signed attributes, if they are present.
When generating an LMS key pair, an implementation MUST generate each key pair independently of all other key pairs in the HSS tree.
When the HSS/LMS AlgorithmIdentifier appears in the SubjectPublicKeyInfo of an end-entity X.509 certificate, the key usage extension MUST contain at least one of digitalSignature, nonRepudiation, or cRLSign, and MUST NOT contain other values.
When the id-alg-hss-lms-hashsig object identifier is used for an HSS/LMS signature or public key, the AlgorithmIdentifier parameters field MUST be absent (not present, not set to NULL).
The HSS/LMS algorithm identifier is id-alg-hss-lms-hashsig with OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 17 }. It is also referred to as id-alg-mts-hashsig based on earlier draft terminology.
The LM-OTS algorithm has five parameters: n (hash output length in bytes), H (preimage-resistant hash function), w (Winternitz coefficient width: 1, 2, 4, or 8 bits), p (number of n-byte elements in the signature), and ls (left-shift bits for the checksum). Values of p and ls are derived from n and w per RFC 8554 Appendix B.
When signed attributes are absent, HSS_LMS_Sign is computed over the content directly. When signed attributes are present, Hash(content) forms the message-digest attribute and HSS_LMS_Sign is computed over DER(SignedAttributes), which MUST include content-type and message-digest attributes.
IANA updated the 'SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)' registry: value 17 now references RFC 9708 (previously RFC 8708).
Use of inadequate PRNGs to generate private keys or LM-OTS random values (C) can result in little or no security; an attacker may reproduce the PRNG environment and search the resulting small key space. RFC 4086 guidance on random number generation MUST be followed.
When private keys and leaf-tracking data are stored on non-volatile media or in VM environments, failed writes, VM snapshots or cloning can cause one-time keys to be reused, enabling signature forgery. Operational procedures must ensure confidentiality and integrity of both the key and its tracking data.
An HSS signature for a hierarchy with Nspk signed public keys encodes as: u32str(Nspk) followed by Nspk signed_public_key structures (each containing an lms_signature over the public key followed by the public key itself), followed by the final lms_signature over the message.
An LM-OTS signature encodes as: u32str(otstype) || C (n-byte random value) || y[0] || ... || y[p-1] (sequence of hash values corresponding to public key elements).
An LMS signature encodes as: u32str(q) (leaf number) || ots_signature || u32str(type) (LMS typecode) || path[0] || ... || path[h-1] (sibling nodes on path from leaf to root, h values total).
The HSS/LMS public key outside a certificate encodes as: u32str(L) (number of levels) || lms_public_key. The full type is HSS-LMS-HashSig-PublicKey ::= OCTET STRING with no additional ASN.1 wrapping.
The LMS public key encodes as: u32str(lms_algorithm_type) || u32str(otstype) || I (private key identifier) || T[1] (m-byte root node string).