# IETF PQUIP Drafts: The Internet Engineering PQC Push **Source**: https://quantumsequrity.com/blog/ietf-pquip-drafts **Category**: Standards & Documents --- [← Back to Blog](../../blog.html) Standards & Documents # IETF PQUIP Drafts: The Internet Engineering PQC Push 12 min read NIST writes the algorithms. ETSI writes the migration framework. ISO/IEC writes the international standards. But the people who actually plug post-quantum cryptography into TLS, IPsec, SSH, and X.509 work in the IETF (Internet Engineering Task Force). Without the IETF's protocol-level work, even a perfectly standardized algorithm sits on the shelf unable to be used in real applications. The IETF created the Post-Quantum Use In Protocols (PQUIP) working group in 2023 specifically to coordinate this. PQUIP is the central forum for protocol-level PQC integration: algorithm code points, hybrid combiner specifications, deployment guidance, transition strategies. It feeds output to the working groups that own specific protocols (TLS, LAMPS for X.509, IPSECME, SSH). This post walks through what PQUIP is, what its current drafts cover, and how protocol migration is organized across IETF working groups. For developers tracking when ML-KEM lands in OpenSSL or when ML-DSA can be used in X.509 certificates, the IETF drafts are where to look. ## What PQUIP Is PQUIP stands for "Post-Quantum Use In Protocols." It is an IETF working group, not a research group. The mission: - Coordinate PQC integration across IETF protocol working groups - Maintain a centralized list of PQC algorithm code points - Publish guidance documents on hybrid mode, migration strategies, common pitfalls - Avoid duplication and divergence across protocols PQUIP does not own any protocol. TLS PQC work happens in the TLS working group. X.509 PQC happens in LAMPS. IPsec PQC happens in IPSECME. PQUIP's role is to provide common infrastructure (code points, hybrid combiner spec, etc.) that all of them can reference. ## Why a Coordinated Effort Without coordination, each working group could pick different algorithm code points, different hybrid combiners, different naming conventions. Implementations would have to handle 20 variants of essentially the same thing. Bugs and interop failures would proliferate. PQUIP's coordination output: - **Single algorithm registry**: ML-KEM-512 has one code point that TLS, IPsec, SSH, X.509 all use - **Consistent hybrid combiner**: HKDF-based concatenation pattern matching ETSI TS 103 744 - **Unified naming**: ml-kem-512, not "kyber-512" or "Crystals-Kyber-512" - **Shared guidance**: hybrid mode, transition timelines, common implementation pitfalls This makes implementations cleaner and migration smoother. ## Active PQUIP Drafts As of 2026, several PQUIP drafts are in active development. Highlights: ### draft-ietf-pquip-pqc-engineers A guidance document for engineers implementing PQC. Covers: - Algorithm overview (ML-KEM, ML-DSA, SLH-DSA, FN-DSA) - Implementation pitfalls (constant-time, side channels, RNG quality) - Hybrid mode patterns - Compliance considerations This draft is widely cited by IETF authors and serves as a primer for protocol-specific work. ### draft-ietf-pquip-hybrid-signature-spectrums Hybrid signature schemes are more complex than hybrid KEMs. There are multiple ways to combine classical and PQC signatures: nested, concatenated, dual, composite. This draft surveys the options and recommends patterns for specific use cases. ### draft-ietf-pquip-pqc-policy-considerations Policy considerations document for organizations planning PQC deployment. Covers compliance, certification, transition timelines, and the relationship to NIST FIPS, NSA CNSA 2.0, and other regulatory frameworks. ### Others Various drafts cover specific topics: composite signatures (draft-ounsworth-pq-composite-sigs), hash-based signatures usage (draft-ietf-pquip-hash-sig-considerations), and more. The full list lives at the PQUIP working group page on datatracker.ietf.org. ## How PQUIP Relates to Other Working Groups ### TLS Working Group The TLS WG owns the TLS protocol. PQC additions to TLS: - **draft-ietf-tls-hybrid-design**: hybrid KEX for TLS 1.3 - **draft-ietf-tls-mlkem**: ML-KEM as a TLS named group (with or without hybrid) - Various drafts on PQ certificates, signatures in TLS PQUIP coordinates the algorithm code points TLS uses; TLS WG decides how to integrate them into the protocol. See [IETF PQC internet drafts](../ietf-pqc-internet-drafts.html). ### LAMPS Working Group LAMPS (Limited Additional Mechanisms for PKIX and SMIME) handles X.509 certificate format additions. PQC X.509 work: - ML-DSA in X.509 certificates - SLH-DSA in X.509 certificates - Composite signatures in X.509 - CSR (certificate signing request) extensions for PQC LAMPS coordinates with PQUIP on algorithm OIDs (object identifiers) and certificate format details. ### IPSECME Working Group IPSECME owns IPsec and IKEv2. PQC integrations: - Hybrid PQ KEM in IKE_SA_INIT - PQC signature additions for IKEv2 authentication - Migration guidance for VPN deployments IPsec is critical for VPN, especially in government and enterprise settings. PQ IPsec is high priority. ### SSH (CURDLE Working Group) SSH historically came under the SECDIR area; recent PQC work happens in the CURDLE (CURves, Deprecating, and a Little more Encryption) WG and others. PQ SSH includes: - ML-KEM hybrid for SSH key exchange - ML-DSA for SSH user and host keys - Backward compatibility considerations ### CFRG (Crypto Forum Research Group) CFRG is a research group, not a WG, but it influences PQUIP heavily. CFRG publishes RFCs on cryptographic constructions (HPKE, HKDF, AES-GCM-SIV) and is the forum for cryptographic algorithm design. CFRG's role for PQC: research-quality analysis of hybrid combiners, PQC schemes, side-channel considerations. PQUIP picks up CFRG output and applies it to protocols. ## The IANA Code Point Registry For algorithms to be used in protocols, they need numeric code points. IANA (Internet Assigned Numbers Authority) maintains registries: TLS named groups, TLS signature algorithms, COSE algorithm IDs, JOSE algorithm IDs, SSH key types, etc. PQUIP coordinates assignment of these code points. New PQC algorithms go through: 1. Internet draft proposing the code point with assigned number 2. Working group review and consensus 3. IANA registration 4. Implementations using the code point The TLS named groups registry has new code points for ML-KEM (512, 768, 1024) and hybrid combinations (X25519+ML-KEM-512, X25519+ML-KEM-768, etc.). These code points are how TLS clients and servers negotiate which algorithm to use. ## PQC Algorithms in the Registry As of 2026, the following algorithms are in active IETF specification: - **ML-KEM-512, ML-KEM-768, ML-KEM-1024**: NIST FIPS 203 - **ML-DSA-44, ML-DSA-65, ML-DSA-87**: NIST FIPS 204 - **SLH-DSA**: NIST FIPS 205, several parameter sets - **HQC**: pending NIST FIPS 209 publication - **LMS, XMSS**: hash-based signatures, RFCs 8554 and 8391 Composite forms (hybrid) are specified separately: - X25519+ML-KEM-512, X25519+ML-KEM-768, X25519+ML-KEM-1024 - P-256+ML-KEM-512, P-384+ML-KEM-768, P-521+ML-KEM-1024 - Ed25519+ML-DSA-44, Ed25519+ML-DSA-65 - ECDSA+ML-DSA, RSA+ML-DSA (composite signatures) ## Pace of Adoption How fast does this all happen? Realistic timeline: - 2024-2025: NIST FIPS 203, 204 published; IETF drafts mature - 2026: First TLS implementations ship hybrid PQC (BoringSSL, OpenSSL 3.x branches) - 2027: Major server software (nginx, Apache) supports hybrid - 2028-2029: Browsers ship hybrid TLS by default - 2030: PQ TLS becomes the default for new connections in most stacks - 2030-2033: CNSA 2.0 deadline for US national security; broader regulatory adoption The pace varies by protocol. TLS will move fastest because of the consumer browser pressure. IPsec and SSH have less consumer-facing pressure but enterprise mandates drive adoption. X.509 certificates are slower because PKI ecosystems are conservative. ## What This Means for QNSQY Users QNSQY today implements PQC at the file level (QSPG v2 format with ML-KEM hybrid and ML-DSA hybrid). It does not depend on protocol-level PQC because it does its own encryption. But QNSQY users still benefit from the IETF PQUIP work indirectly: - Standardized algorithm naming and parameters means QNSQY interoperates with other PQC tools - IETF guidance on hybrid combiners aligns with QNSQY's HKDF combiner - Future integrations (PQC TLS for QNSQY's API connections, PQC SSH for remote operations) will use the same underlying algorithms For organizations migrating their full stack, the IETF PQUIP work is what unlocks browser, VPN, and SSH PQC support. QNSQY can be a starting point (encrypt critical files now) while the rest of the stack catches up. ## Vendor and Library Status Major libraries and their PQC status (as of 2026): - **liboqs / Open Quantum Safe**: Comprehensive PQC implementation; reference for many integrations - **OpenSSL 3.x**: experimental ML-KEM and ML-DSA in `oqs-provider`; production support scheduled for OpenSSL 4 - **BoringSSL**: Google's TLS library, has hybrid X25519+ML-KEM-768 in production for Chrome's TLS connections to Google - **rustls**: Rust TLS library, PQC support in active development - **NSS (Network Security Services)**: Mozilla's library, hybrid PQC support in progress for Firefox - **wolfSSL**: PQC support shipping with FIPS 140-3 validation in progress Library support is a leading indicator. Once libraries ship PQC, applications can adopt it relatively easily. ## Hybrid Combiner Specification One of PQUIP's most concrete deliverables is the hybrid combiner specification. Combining a classical and a PQC shared secret into one final secret sounds simple but has subtle pitfalls. PQUIP's recommended pattern follows the IETF and ETSI consensus: ``` shared_secret = HKDF-Extract(salt=label, IKM=ss_classical || ss_pqc) key = HKDF-Expand(shared_secret, info=context, length=N) ``` The HKDF-based combiner has three properties that matter: 1. **Concatenation order matters for analysis but not security**. Both `ss_classical || ss_pqc` and `ss_pqc || ss_classical` are secure, but the spec mandates a specific order so implementations interoperate. 2. **Salt is mandatory**. A static salt or one derived from the protocol context binds the combiner to the protocol, preventing cross-protocol substitution attacks. 3. **HKDF-Extract followed by HKDF-Expand**. This is the standard HKDF pattern from RFC 5869. Section 2.2 of the RFC describes the exact bit layout. The combiner is used in TLS 1.3 hybrid groups (draft-ietf-tls-hybrid-design), in IPsec hybrid (draft-ietf-ipsecme-ikev2-pqc), and in SSH PQ kex. Having one combiner across protocols means library code, fuzz tests, and audits transfer naturally. ETSI TS 103 744 published the canonical hybrid KEX profile in 2020, and IETF PQUIP aligns with it. Where the two diverge slightly (the precise label values, for example), PQUIP defers to the IETF protocol-specific specification. ## OID and Code Point Allocation Process When a new PQ algorithm is ready to be used in protocols, IANA must allocate a numeric code point and one or more Object Identifiers (OIDs). The process: 1. **Internet draft proposes the algorithm and its identifier**. The draft includes a reference implementation and security analysis. 2. **Working group review**. The relevant working group (TLS for TLS code points, LAMPS for X.509 OIDs, etc.) reviews the draft. 3. **WG last call and IETF last call**. Open community review. 4. **IESG approval**. The IETF Engineering Steering Group approves the draft. 5. **IANA allocation**. IANA assigns the code point and updates the public registry. 6. **RFC publication**. The Internet Draft becomes an RFC. For ML-KEM and ML-DSA, the IANA registries already contain the necessary code points. For HQC (still pending FIPS 209), code points are reserved but not yet active. For on-ramp signature candidates, code points are not allocated until NIST selects winners. The OID for ML-DSA-65 (per FIPS 204) is 2.16.840.1.101.3.4.3.18. ML-KEM-768 carries 2.16.840.1.101.3.4.4.2. These OIDs appear in X.509 certificates, CMS messages, and other ASN.1-based formats. PQUIP does not assign OIDs but coordinates with NIST and LAMPS to ensure consistent identifiers across protocols. ## Composite vs Hybrid Terminology A point of confusion in the PQUIP space: "composite" and "hybrid" sometimes mean different things. **Composite signature (LAMPS terminology)**: A single signature that bundles two underlying signatures. The verifier must validate both. Encoded as a single signature with a composite OID. Used in X.509 certificates. **Hybrid signature (general terminology)**: Any combination of classical and PQ signatures. Could be composite (one OID, both signatures), parallel (two separate signatures), or sequential (one signed object containing the other). **Hybrid KEX (TLS terminology)**: A key exchange that derives a shared secret from a classical KEM and a PQ KEM. The two shared secrets are combined via an HKDF-based combiner. PQUIP works on harmonizing terminology across these contexts. The general advice for engineers reading drafts: check the specific working group's terminology before assuming. ## FAQ ### Where do I find current PQUIP drafts? The PQUIP working group page at https://datatracker.ietf.org/group/pquip/about/ lists all active drafts and recent meetings. The IETF Datatracker also has search functionality for finding specific topics. ### Are IETF drafts free to read? Yes. All IETF drafts and RFCs are free at datatracker.ietf.org. This is one of IETF's core principles. ### How does PQUIP relate to NIST? NIST publishes the algorithm specifications (FIPS 203, 204, 205, etc.). PQUIP coordinates the protocol-level integration. They are complementary: NIST tells you what the algorithm is, PQUIP tells you how to use it in protocols. Many of the same researchers contribute to both. ### Should I wait for IETF PQC standards to be finalized? Depends on use case. For long-lived data (file encryption, code signing, archival), start now with hybrid mode. The hybrid approach is robust against transition risk. For protocol-level PQC (TLS, IPsec), wait for production library support, expected through 2026 to 2028. ### Does QNSQY follow PQUIP guidance? QNSQY's design aligns with PQUIP guidance: standardized algorithm naming (ml-kem512, ml-dsa44, etc.), HKDF-based hybrid combiner, NIST FIPS-aligned parameters. The QSPG v2 file format is custom but follows PQUIP-recommended patterns. See [pricing](../../pricing.html). ### What is the difference between PQUIP and CFRG? PQUIP is a working group focused on protocol-level integration of PQC. CFRG is a research group that does cryptographic algorithm review and publishes RFCs on cryptographic constructions. CFRG analyzes the security of proposed algorithms and combiners; PQUIP applies that analysis to specific protocols. The two groups overlap in membership and frequently coordinate. CFRG publishes things like RFC 9180 (HPKE) and analyses of HKDF; PQUIP publishes things like protocol-specific PQC migration drafts. ### How are vendors expected to track PQUIP work? Most major TLS, SSH, and IPsec vendors have a representative monitoring PQUIP. Library maintainers (OpenSSL, BoringSSL, rustls, NSS) attend IETF meetings or follow the mailing list. For organizations without IETF participation, the simplest tracking method is to subscribe to the pquip@ietf.org mailing list and watch the working group page on datatracker.ietf.org for new drafts. ## Sources 1. IETF PQUIP Working Group. https://datatracker.ietf.org/group/pquip/about/ 2. draft-ietf-pquip-pqc-engineers, "Post-Quantum Cryptography for Engineers." https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/ 3. IETF Datatracker, "Active drafts in PQUIP." https://datatracker.ietf.org/wg/pquip/documents/ 4. IETF Crypto Forum Research Group (CFRG). https://datatracker.ietf.org/group/cfrg/about/ 5. IANA Algorithm Registries. https://www.iana.org/protocols 6. RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." https://datatracker.ietf.org/doc/html/rfc5869 7. ETSI TS 103 744 v1.2.1, "Quantum-Safe Hybrid Key Exchanges." https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/ 8. NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024. https://csrc.nist.gov/pubs/fips/203/final ## Related Articles - [IETF PQC internet drafts](../ietf-pqc-internet-drafts.html) - [IETF RFC 9180 HPKE](../ietf-rfc-9180-hpke.html) - [IETF RFC 9420 MLS](../ietf-rfc-9420-mls.html) - [Hybrid encryption](../hybrid-encryption.html) - [NIST PQC standards timeline](../nist-pqc-standards-timeline.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)