up:: The Mandates MOC

IETF PQUIP WG

PQUIP is the Internet Engineering Task Force’s Post-Quantum Use In Protocols working group, the coordination venue chartered to keep post-quantum cryptography consistent across the internet’s protocols as each one gets its quantum-safe upgrade. It sits one layer above the protocol-specific working groups that actually rewrite TLS, IPsec, SSH, and X.509, and its job is coordination rather than protocol surgery: shared vocabulary, shared engineering guidance, and consistent patterns for how a classical scheme and a post-quantum scheme get combined, so that the migration stays coherent across a dozen protocols instead of splitting into incompatible dialects.

Its two flagship deliverables are published RFCs, the engineer-facing “Post-Quantum Cryptography for Engineers” (RFC 9958) and the shared vocabulary of “Terminology for Post-Quantum Traditional Hybrid Schemes” (RFC 9794).

PQUIP carries no deadline and binds no one directly. It is a standards-coordination group, and its influence is that its guidance shapes how every other IETF protocol group implements post-quantum cryptography, which makes it the canonical vendor-independent citation when a migration plan needs authoritative implementer-facing guidance rather than a marketing claim.

The short version:

1. PQUIP is an IETF working group in the Security area, chartered to support the IETF-wide transition to post-quantum cryptography and to document the operational guidance that goes with it.
2. It is a coordination venue, not a protocol-editing group. Its charter explicitly says it will not update existing protocols, specify new protocols, define new cryptographic mechanisms, or judge whether a mechanism is quantum-resistant.
3. The protocol-specific work happens in the maintenance working groups: TLS in the TLS WG, IPsec in IPSECME, X.509 and certificates in LAMPS, and constrained-object formats in COSE. PQUIP keeps them consistent and serves as the venue of last resort for PQC issues that have no home group.
4. Its two flagship outputs are RFC 9958, “Post-Quantum Cryptography for Engineers” (Informational, June 2026), and RFC 9794, “Terminology for Post-Quantum Traditional Hybrid Schemes” (Informational, June 2025).
5. Active drafts in progress cover hash-based-signature state and backup management, hybrid signature spectrums, and adapting constrained devices for post-quantum cryptography.

Think of the internet’s protocols as a city where every building needs the same new lock, and each building has its own contractor. PQUIP is not any of those contractors. It is the standards office that publishes the shared spec sheet and the common vocabulary, so that the lock installed on the TLS door, the IPsec door, and the certificate door all interoperate instead of each contractor inventing an incompatible fitting.

What is the IETF PQUIP working group?

PQUIP is the Post-Quantum Use In Protocols working group, an IETF working group in the Security area whose stated focus is to support the growing body of IETF work that moves internet protocols onto post-quantum cryptography. Its charter frames the purpose directly: to “facilitate the evolution of IETF protocols and document associated operational guidance with respect to PQC.”

1. Where it sits. PQUIP is chartered in the IETF’s Security area, chaired by Paul E. Hoffman, under the responsible Security area director. The IETF is the open international body whose output, RFCs, is adopted globally by protocol implementers, so PQUIP’s guidance travels wherever internet protocols travel.
2. What it deliberately does not do. The charter draws a hard line around scope. PQUIP “will not update existing protocols, specify new protocols, define new cryptographic mechanisms, or assess whether a given cryptographic mechanism is quantum-resistant.” That keeps it a coordination and guidance body rather than a competitor to the protocol groups or to the algorithm standardizers.
3. The venue-of-last-resort role. PQUIP also serves as the place to discuss post-quantum issues in IETF protocols that have no dedicated maintenance working group, so a PQC question that would otherwise fall through the cracks has a home.

Source: IETF, “Post-Quantum Use In Protocols (PQUIP) Working Group,” charter and about page, datatracker.ietf.org/wg/pquip/about.

How does PQUIP wire post-quantum cryptography into real protocols?

