Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure

Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure CryptoNext Security

daniel.vangeest@cryptonext-security.com

BSI

kaveh.bashiri.ietf@gmail.com

Cisco Systems

sfluhrer@cisco.com

genua GmbH

ietf@gazdag.de

BSI

kousidis.ietf@gmail.com

SEC lamps HSS LMS XMSS certificate X.509 PKIX stateful hash-based This document specifies algorithm identifiers and ASN.1 encoding formats for the following stateful Hash-Based Signature (HBS) schemes: Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS). This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs).

Introduction Stateful Hash-Based Signature (HBS) schemes such as the Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT combine Merkle trees with One-Time Signatures (OTS). This is done in order to provide digital signature schemes that remain secure even when quantum computers become available. Their theoretic security is well understood and depends only on the security of the underlying hash function. As such, they can serve as an important building block for quantum computer resistant information and communication technology. A stateful HBS private key consists of a finite collection of OTS keys, along with state information that tracks the usage of these keys to ensure the security of the scheme. Only a limited number of messages can be signed, and the private key's state must be updated and persisted after signing to prevent reuse of OTS keys. While the right selection of algorithm parameters would allow a private key to sign a virtually unbounded number of messages (e.g., 2⁶⁰), this is at the cost of a larger signature size and longer signing time. Because the private key in stateful HBS schemes is stateful and the number of signatures that can be generated is limited, these schemes may be unsuitable for use in interactive protocols. However, in some use cases, the deployment of stateful HBS schemes may be appropriate. Such use cases are described and discussed in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Use Cases of Stateful HBS Schemes in X.509 As described in the Security Considerations in , it is imperative that stateful HBS implementations do not reuse OTS signatures. This makes stateful HBS algorithms inappropriate for general use cases. The exact conditions under which stateful HBS certificates may be used is left to certificate policies . However, the intended use of stateful HBS schemes as described by can be used as a guideline:

stateful HBS schemes are primarily intended for applications with the following characteristics: 1) it is necessary to implement a digital signature scheme in the near future; 2) the implementation will have a long lifetime; and 3) it would not be practical to transition to a different digital signature scheme once the implementation has been deployed.

In addition, since a stateful HBS private key can only generate a finite number of signatures, use cases for stateful HBS public keys in certificates should have a predictable range of the number of signatures that will be generated, falling safely below the maximum number of signatures that a private key can generate. Use cases where stateful HBS public keys in certificates may be appropriate due to the relatively small number of signatures generated and the signer's ability to enforce security restrictions on the signing environment include:

Firmware signing (see Section 1.1 of , , and Section 6.7 of )
Software signing ( and )
Certification Authority (CA) certificates

In each of these cases, the operator tightly controls their secured signing environment and can mitigate OTS key reuse by employing state management strategies such as those in . Also, for secure private key backup and restoration, adequate mechanisms have to be implemented (see ). Generally speaking, stateful HBS public keys are not appropriate for use in end-entity certificates, however, in the firmware and software signing cases, signature generation will often be more tightly controlled. Some manufactures use common and well-established key formats like X.509 for their code signing and update mechanisms. Also, there are multi-party Internet of Things (IoT) ecosystems where publicly trusted code signing certificates are useful. In general, root CAs generate signatures in a more secure environment and issue fewer certificates than subordinate CAs . This makes the use of stateful HBS public keys more appropriate in root CA certificates than in subordinate CA certificates. However, if a subordinate CA can match the security and signature count restrictions of a root CA, for example, if the subordinate CA only issues code-signing certificates, then using a stateful HBS public key in the subordinate CA certificate may be practical.

Algorithm Identifiers and Parameters In this document, we define new Object Identifiers (OIDs) for identifying the different stateful hash-based signature algorithms. An additional OID is defined in and repeated here for convenience. The AlgorithmIdentifier type is defined in as follows: The fields in AlgorithmIdentifier have the following meanings:

algorithm:: this identifies the cryptographic algorithm with an OID.
parameters:: these are optional and are the associated parameters for the algorithm identifier in the algorithm field.

The parameters field of the AlgorithmIdentifier for HSS, XMSS, and XMSS^MT public keys MUST be absent.

