IETF Post-Quantum Work

PQC runs through TLS, LAMPS, IPSECME, SSH and CFRG/PQUIP. Some of this work is already published as RFCs, including XMSS/LMS, IKEv2 multiple key exchanges, PQ/T hybrid terminology, SSH sntrup761x25519, and the algorithm identifiers and encodings for ML-DSA, SLH-DSA and ML-KEM in X.509/CMS; but TLS hybrid ECDHE-ML-KEM, ML-DSA authentication in TLS, and composite certificates and composite KEM are still in Internet-Draft form, where wire formats and policy details can still change.

How the IETF fits in

A standardized algorithm is not deployable until a protocol knows how to negotiate it, a certificate knows how to encode it, and a message format knows how to wrap it. The IETF produces exactly these bindings, working group by working group. Because the lattice schemes are recent, much of this work is in draft and should be tracked as direction-of-travel rather than fixed specification.

TLS WG — securing the handshake

The flagship effort is hybrid key exchange, combining a classical curve with ML-KEM so a connection stays safe if either component holds. The NamedGroup defined/requested in the current draft-ietf-tls-ecdhe-mlkem includes X25519MLKEM768, with value 4588 / 0x11EC; until the RFC is published it should still be treated as a draft. Work on ML-DSA authentication in TLS (draft-ietf-tls-mldsa) is also progressing. Both are still Internet-Drafts. See TLS and Hybrid.

LAMPS WG — certificates and CMS

LAMPS defines how PQC appears in X.509 certificates and in CMS (signed/encrypted messages). These are now published RFCs: the X.509 algorithm identifiers are RFC 9881 (ML-DSA), RFC 9909 (SLH-DSA) and RFC 9935 (ML-KEM), and the CMS conventions are RFC 9882 (ML-DSA), RFC 9814 (SLH-DSA) and RFC 9936 (ML-KEM). LAMPS is still developing composite schemes — draft-ietf-lamps-pq-composite-sigs (Composite ML-DSA) and draft-ietf-lamps-pq-composite-kem (Composite ML-KEM) — that bind a post-quantum algorithm to a classical one, e.g. ML-DSA + ECDSA, so a certificate can satisfy both worlds. See X.509.

IPSECME WG — VPNs and IKEv2

Two RFCs already enable a quantum-safe VPN posture: RFC 9370 adds multiple, post-quantum key exchanges to IKEv2, and RFC 8784 mixes in post-quantum preshared keys. Together they let IPsec gain quantum resistance today, before lattice KEMs are fully profiled. See IPsec.

CFRG — combiners and hybrids

The Crypto Forum Research Group works on the cryptographic building blocks underneath protocols. RFC 9794 standardizes the terminology for post-quantum/traditional hybrid schemes, and individual drafts such as X-Wing (draft-connolly-cfrg-xwing-kem) define general-purpose hybrid KEMs that other working groups can reference.

Hash-based signatures — already standardized

Stateful hash-based signatures are mature and have RFCs: RFC 8391 (XMSS, Informational), RFC 8554 (LMS/HSS, Informational), RFC 9708 (HSS/LMS in CMS, obsoleting RFC 8708), and RFC 9802 (HSS/XMSS in X.509). They are conservative, well-understood choices for firmware and code signing — at the cost of careful state management.

RFCs vs drafts at a glance

Standards & references

• draft-ietf-tls-ecdhe-mlkem — Hybrid ECDHE-MLKEM Key Agreement for TLS 1.3
• draft-ietf-tls-mldsa — Use of ML-DSA in TLS 1.3
• RFC 9881 — ML-DSA algorithm identifiers for X.509
• RFC 9909 — SLH-DSA algorithm identifiers for X.509
• RFC 9935 — ML-KEM algorithm identifiers for X.509
• RFC 9882 — Use of ML-DSA in CMS
• RFC 9814 — Use of SLH-DSA in CMS
• RFC 9936 — Use of ML-KEM in CMS
• RFC 9794 — Terminology for Post-Quantum Traditional Hybrid Schemes
• RFC 9941 — published, Informational RFC; describes the widely-deployed OpenSSH sntrup761x25519-sha512 hybrid KEX
• RFC 9958 — Post-Quantum Cryptography for Engineers, published June 2026, Informational RFC