PQUIP does the wiring indirectly, by coordinating the protocol-specific working groups that carry out the actual protocol changes and by publishing the shared guidance and vocabulary those groups build on. The concrete protocol updates land in the maintenance groups, and PQUIP keeps them from diverging.

Protocol surface	Where the protocol work happens	What PQUIP contributes
TLS	The TLS working group	Shared hybrid terminology and engineering guidance the TLS hybrid key-exchange work draws on
IPsec	The IPSECME working group	Consistent PQC patterns and the shared vocabulary for hybrid key establishment
SSH	The relevant transport maintenance work	Cross-protocol guidance so the SSH approach matches the others
X.509 and certificates	The LAMPS working group	Coordination on certificate and PKI-facing PQC, kept consistent with the rest
Constrained object formats	The COSE working group	Guidance feeding the constrained-device work

Source: IETF, “PQUIP Working Group,” charter, datatracker.ietf.org/wg/pquip/about.

The value of this arrangement is consistency. When the same classical-plus-post-quantum hybrid idea has to land in TLS, IPsec, and SSH, PQUIP is what stops each group from coining its own incompatible terminology or its own subtly different combiner pattern, which is the same interoperability problem that cryptographic interoperability work exists to prevent.

What has PQUIP published?

PQUIP’s two flagship deliverables have both moved from draft to published RFC, and several more drafts are working through the process. The published RFCs are informational, meaning they carry guidance and vocabulary rather than a normative protocol requirement, which fits a coordination group.

Document	Title	Status and date
RFC 9958	Post-Quantum Cryptography for Engineers	Informational, June 2026
RFC 9794	Terminology for Post-Quantum Traditional Hybrid Schemes	Informational, June 2025

Source: IETF, “PQUIP Working Group Documents,” datatracker.ietf.org/wg/pquip/documents.

1. RFC 9958, “Post-Quantum Cryptography for Engineers.” The implementer-facing guidance document, a roughly 42-page informational RFC that gives engineers a practical grounding in post-quantum cryptography for protocol work. It is the citation to reach for when a client wants an authoritative, vendor-independent primer that an engineering team can act on.
2. RFC 9794, “Terminology for Post-Quantum Traditional Hybrid Schemes.” The shared-vocabulary document. It pins down the terms other working groups use when they describe combining a traditional (classical) scheme with a post-quantum one, so that “hybrid” means the same thing across TLS, IPsec, and the rest.

Active internet-drafts still in progress, per the working-group document list, include “Hash-based Signatures: State and Backup Management” (draft-ietf-pquip-hbs-state), “Hybrid signature spectrums” (draft-ietf-pquip-hybrid-signature-spectrums), and “Adapting Constrained Devices for Post-Quantum Cryptography” (draft-ietf-pquip-pqc-hsm-constrained), the last of which connects to the constrained-device problem.

Source: IETF, “PQUIP Working Group Documents,” datatracker.ietf.org/wg/pquip/documents.

Who does PQUIP guidance reach?

PQUIP binds no one directly, and its influence runs through the implementers and standards groups that build on its output. The audiences fall into three tiers:

1. The IETF protocol working groups. The primary audience. TLS, IPSECME, LAMPS, and COSE build their post-quantum protocol changes on PQUIP’s shared terminology and engineering guidance, so PQUIP’s work shapes what those groups produce.
2. Protocol implementers and library maintainers. The teams building TLS stacks, IPsec appliances, SSH implementations, and certificate tooling read RFC 9958 for engineering grounding and RFC 9794 for consistent vocabulary, so PQUIP reaches the code that ships.
3. Consultancies, auditors, and buyers. PQUIP’s RFCs are the canonical vendor-independent citation for implementer-facing post-quantum guidance, so a migration plan or a procurement requirement can point at RFC 9958 and RFC 9794 as neutral authorities rather than relying on any one vendor’s documentation.

Source: IETF, “PQUIP Working Group,” charter, datatracker.ietf.org/wg/pquip/about.

How does PQUIP relate to the other mandates and standards?