HSS Algorithm Identifier The OID and public key algorithm identifier for HSS is defined in . The definitions are repeated here for reference. The AlgorithmIdentifier for an HSS public key MUST use the id-alg-hss-lms-hashsig OID. Note that the id-alg-hss-lms-hashsig algorithm identifier is also referred to as id-alg-mts-hashsig. This synonym is based on the terminology used in an early draft of the document that became . The public key and signature values identify the hash function and the height used in the HSS tree. and define these values, and additional identifiers can be registered in the "Leighton-Micali Signatures (LMS)" registry .

XMSS Algorithm Identifier The AlgorithmIdentifier for an XMSS public key MUST use the id-alg-xmss-hashsig OID. The public key and signature values identify the hash function and the height used in the XMSS tree. and define these values, and additional identifiers can be registered in the "Leighton-Micali Signatures (LMS)" registry .

XMSS^MT Algorithm Identifier The AlgorithmIdentifier for an XMSS^MT public key MUST use the id-alg-xmssmt-hashsig OID. The public key and signature values identify the hash function and the height used in the XMSS^MT tree. and define these values, and additional identifiers can be registered in the "Leighton-Micali Signatures (LMS)" registry .

Public Key Identifiers Certificates conforming to can convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. An algorithm identifier consists of an OID and optional parameters. defines the encoding of HSS public keys, and defines the encodings of XMSS and XMSS^MT public keys. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains these encodings of the public key. This document defines ASN.1 OCTET STRING types for encoding the public keys when not used in a SubjectPublicKeyInfo. The OCTET STRING is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING.

HSS Public Keys The HSS public key identifier is as follows: The HSS public key is defined as follows: defines the encoding of an HSS public key using the hss_public_key structure. See and for more information on the contents and format of an HSS public key. Note that the Leighton-Micali Signature (LMS) single-tree signature scheme is instantiated as HSS with the number of levels being equal to 1.

XMSS Public Keys The XMSS public key identifier is as follows: The XMSS public key is defined as follows: defines the encoding of an XMSS public key using the xmss_public_key structure. See and for more information on the contents and format of an XMSS public key.

XMSS^MT Public Keys The XMSS^MT public key identifier is as follows: The XMSS^MT public key is defined as follows: defines the encoding of an XMSS^MT public key using the xmssmt_public_key structure. See and for more information on the contents and format of an XMSS^MT public key.

Key Usage Bits The intended application for the key is indicated in the keyUsage certificate extension . When id-alg-hss-lms-hashsig, id-alg-xmss-hashsig, or id-alg-xmssmt-hashsig appears in the SubjectPublicKeyInfo field of a CA X.509 certificate , the certificate key usage extension MUST contain at least one of the following values: digitalSignature, nonRepudiation, keyCertSign, or cRLSign. However, it MUST NOT contain other values. When id-alg-hss-lms-hashsig, id-alg-xmss-hashsig, or id-alg-xmssmt-hashsig appears in the SubjectPublicKeyInfo field of an end entity X.509 certificate , the certificate key usage extension MUST contain at least one of the following values: digitalSignature, nonRepudiation or cRLSign. However, it MUST NOT contain other values.

Signature Algorithms The same OIDs used to identify HSS, XMSS, and XMSS^MT public keys are also used to identify their respective signatures. When these algorithm identifiers appear in the algorithm field of an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, one of the OIDs defined in the following subsections. When the signature algorithm identifiers described in this document are used to create a signature on a message, no digest algorithm is applied to the message before signing. That is, the full data to be signed is signed rather than a digest of the data. The format of an HSS signature is described in . The format of an XMSS signature is described in , and the format of an XMSS^MT signature is described in . The octet string representing the signature is encoded directly in a BIT STRING without adding any additional ASN.1 wrapping. For the Certificate and CertificateList structures, the octet string is encoded in the "signatureValue" BIT STRING field.

HSS Signature Algorithm The id-alg-hss-lms-hashsig OID is used to specify that an HSS signature was generated on the full message, i.e., the message was not hashed before being processed by the HSS signature algorithm. See and for more information on the contents and format of an HSS signature.

XMSS Signature Algorithm The id-alg-xmss-hashsig OID is used to specify that an XMSS signature was generated on the full message, i.e., the message was not hashed before being processed by the XMSS signature algorithm. See and for more information on the contents and format of an XMSS signature. The signature generation MUST be performed according to Section 7.2 of .

