]> Nokia

London United Kingdom aritra.banerjee@nokia.com

Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Security ACME PQC ACME This document updates RFC 8555 (ACME) to specify post-quantum and PQ/T hybrid cryptographic requirements for quantum-ready deployments. The Automatic Certificate Management Environment (ACME) automates certificate issuance, validation, and management over HTTPS using JSON Web Signatures (JWS) to authenticate client request payloads. Current ACME deployments rely on traditional public-key algorithms in both JWS and TLS, which are vulnerable to attacks from Cryptographically Relevant Quantum Computers (CRQCs). This specification defines PQC or PQ/T hybrid TLS 1.3 key establishment and specifies PQC or PQ/T authentication mechanisms for JWS and TLS under the quantum-ready ACME mechanism. This specification enables ACME clients and servers to achieve quantum-resistant confidentiality and authentication. About This Document Status information for this document may be found at . Discussion of this document takes place on the acme Working Group mailing list (), which is archived at . Subscribe at .

Introduction The Automatic Certificate Management Environment (ACME ) automates certificate issuance, validation, and management over HTTPS using JSON Web Signatures (JWS) for authenticating client requests to the Certificate Authority (CA). ACME relies on TLS to provide confidentiality, integrity, and authentication of the ACME server, ensuring secure transport of protocol messages. ACME defines multiple domain control validation methods, such as HTTP-01, DNS-01, and TLS-based challenges like tls-alpn-01 . In all cases, ACME depends on traditional public-key cryptography, both in JWS for client request authentication and in TLS for server authentication and session key establishment. The emergence of Cryptographically Relevant Quantum Computers (CRQCs) threatens the security of these mechanisms. Quantum algorithms, such as Shor's algorithm, would render widely deployed public-key algorithms (e.g., RSA, ECDSA, and ECDH) insecure. Consequently, there is a need to transition ACME to post-quantum cryptography (PQC) to ensure long-term security. This document makes two distinct contributions. First, it specifies post-quantum and PQ/T hybrid signature algorithms as mandatory-to-implement for authentication in quantum-ready ACME deployments — covering both JWS request authentication (updating RFC 8555 Section 6.2, following the same precedent by which RFC 8555 mandated ES256) and TLS server authentication. Second, it enables the use of post-quantum or PQ/T hybrid key exchange for the TLS channel underlying ACME, specifically to address the Harvest-Now, Decrypt-Later (HNDL) threat to ACME traffic confidentiality. Unless explicitly stated otherwise, all requirements in this document apply only to deployments operating under these quantum-ready mechanisms.

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. This document also adopts terminology defined in . For the purposes of this document, it is useful to categorize cryptographic algorithms into three distinct classes:

• Traditional Algorithm: An asymmetric cryptographic algorithm based on integer factorization, finite field discrete logarithms, or elliptic curve discrete logarithms. In the context of TLS, an example of a traditional key exchange algorithm is Elliptic Curve Diffie-Hellman (ECDH), which is almost exclusively used in its ephemeral mode, referred to as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE).
• Post-Quantum Algorithm: An asymmetric cryptographic algorithm designed to be secure against attacks from both quantum and classical computers. An example of a post-quantum key exchange algorithm is the Module-Lattice Key Encapsulation Mechanism (ML-KEM). Such algorithms rely on mathematical problems (e.g., lattices) that are believed to be hard for both classical and CRQCs to solve efficiently.
• Hybrid Algorithm: The distinction is made between key exchange algorithms and signature algorithms:
  • PQ/T Hybrid Key Exchange: A key exchange mechanism that combines two component algorithms - one traditional algorithm and one post-quantum algorithm. The resulting shared secret remains secure as long as at least one of the component key exchange algorithms remains unbroken.
  • PQ/T Hybrid Digital Signature: A multi-algorithm digital signature scheme composed of two or more component signature algorithms, where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