PQUIP is the internet-protocol coordination node in a wider stack, and it deliberately does not overlap with the algorithm standardizers or the national mandates.

1. NIST FIPS suite. NIST standardized the algorithms in FIPS 203, FIPS 204, and FIPS 205. PQUIP takes those as given and coordinates how they get used in protocols, since its charter forbids defining new mechanisms.
2. The protocol working groups. The TLS WG, IPSECME, LAMPS, and COSE do the protocol surgery. PQUIP keeps them consistent and catches the orphan cases.
3. ETSI. ETSI’s TS 103 744 is the European specification for hybrid key exchange, and it is the counterpart to the IETF’s protocol-level hybrid work that PQUIP helps coordinate. Both rest on the same combine-classical-with-post-quantum idea.
4. The national mandates. CNSA 2.0, BSI, and ANSSI set the policy deadlines and strategy. PQUIP’s guidance is what the engineering teams lean on when they turn those policies into working protocol deployments, and RFC 9794’s hybrid vocabulary underpins the hybrid deployments those bodies recommend.
5. Hybrid cryptography. RFC 9794 is the document that standardizes the language for describing hybrid traditional-plus-post-quantum schemes, so it is the vocabulary layer under the hybrid deployments the rest of the field guide describes.

Common misconceptions

1. “PQUIP defines post-quantum algorithms.” It does not, and its charter explicitly forbids it. NIST defines the algorithms. PQUIP coordinates how they are used in protocols.
2. “PQUIP rewrites TLS and IPsec.” No. The protocol changes happen in the maintenance working groups, TLS in the TLS WG and IPsec in IPSECME. PQUIP coordinates across them and provides shared guidance and terminology.
3. “PQUIP’s RFCs are mandatory protocol requirements.” RFC 9958 and RFC 9794 are Informational RFCs, so they carry guidance and vocabulary rather than a normative protocol mandate. Their weight is that other groups and implementers build on them.
4. “PQUIP judges which algorithms are quantum-safe.” It does not assess whether a given mechanism is quantum-resistant. That evaluation happens elsewhere, in the algorithm standardization and cryptanalysis communities.
5. “PQUIP is a deadline you have to meet.” PQUIP sets no dates and binds no one. The deadlines live in the mandates. PQUIP is the guidance that helps you meet them cleanly.

Questions people ask

What does PQUIP actually do? It coordinates the IETF-wide move to post-quantum cryptography, publishing shared engineering guidance and terminology so that the protocol-specific working groups, TLS, IPSECME, LAMPS, and COSE, implement PQC consistently. It also serves as the discussion venue for PQC issues in protocols that have no dedicated maintenance group.

Does PQUIP change TLS or IPsec directly? No. The TLS working group changes TLS and IPSECME changes IPsec. PQUIP sits above them as coordination and guidance, and its charter explicitly rules out editing existing protocols itself.

What are RFC 9958 and RFC 9794? RFC 9958 is “Post-Quantum Cryptography for Engineers,” the implementer-facing guidance document from June 2026. RFC 9794 is “Terminology for Post-Quantum Traditional Hybrid Schemes,” the shared-vocabulary document from June 2025 that pins down what “hybrid” means across protocols.

Why should a migration plan cite PQUIP? Because its RFCs are authoritative and vendor-independent. When a plan needs neutral implementer-facing guidance for how post-quantum cryptography goes into protocols, RFC 9958 and RFC 9794 are the canonical citations, rather than any single vendor’s documentation.

How does PQUIP relate to ETSI’s hybrid work? They are counterparts. ETSI’s TS 103 744 is the European hybrid-key-exchange specification, and the IETF protocol work PQUIP coordinates is the internet-protocol path. Both rest on combining a classical key exchange with a post-quantum KEM.

---

Everything here is the map, given freely. When your team needs the IETF’s protocol-level post-quantum guidance translated into a hybrid rollout sequenced across your own TLS, IPsec, SSH, and certificate surfaces, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.