Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab) are defined in the glossary.
Read this first
A post-quantum ACME trial must test four independent cryptographic surfaces: TLS key exchange, TLS server authentication, the account-key JWS signature and the issued certificate chain. Capture evidence for each surface separately, refuse silent downgrade, and exercise account rollover, renewal and revocation. The current ACME PQC proposal is an individual Internet-Draft, not an IETF standard or a production profile.
The Automated Certificate Management Environment, or ACME, automates certificate requests, domain-control challenges, issuance, renewal and revocation. A client can complete that workflow even when only one part of the connection is post-quantum. A hybrid TLS group may protect the transport while the server certificate, account signature or issued certificate remains classical.
The 28 October 2026 revision of draft-ar-acme-pqc-tlsjws proposes a quantum-ready ACME profile that combines post-quantum or hybrid TLS with post-quantum account JWS signatures. Revision 01 is an individual Standards Track proposal and work in progress. Pin that exact revision in the test record and treat its algorithm choices as hypotheses to validate, not as a stable deployment contract.
Start by adding the ACME directory, client, server, reverse proxy, trust store, certificate profile and every enabled algorithm to the cryptographic inventory. The result should show where post-quantum protection begins and ends instead of assigning one label to the whole service.
Separate the four cryptographic surfaces
| Surface | Evidence to capture | Required failure |
|---|---|---|
| TLS key exchange | TLS 1.3 ServerHello named group, client offer and shared transcript | Fail when policy requires a hybrid group and the server selects a classical-only group |
| TLS server authentication | Server certificate chain, signature algorithms, trust result and hostname validation | Reject an untrusted, expired, policy-ineligible or mismatched certificate |
| ACME account JWS | Protected alg, nonce, url and kid or jwk fields plus signature verification result | Reject an unsupported algorithm, replayed nonce, changed URL or invalid signature |
| Issued certificate | Subject key algorithm, issuer signature algorithm, extensions, chain and relying-party result | Reject a profile, extension or chain that violates the order policy |
Do not infer one row from another. RFC 10024 hybrid key exchange does not prove post-quantum server authentication. A post-quantum account JWS does not prove that the new certificate or its issuer chain uses post-quantum signatures. An ML-KEM public key in an X.509 certificate is a key-management credential, not a digital-signature credential.
Freeze a reproducible test matrix
Record exact builds and configuration before the first order. An algorithm name without the implementation, protocol revision and policy state is not enough evidence to reproduce a result.
- Pin the ACME client and server commits, the draft revision, TLS library, reverse-proxy build and operating system.
- Record the directory URL, challenge type, account-key algorithm, requested certificate profile and trust anchors.
- List every offered and accepted TLS named group, server-certificate signature algorithm and JWS algorithm.
- Keep packet captures, ACME problem documents, server audit events, certificate objects and verifier results under one trial identifier.
- Define the minimum acceptable cryptographic floor before testing fallback or retry behavior.
Prove the TLS channel before testing ACME
The proposal requires TLS 1.3 or later. Capture the ClientHello and ServerHello and verify the selected named group. RFC 10024 defines the hybrid groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. A successful HTTPS connection is not sufficient evidence because a server can negotiate a classical-only group that the client also offered.
Exercise HelloRetryRequest, session resumption and reconnects through the production proxy path. Confirm that a retry cannot cross below the required floor. Then validate the server certificate independently: issuer chain, name constraints, hostname, validity period, revocation policy and signature algorithm. Save the selected group and authenticated chain from the same connection.
Do not collapse key exchange and authentication
Hybrid key exchange can protect confidentiality against a future quantum computer while the server still authenticates with a classical signature. That can be an intentional transition state, but it must be visible in policy and evidence.
Verify the account JWS as a separate control
ACME requests are signed JSON Web Signatures. Under RFC 8555, a request's protected header carries alg, nonce, url and either kid or jwk, depending on account state. Test the complete protected object. A valid post-quantum signature over the wrong URL or a reused nonce is still an invalid ACME request.
The draft points to ML-DSA from RFC 9964, SLH-DSA work and composite ML-DSA work, but it deliberately does not mandate one parameter set. Keep the allowed set explicit on both client and server. If ES256 remains enabled for a bounded migration period, record the precise conditions under which it is allowed and prove that a required post-quantum account cannot silently fall back to it.
| Mutation | Expected result | Evidence |
|---|---|---|
| Change alg without changing the signature | Unauthorized or malformed request | ACME problem document and verifier event |
| Replay a valid nonce | badNonce or equivalent rejection | Nonce identifier and server rejection |
| Change the protected url | Request rejected before order processing | Protected header and audit event |
| Replace kid with an unrelated account | Account authorization fails | Account identifier and response |
| Truncate or enlarge the signature | Bounded parser failure without a crash | HTTP status, memory and latency |
| Use a disabled classical algorithm | Policy rejection without a weaker retry | Policy event and client trace |
Large signatures also change the operational test. The draft calls out SLH-DSA message size as a denial-of-service consideration. Measure request bytes, verification latency, memory, concurrent-request behavior and the limits imposed by gateways, web application firewalls and ACME rate controls.
Trace one order through the whole lifecycle
Follow a new account and order from directory discovery to certificate download. Capture each state transition rather than treating the final HTTP success as the only checkpoint.
- Fetch a fresh nonce and create the account with the intended post-quantum JWS algorithm.
- Create an order and confirm every identifier and requested profile.
- Complete the authorization challenge without changing the account-key policy.
- Submit the CSR and verify that its public key, signature and requested extensions match the profile.
- Download the certificate and build the complete chain with the intended trust anchors.
- Repeat the flow for renewal, revoke the result and confirm that relying parties observe the revocation policy.
- Roll the account key and prove that the old key no longer authorizes new requests.
Domain-control challenges prove control of an identifier; they do not prove that the certificate profile is post-quantum. Keep challenge success separate from CSR verification, certificate issuance and relying-party validation.
Inspect the issued certificate by purpose
RFC 9881 defines X.509 algorithm identifiers and encodings for ML-DSA signature keys. RFC 9935 defines ML-KEM keys for X.509, but ML-KEM is a key-encapsulation mechanism and cannot sign a TLS CertificateVerify message. The certificate's algorithm must therefore match its intended use, extensions and verifier behavior.
Test the actual chain that applications will receive. Record the subject public-key algorithm, each certificate signature algorithm, key-usage and extended-key-usage extensions, path length, encoded size and validation result. Run the same chain through browsers, gateways, load balancers, service meshes and monitoring tools that matter to the deployment. The certificate and key-format acceptance guide provides a deeper interoperability matrix.
Build an explicit downgrade matrix
| TLS key exchange | Server authentication | Account JWS | Issued certificate | Decision |
|---|---|---|---|---|
| Hybrid | Classical | Post-quantum | Post-quantum signature | Allowed only if the documented transition policy permits classical server authentication |
| Hybrid | Classical | Classical | Classical | Classical transition state, not post-quantum ACME |
| Classical | Post-quantum | Post-quantum | Post-quantum signature | Reject when hybrid key exchange is mandatory |
| Hybrid | Post-quantum | Post-quantum | Classical | Reject when the requested profile requires a post-quantum certificate |
| Hybrid | Post-quantum | Post-quantum | Post-quantum signature | Candidate for the full acceptance suite |
For every rejected row, show that the client stops with a clear error. Automatic retry into a weaker row is a security defect unless an explicit, time-bounded exception authorizes it. Add that floor and the rollback conditions to the PQC migration roadmap.
Set a staged acceptance gate
- Protocol gate: all four surfaces are visible and match the pinned profile.
- Negative-test gate: corrupted, replayed and policy-ineligible requests fail closed.
- Lifecycle gate: issuance, renewal, revocation and account-key rollover work with the same floor.
- Interoperability gate: every required proxy, CA component and relying party processes the objects correctly.
- Capacity gate: larger handshakes, JWS objects, CSRs and chains remain inside measured latency, memory and transport budgets.
- Operations gate: telemetry identifies the selected algorithms and alerts on downgrade or repeated policy failure.
- Governance gate: the owner, exception expiry, rollback condition and production decision are documented.
A controlled post-quantum audit can use this evidence to distinguish a working primitive from a working service. A migration engagement can then turn the failed matrix cells into owned remediation work, while certification support can preserve the tested profile and evidence set for external review.
What this test does not prove
Passing the suite does not make the Internet-Draft final, prove every implementation secure, establish regulatory approval or guarantee interoperability with products outside the matrix. It also does not eliminate the classical components of an approved transition design. Production authorization still needs a threat model, implementation review, operational capacity evidence and a policy decision about any hybrid or classical dependency.
The useful outcome is narrower: a repeatable record showing which ACME surfaces used which algorithms, how the system behaved under downgrade and failure, and whether the complete certificate lifecycle stayed above the chosen cryptographic floor.
Primary sources
- IETF Datatracker, Post-Quantum Cryptography for ACME: TLS and JWS Enhancements, draft-ar-acme-pqc-tlsjws-01, 28 October 2026.
- IETF, RFC 8555: Automatic Certificate Management Environment, March 2019.
- IETF, RFC 10024: Hybrid Post-Quantum Key Agreement for TLS 1.3, October 2026.
- IETF, RFC 9881: Internet X.509 Public Key Infrastructure Algorithm Identifiers for ML-DSA, 2026.
- IETF, RFC 9935: Internet X.509 Public Key Infrastructure Algorithm Identifiers for ML-KEM, 2026.
- IETF, RFC 9964: JSON Web Algorithms for ML-DSA, 2026.
Where this goes next