Summary

The label does not set the closing hour

Picture two certificate servers with the same “quantum-ready” sign on the door. Both move ACME traffic onto TLS 1.3 with post-quantum or hybrid key exchange. Both understand newer authentication. One refuses an old ES256 account signature tonight. The other continues to take it next year. For a client trying to obtain a certificate, that difference is the whole security policy.

The June text tried to name that difference. Its Strict Quantum-Ready Profile required post-quantum-only or hybrid signatures on both the TLS server and the client's JWS request, with no traditional-only fallback. The October revision deletes the strict section. It keeps a single “Quantum-Ready Mechanism”: protected TLS key exchange and support for new authentication, with traditional-only authentication allowed during an explicitly bounded transition. It says choosing this mechanism is a deployment-policy decision.

The change goes beyond a heading. June named ML-DSA variants and a composite signature as mandatory implementations for participating ACME servers, while preserving ES256. October §4.2 says servers may support any signature algorithm in the JOSE registry and mandates no particular algorithm or parameter set. It proposes that a server may choose not to implement ES256 at all. A server that retains ES256 may accept traditional-only JWS signatures for a transition period of its choosing. That is a real knob in the hands of the certificate service and its PKI policy owners.

There is also a sentence the authors still need to settle. The October introduction describes post-quantum and hybrid signatures as mandatory to implement for quantum-ready authentication. Section 4.2 then says “MAY” and expressly declines to mandate any particular JWS algorithm. An implementer cannot build a shared conformance test from those two instructions without deciding which one wins. The source text contains the conflict; it offers no deployment trace that resolves it.

The two cryptographic layers address different exposures. Post-quantum or hybrid TLS key exchange aims to protect recorded ACME traffic from later decryption. JWS signatures authenticate live requests made with an account key. If an attacker could forge a traditional account signature, a server still accepting it could receive a fraudulent certificate order. The draft places TLS certificate authentication in the TLS and issuing-PKI rules, while the ACME server controls what account signatures it will take. A shiny transport tunnel does not close the request-authentication side door.

The Datatracker calls this an active individual Internet-Draft, not an adopted IETF rule. The draft gives no date when every operator must turn off old signatures. A published interoperability test naming accepted algorithms, rejecting traditional-only requests and documenting the cutoff would show what an implementation actually enforces.

Sources: October revision; June revision; RFC 8555; IETF status.