• For clarity, this document uses the term PQC-only to refer exclusively to cryptographic mechanisms that contain no traditional component, and distinguishes them from PQ/T hybrid mechanisms that combine post-quantum and traditional algorithms.
• Quantum-Ready Mechanism: A deployment mechanism under which all TLS connections use post-quantum or PQ/T hybrid key exchange, and post-quantum or PQ/T hybrid authentication is supported for both TLS server authentication and JWS request authentication. Traditional-only authentication may continue to be accepted during an explicitly bounded transition period.

Selection of a Quantum-Ready Mechanism is a matter of deployment policy.

Quantum-Ready TLS Channel Requirements In ACME, clients may transmit personally identifiable information (PII) such as email addresses and other account-related metadata when creating or managing an account. The confidentiality of this information relies on the security of the TLS 1.3 channel, which protects ACME exchanges from passive observation during transmission. ACME deployments operating under a quantum-ready mechanism MUST use TLS 1.3 , or a later version of TLS, for all ACME message exchanges; earlier versions of TLS MUST NOT be used. Post-quantum and PQ/T hybrid key exchange for TLS is defined only for TLS 1.3, so this requirement is a prerequisite for the key-establishment protections described below. One of the primary threats to TLS in ACME is the Harvest-Now, Decrypt-Later (HNDL) attack. In this scenario, an adversary passively records encrypted TLS traffic, such as ACME account creation or order requests, and stores it for future decryption once Cryptographically Relevant Quantum Computers (CRQCs) become available. CRQCs can break the traditional public-key algorithms (e.g., RSA, ECDH) used in TLS handshakes to establish session keys, exposing sensitive PII contained within ACME messages. Protection against HNDL requires post-quantum or PQ/T hybrid key exchange for the TLS connection. The key exchange is established at the TLS layer, not by ACME; its post-quantum and PQ/T hybrid form is specified in Section 4 of . ACME deployments seeking quantum-ready confidentiality follow that guidance, which ensures that recorded TLS sessions cannot be retrospectively decrypted.

Quantum-Ready Authentication Post-quantum protection requirements differ between key establishment and authentication mechanisms, but both require action before a Cryptographically Relevant Quantum Computer (CRQC) becomes available. Unlike Harvest-Now, Decrypt-Later attacks that target confidentiality retrospectively, the threat to authentication arises only from the moment a CRQC becomes available. However, as discussed in , the availability of a CRQC may not be publicly disclosed — similar to a zero-day vulnerability, an adversary could exploit quantum capabilities privately to forge traditional certificates without alerting the wider ecosystem. Furthermore, because ecosystem-wide upgrades across cryptographic libraries, PKI infrastructure, Hardware Security Modules (HSMs), and dependent protocols require years of planning and deployment, preparations must begin well before a CRQC is publicly known. Post-quantum security is achieved only when relying parties enforce policies that reject traditional-only authentication. For these reasons, this document provides support for post-quantum or PQ/T hybrid authentication mechanisms for quantum-ready ACME mechanism, while permitting continued acceptance of traditional-only signatures during an explicitly bounded transition period.

TLS Server Authentication Migration to post-quantum X.509 certificates is operationally complex due to the time required to establish new trust anchors, update validation infrastructure, and deploy new root certificates across clients. As noted in , these transitions require years of planning and must begin well before a CRQC is publicly known. For TLS server authentication, the certificate signature algorithms are governed by TLS and the issuing PKI, not by ACME. Post-quantum and PQ/T hybrid certificate authentication for TLS is addressed in . ACME deployments seeking quantum-ready server authentication follow that guidance.

JWS Request Authentication ACME request authentication relies on the integrity of JSON Web Signatures (JWS) produced with the client's account key. While JWS signatures cannot be retroactively forged, an adversary with a CRQC could forge them in real time to impersonate ACME clients and submit fraudulent certificate requests. As with TLS authentication, the risk that a CRQC may be available without public disclosure means that migration must be underway before the threat materialises. This document updates Section 6.2 of . ACME servers MAY support any JWS signature algorithm registered in the IANA "JSON Web Signature and Encryption Algorithms" registry . These include the post-quantum and PQ/T hybrid algorithms defined in (ML-DSA), (SLH-DSA), and (composite ML-DSA). This document does not mandate any particular algorithm or parameter set; selection is a matter of deployment and PKI policy. RFC 8555 Section 6.2 requires an ACME server to implement the ES256 signature algorithm. This document updates that requirement: an ACME server MAY choose not to implement ES256, and MAY implement any signature algorithm registered in the JOSE registry instead. A server that still implements ES256 for backward compatibility with existing clients MAY accept traditional-only JWS signatures during a transition period of its choosing.

Security Considerations The security considerations outlined in must be carefully evaluated and taken into account. Post-quantum algorithms selected for standardization are relatively new, and their implementations are still in the early stages of maturity. This makes them more susceptible to implementation bugs compared to the well-established and extensively tested cryptographic algorithms currently in use. Furthermore, certain deployments may need to continue using traditional algorithms to meet regulatory requirements, such as Federal Information Processing Standard (FIPS) 140-3 or Payment Card Industry (PCI) compliance. Hybrid key exchange provides a practical and flexible solution, offering protection against "Harvest Now, Decrypt Later" attacks while ensuring resilience to potential catastrophic vulnerabilities in any single algorithm. This approach allows for a gradual transition to PQC, preserving the benefits of traditional cryptosystems without requiring their immediate replacement. SLH-DSA signatures are substantially larger than ML-DSA or traditional signatures. ACME servers that accept SLH-DSA-authenticated JWS requests will have to account for the increased message size in request-size limits and resource provisioning, so that the larger signatures do not become a denial-of-service vector.

MITM Attacks with CRQC in ACME A MITM attack can occur if an adversary possesses a CRQC capable of breaking traditional public-key signature schemes. In such a scenario, the adversary can generate forged certificates and produce valid signatures, thereby impersonating a TLS peer (server or client). Consequently, the authentication guarantees of TLS have to be considered compromised when relying solely on traditional certificate-based authentication once a CRQC is available. The normative measures that mitigate this threat are specified in the mechanism sections of this document and are not restated here as independent requirements: The Quantum-Ready mechanism requires support for PQC-only or PQ/T hybrid authentication for both TLS server authentication () and JWS request authentication (), and permits traditional-only authentication only during an explicitly bounded transition period. Organizations operating PKI infrastructures are expected to define and implement a transition strategy toward issuing PQC or PQ/T hybrid certificates, phasing out certificates that rely exclusively on traditional cryptographic algorithms within a defined migration timeline as part of their quantum-readiness posture.

IANA Considerations This document has no IANA actions.

References Normative References This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. 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. 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. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Nokia University of the Bundeswehr Munich Post-quantum cryptography presents new challenges for device manufacturers, application developers, and service providers. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and supporting protocols such as DNS. Huawei Huawei Entrust Limited Nokia This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Post- Quantum Traditional (PQ/T) hybrid composite signatures. The composite algorithms described combine the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) as the post-quantum component and either the Elliptic Curve Digital Signature Algorithm (ECDSA) or the Edwards-Curve Digital Signature Algorithm (EdDSA) as the traditional component. mesur.io Tradeverifyd University of the Bundeswehr Munich Digital signatures are used within JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) to protect the integrity and authenticity of messages, such as JSON Web Signatures and signed COSE structures. This document specifies JOSE and COSE serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. The conventions for the associated algorithm identifiers, signatures, public keys, and private keys are also specified. Informative References National Institute of Standards and Technology (NIST) The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. Nokia Citrix Zscaler This document provides guidance for migration from traditional digital signature algorithms to post-quantum cryptographic (PQC) signature algorithms. It compares three models under discussion in the IETF for PKI-based protocols: composite certificates, dual certificates, and PQC certificates. The goal is to help operators and engineers working on cryptographic libraries, network security, and PKI/key management infrastructure select an approach that balances interoperability, security, and operational efficiency during the transition to post-quantum authentication.

Acknowledgements This draft leverages text from , and .