Quantum-Ready Profiles for ACME
draft-ar-acme-pqc-tlsjws-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Aritra Banerjee , Tirumaleswar Reddy.K | ||
| Last updated | 2026-06-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ar-acme-pqc-tlsjws-00
ACME A. Banerjee
Internet-Draft T. Reddy
Updates: RFC8555 (if approved) Nokia
Intended status: Standards Track 30 June 2026
Expires: 1 January 2027
Quantum-Ready Profiles for ACME
draft-ar-acme-pqc-tlsjws-00
Abstract
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). These profiles
define PQC or PQ/T TLS 1.3 key establishment and specify PQC or PQ/T
authentication mechanisms for JWS and TLS where required by the
selected quantum-ready profile. Together, these profiles enable ACME
clients and servers to achieve quantum-resistant confidentiality and
authentication.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ar-acme-pqc-tlsjws/.
Discussion of this document takes place on the acme Working Group
mailing list (mailto:acme@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/acme/. Subscribe at
https://www.ietf.org/mailman/listinfo/acme/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Banerjee & Reddy Expires 1 January 2027 [Page 1]
Internet-Draft Quantum-Ready ACME Profiles June 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Quantum-Ready TLS Channel Requirements . . . . . . . . . . . 5
4. Quantum-Ready Authentication . . . . . . . . . . . . . . . . 5
4.1. TLS Server Authentication . . . . . . . . . . . . . . . . 6
4.2. JWS Request Authentication . . . . . . . . . . . . . . . 6
4.3. Strict Quantum-Ready Profile . . . . . . . . . . . . . . 7
5. Additional Quantum-Ready Requirements for ACME . . . . . . . 7
5.1. DNSSEC with PQC Signatures . . . . . . . . . . . . . . . 8
5.2. URLs with PQC . . . . . . . . . . . . . . . . . . . . . . 8
6. Quantum Safe ACME JWS signature . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. MITM Attacks with CRQC in ACME . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Banerjee & Reddy Expires 1 January 2027 [Page 2]
Internet-Draft Quantum-Ready ACME Profiles June 2026
1. Introduction
The Automatic Certificate Management Environment (ACME [RFC8555])
automates certificate issuance, validation, and management over HTTPS
using JSON Web Signatures (JWS) [RFC7515] 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 [RFC8737].
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 mandates 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 profiles.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document also adopts terminology defined in [RFC9794].
For the purposes of this document, it is useful to categorize
cryptographic algorithms into three distinct classes:
Banerjee & Reddy Expires 1 January 2027 [Page 3]
Internet-Draft Quantum-Ready ACME Profiles June 2026
* 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 Profile: A deployment profile 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.
* Strict Quantum-Ready Profile: A Quantum-Ready Profile that
additionally rejects traditional-only authentication, requiring
post-quantum or PQ/T hybrid signature algorithms for both TLS
server authentication and JWS request authentication with no
traditional-only fallback.
Banerjee & Reddy Expires 1 January 2027 [Page 4]
Internet-Draft Quantum-Ready ACME Profiles June 2026
Selection of a Quantum-Ready Profile or Strict Quantum-Ready Profile
is a matter of deployment policy.
3. 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 [RFC8446] channel,
which protects ACME exchanges from passive observation during
transmission.
ACME deployments operating under a quantum-ready profile MUST use TLS
1.3 [RFC8446], 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 specified 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.
To protect against HNDL, ACME deployments operating under a quantum-
ready profile MUST adopt post-quantum or PQ/T hybrid key exchange
mechanisms for all TLS connections, as outlined in Section 4 of
[I-D.ietf-uta-pqc-app]. These mechanisms ensure that recorded TLS
sessions cannot be retrospectively decrypted.
4. 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
[I-D.reddy-pquip-pqc-signature-migration], 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
Banerjee & Reddy Expires 1 January 2027 [Page 5]
Internet-Draft Quantum-Ready ACME Profiles June 2026
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 mandates support for post-quantum or
PQ/T hybrid authentication mechanisms for quantum-ready ACME
profiles, while permitting continued acceptance of traditional-only
signatures during an explicitly bounded transition period.
4.1. 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 [I-D.reddy-pquip-pqc-signature-migration],
these transitions require years of planning and must begin well
before a CRQC is publicly known.
For TLS server authentication, ACME servers operating under a
quantum-ready profile:
* MUST support TLS server authentication using PQC-only or PQ/T
hybrid certificate signatures, following the authentication
guidance of [I-D.ietf-uta-pqc-app].
* MAY continue to accept traditional-only certificate signatures
during an explicitly bounded transition period.
4.2. JWS Request Authentication
ACME request authentication relies on the integrity of JSON Web
Signatures (JWS) [RFC7515]. 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 [RFC8555].
ACME servers operating under a quantum-ready profile MUST implement
ML-DSA-44, ML-DSA-65, and ML-DSA-87 [RFC9964] and the composite ML-
DSA algorithm pairing ML-DSA-44 with ECDSA-P256
[I-D.ietf-jose-pq-composite-sigs]. Such servers SHOULD also
implement SLH-DSA-SHAKE-128s, SLH-DSA-SHAKE-192s, and SLH-DSA-SHAKE-
256s [I-D.ietf-cose-sphincs-plus] and the composite ML-DSA algorithms
Banerjee & Reddy Expires 1 January 2027 [Page 6]
Internet-Draft Quantum-Ready ACME Profiles June 2026
pairing ML-DSA-65 with Ed25519 and ML-DSA-87 with Ed448
[I-D.ietf-jose-pq-composite-sigs]. ES256 remains mandatory-to-
implement for backward compatibility during the transition period.
ACME servers MAY accept traditional-only JWS signatures during an
explicitly bounded transition period, except when operating under the
Strict Quantum-Ready Profile.
The JWS "alg" values named in this section are registered in the IANA
"JSON Web Signature and Encryption Algorithms" registry established
by [RFC7518].
This profile uses SLH-DSA with SHAKE rather than SHA-2. ML-DSA and
SLH-DSA-SHAKE both rely only on SHAKE, so this choice lets every
post-quantum signature in the profile use a single hash primitive,
avoiding a separate SHA-2 implementation needed only by SLH-DSA-SHA2
and reducing the number of distinct primitives. Composite ML-DSA
complements this by combining a post-quantum signature with a
traditional one (e.g., ECDSA or RSA), so a certificate remains secure
as long as either component holds. This provides hybrid assurance
during migration and lowers deployment risk for ACME clients and
existing PKI that are not yet ready to rely on a post-quantum
algorithm alone.
The security properties of these composite algorithms, including
their strong-unforgeability (SUF-CMA) characteristics, are described
in the Security Considerations of [I-D.ietf-jose-pq-composite-sigs].
4.3. Strict Quantum-Ready Profile
The Strict Quantum-Ready Profile is intended for deployments that
require quantum-resistant authentication (e.g., high-assurance
environments or regulatory-driven profiles). Under this profile:
* TLS server authentication and JWS request authentication MUST use
PQC-only or PQ/T hybrid signature algorithms.
* Any fallback to traditional-only signature algorithms MUST be
rejected.
5. Additional Quantum-Ready Requirements for ACME
Banerjee & Reddy Expires 1 January 2027 [Page 7]
Internet-Draft Quantum-Ready ACME Profiles June 2026
5.1. DNSSEC with PQC Signatures
When the DNS-01 challenge type is used, ACME servers rely on DNSSEC
to authenticate the DNS records associated with the validation.
However, the DNSSEC ecosystem does not yet have standardized use of
post-quantum signature algorithms, and the IETF is still evaluating
the feasibility and operational impact of introducing PQC into
DNSSEC. As a result, DNSSEC today remains dependent on traditional
algorithms such as RSA and ECDSA, which are vulnerable to future
CRQCs.
Given these limitations, ACME servers SHOULD assess the strength of
the DNSSEC validation chain and treat DNSSEC dependencies on
traditional-only algorithms as providing reduced or uncertain long-
term authentication guarantees in the presence of CRQCs. Once DNSSEC
supports PQC, ACME servers and CAs are expected to migrate DNS-01
validation policies accordingly.
5.2. URLs with PQC
When operating under a quantum-ready ACME profile, all URLs provided
by the ACME directory (e.g., newAccount, newOrder, revokeCert) MUST
be accessible over HTTPS endpoints that use post-quantum or PQ/T
hybrid key exchange mechanisms, consistent with the TLS channel
requirements of Section 3.
The certificate authentication presented on these endpoints is the
TLS server authentication described in Section 4.1 and is governed by
the authentication policy of the selected quantum-ready profile.
This section imposes no separate or additional authentication
requirement.
6. Quantum Safe ACME JWS signature
Following is an example for ACME JWS signature:
Banerjee & Reddy Expires 1 January 2027 [Page 8]
Internet-Draft Quantum-Ready ACME Profiles June 2026
POST /acme/authz/1234/2
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ML-DSA-44",
"kid": "https://example.com/acme/acct/1",
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/authz/1234/2"
}),
"payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
7. Security Considerations
The security considerations outlined in [RFC9958] 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 [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.
Banerjee & Reddy Expires 1 January 2027 [Page 9]
Internet-Draft Quantum-Ready ACME Profiles June 2026
7.1. 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
profile sections of this document and are not restated here as
independent requirements:
* The Quantum-Ready Profile requires support for PQC-only or PQ/T
hybrid authentication for both TLS server authentication
(Section 4.1) and JWS request authentication (Section 4.2), and
permits traditional-only authentication only during an explicitly
bounded transition period.
* The Strict Quantum-Ready Profile rejects any authentication that
relies solely on traditional signature algorithms, with no
fallback (Section 4.3).
Independent of the selected profile, 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.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[I-D.ietf-cose-sphincs-plus]
Prorock, M., Steele, O., and H. Tschofenig, "SLH-DSA for
JOSE and COSE", Work in Progress, Internet-Draft, draft-
ietf-cose-sphincs-plus-08, 15 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
sphincs-plus-08>.
Banerjee & Reddy Expires 1 January 2027 [Page 10]
Internet-Draft Quantum-Ready ACME Profiles June 2026
[I-D.ietf-jose-pq-composite-sigs]
Prabel, L., Shuzhou, S., Gray, J., and T. Reddy.K, "PQ/T
Hybrid Composite Signatures for JOSE and COSE", Work in
Progress, Internet-Draft, draft-ietf-jose-pq-composite-
sigs-01, 27 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-pq-
composite-sigs-01>.
[I-D.ietf-uta-pqc-app]
Reddy.K, T. and H. Tschofenig, "Post-Quantum Cryptography
Recommendations for TLS-based Applications", Work in
Progress, Internet-Draft, draft-ietf-uta-pqc-app-02, 22
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-uta-pqc-app-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[RFC8737] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) TLS Application-Layer Protocol
Negotiation (ALPN) Challenge Extension", RFC 8737,
DOI 10.17487/RFC8737, February 2020,
<https://www.rfc-editor.org/rfc/rfc8737>.
Banerjee & Reddy Expires 1 January 2027 [Page 11]
Internet-Draft Quantum-Ready ACME Profiles June 2026
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/rfc/rfc9794>.
[RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing
and Encryption (JOSE) and CBOR Object Signing and
Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May
2026, <https://www.rfc-editor.org/rfc/rfc9964>.
9.2. Informative References
[FIPS-140-3]
National Institute of Standards and Technology (NIST),
"Security Requirements for Cryptographic Modules",
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>.
[I-D.reddy-pquip-pqc-signature-migration]
Reddy.K, T., Wing, D., and Y. Rosomakho, "Guidance for
Migration to Composite, Dual, or PQC Authentication", Work
in Progress, Internet-Draft, draft-reddy-pquip-pqc-
signature-migration-01, 14 October 2025,
<https://datatracker.ietf.org/doc/html/draft-reddy-pquip-
pqc-signature-migration-01>.
[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
<https://www.rfc-editor.org/rfc/rfc9958>.
Appendix A. Acknowledgements
This draft leverages text from [RFC8555], [RFC8737] and
[I-D.ietf-uta-pqc-app].
Authors' Addresses
Aritra Banerjee
Nokia
London
United Kingdom
Email: aritra.banerjee@nokia.com
Banerjee & Reddy Expires 1 January 2027 [Page 12]
Internet-Draft Quantum-Ready ACME Profiles June 2026
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.com
Banerjee & Reddy Expires 1 January 2027 [Page 13]