XMSS^MT Signature Algorithm The id-alg-xmssmt-hashsig OID is used to specify that an XMSS^MT signature was generated on the full message, i.e., the message was not hashed before being processed by the XMSS^MT signature algorithm. See and for more information on the contents and format of an XMSS^MT signature. The signature generation MUST be performed according to Section 7.2 of .

Key Generation The key generation for XMSS and XMSS^MT MUST be performed according to Section 7.2 of .

ASN.1 Module For reference purposes, the ASN.1 syntax is presented as an ASN.1 module here . Note that as per , certificates use the Distinguished Encoding Rules; see . This ASN.1 module builds upon the conventions established in . This module imports objects from and .

Security Considerations The security requirements of MUST be taken into account. As stateful HBS private keys can only generate a limited number of signatures, a user needs to be aware of the total number of signatures they intend to generate in their use case; otherwise, they risk exhausting the number of OTS keys in their private key. For stateful HBS schemes, it is crucial to stress the importance of correct state management. If an attacker were able to obtain signatures for two different messages created using the same OTS key, then it would become computationally feasible for that attacker to create forgeries . As noted in and , extreme care needs to be taken in order to avoid the risk that an OTS key will be reused accidentally. This is a new requirement that most developers will not be familiar with and requires careful handling. Various strategies for a correct state management can be applied:

Implement a record of all signatures generated by a key pair associated with a stateful HBS instance, for example, by logging the OTS key indexes as signatures are generated. This record may be stored outside the device that is used to generate the signature. Check the record to prevent OTS key reuse before a new signature is released. If OTS key reuse is detected, freeze all new signature generation by the private key, re-audit previously released signatures (possibly revoking the private key if previously released signatures showed OTS key reuse), and perform a post-failure audit.
Use a stateful HBS instance only for a moderate number of signatures such that it is always practical to keep a consistent record and be able to unambiguously trace back all generated signatures.
Apply the state reservation strategy described in Section 5 of , where upcoming states are reserved in advance by the signer. In this way, the number of state synchronizations between nonvolatile and volatile memory is reduced.

Backup and Restore Management Certificate authorities have high demands in order to ensure the availability of signature generation throughout the validity period of signing key pairs. Some usual backup and restore strategies when using a stateless signature scheme (e.g., SLH-DSA) are to:

duplicate private keying material and operate redundant signing devices.
store and safeguard a copy of the private keying material such that it can be used to set up a new signing device in case of technical difficulties.

For stateful HBS schemes, such straightforward backup and restore strategies will lead to OTS reuse with high probability as a correct state management is not guaranteed. Strategies for maintaining availability and keeping a correct state are described in Section 7 of and .

IANA Considerations IANA has registered the following OID for the ASN.1 module (see ) in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:

Decimal	Description	References
114	id-mod-pkix1-shbs-2024	RFC 9802

IANA has registered the following entries in the "SMI Security for PKIX Algorithms" (1.3.6.1.5.5.7.6) registry :

Decimal	Description	References
34	id-alg-xmss-hashsig	RFC 9802
35	id-alg-xmssmt-hashsig	RFC 9802

References Normative References Recommendation for Stateful Hash-Based Signature Schemes Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation ITU-T Information technology: ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T Informative References State Management for Hash-Based Signatures Cryptology ePrint Archive, Paper 2016/357 Oops, I did it again - Security of One-Time Signatures under Two-Message Attacks. Cryptology ePrint Archive, Paper 2016/1042 The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ National Security Agency (NSA) CYBER; State management for stateful authentication mechanisms Leighton-Micali Signatures (LMS) IANA XMSS: Extended Hash-Based Signatures IANA SMI Security for PKIX Algorithms IANA ANSSI views on the Post-Quantum Cryptography transition (2023 follow up) Quantum-safe cryptography - fundamentals, current developments and recommendations

HSS X.509 v3 Certificate Example This section shows a self-signed X.509 v3 certificate using HSS.

XMSS X.509 v3 Certificate Example This section shows a self-signed X.509 v3 certificate using XMSS.

XMSS^MT X.509 v3 Certificate Example This section shows a self-signed X.509 v3 certificate using XMSS^MT.

Acknowledgments Thanks to , , , and for their helpful suggestions and reviews. This document uses a lot of text from similar documents, including: , and , as well as . Thanks goes to the authors of those documents. "Copying always makes things easier and less error prone" .