]> 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 - Limited Additional Mechanisms for PKIX and SMIME Internet-Draft This document specifies algorithm identifiers and ASN.1 encoding formats for the 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 those digital signatures are used in Internet X.509 certificates and certificate revocation lists. About This Document Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Stateful HBS schemes such as HSS, XMSS and XMSS^MT combine Merkle trees with One Time Signatures (OTS) 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^60), 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 of , 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:
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 (Section 1.1 of , Table IV of , Section 6.7 of )
  • Software signing (Table IV of , )
  • Certification Authority (CA) certificates.
In each of these cases, the operator is able to control their signing environment such that signatures are generated in hardware cryptographic modules and audited before the signature is published, in order to prevent OTS key reuse. 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 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 possible.
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 identifies the cryptographic algorithm with an object identifier.
  • parameters, which are optional, 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 object identifier 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 object identifier. 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, but an IANA registry permits the registration of additional identifiers in the future.
XMSS Algorithm Identifier The AlgorithmIdentifier for an XMSS public key MUST use the id-alg-xmss-hashsig object identifier. The public key and signature values identify the hash function and the height used in the XMSS tree. and define these values, but an IANA registry permits the registration of additional identifiers in the future.
XMSS^MT Algorithm Identifier The AlgorithmIdentifier for an XMSS^MT public key MUST use the id-alg-xmssmt-hashsig object identifier. The public key and signature values identify the hash function and the height used in the XMSS^MT tree. and define these values, but an IANA registry permits the registration of additional identifiers in the future.
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 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 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 7.2 of .
Key Generation The key generation for XMSS and XMSS^MT MUST be performed according to 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 . RFC EDITOR: Please replace in the module with a reference to the published RFC.
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 which 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 synchronisations 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. Usual backup and restore strategies when using a stateless signature scheme (e.g. SLH-DSA) are to duplicate private keying material and to operate redundant signing devices or to 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 .
IANA Considerations One object identifier for the ASN.1 module in is requested for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) registry:
Decimal Description References
TBD id-mod-pkix1-shbs-2024 [EDNOTE: THIS RFC]
IANA has updated the "SMI Security for PKIX Algorithms" (1.3.6.1.5.5.7.6) registry with two additional entries:
Decimal Description References
34 id-alg-xmss-hashsig [EDNOTE: THIS RFC]
35 id-alg-xmssmt-hashsig [EDNOTE: THIS RFC]
References Normative References Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) Vigil Security, LLC This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC 8708. New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] XMSS: eXtended Merkle Signature Scheme This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. Leighton-Micali Hash-Based Signatures This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. Recommendation for Stateful Hash-Based Signature Schemes Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation ITU-T Information technology - Abstract Syntax Notation One (ASN.1): ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. Internet Security Glossary, Version 2 This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. IANA Registration for the Cryptographic Algorithm Object Identifier Range When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. State Management for Hash-Based Signatures Oops, I did it again – Security of One-Time Signatures under Two-Message Attacks. Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) Cybersecurity Advisory (CSA) State management for stateful authentication mechanisms Leighton-Micali Signatures (LMS) n.d. XMSS: Extended Hash-Based Signatures n.d. SMI Security for PKIX Algorithms n.d. 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 for Russ Housley, Panos Kampanakis, Michael StJohns and Corey Bonnell for helpful suggestions and reviews. This document uses a lot of text from similar documents , ( and ) as well as . Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - .