Post-Quantum Saturday — August 01 2026 Weekly Update

TL;DR — This Week

1. ML-DSA in TLS crosses the standards threshold. At IETF 126 (Vienna, July 20–24, 2026), the TLS WG confirmed that draft-ietf-tls-mlkem (ML-KEM key exchange for TLS 1.3) is in IESG processing — the final editorial/approval stage before RFC publication. The companion draft-ietf-tls-mldsa (ML-DSA authentication for TLS) is an active WG draft. A hybrid ML-DSA certificate standard (composite signatures, LAMPS WG) reached WG Last Call in March 2026, targeting RFC Q4 2026. Cloudflare's timeline says: first ML-DSA certificates in WebPKI by early 2027. The era of pure-PQ TLS authentication is approaching.
2. Merkle Tree Certificates (MTCs) emerge as the Web PKI answer. Let's Encrypt (June 2026) committed to MTCs as its path to post-quantum web authentication — staging late 2026, production 2027. Chrome identified MTCs as its preferred approach. The IETF PLANTS WG has the draft in WG Last Call. This sidesteps the 5–100× signature-size explosion of putting ML-DSA directly into X.509. See the new deep-dive: Merkle Tree Certificates.
3. CISA publishes PQC Product Categories (July 23, 2026). CISA released its categorization of technologies by PQC readiness: "widely available" (cloud, browsers, chat — procure PQC-only now) vs. "transitioning" (networking hardware, HSMs, IdPs, email, databases — migrating). This operationalizes EO 14412's procurement requirements and creates a de facto vendor checklist.
4. Cloudflare's "ML-DSA will have to do" manifesto. Cloudflare published a detailed argument that despite ML-DSA's downsides (2.4–4.6 KB signatures vs. 64 bytes for Ed25519), better PQ signature algorithms won't be ready in time. ML-DSA is the only game in town for the first migration. The post includes a comprehensive comparison table of all NIST signature candidates with exact sizes and performance.
5. GRI Quantum Threat Timeline 2025 published. The Global Risk Institute / evolutionQ annual expert survey puts the probability of a CRQC within 10 years at 28–49% (highest in the survey's history) and within 15 years at 51–70%. This is the survey cited in EO 14412's rationale.

Freedom-tech implication: the standards train has left the station. ML-KEM key exchange in TLS is essentially done (IESG processing). The authentication migration (ML-DSA certificates, MTCs) is the 2026–2028 frontier. Decentralized identity systems (Nostr, ENS, DIDs) should be planning their PQ signature migration now — the tooling (OpenSSL 3.5+, Go 1.27 crypto/mlkem, liboqs 0.16.0) is production-ready.

The Week in Detail

1. IETF 126 (Vienna, July 20–24, 2026) — PQC TLS Standardization Status

The IETF 126 meeting in Vienna featured multiple PQC-related sessions across TLS, LAMPS, PLANTS, and MAPRG working groups. The standardization status as of July 2026:

Key takeaway: ML-KEM in TLS 1.3 (draft-ietf-tls-mlkem) is essentially done — IESG processing is the final editorial and approval step before it becomes an RFC. This means the hybrid X25519MLKEM768 key exchange already deployed by Chrome, Cloudflare, AWS, and Apple will have a formal RFC behind it imminently. The harder problem — ML-DSA authentication — is in active WG draft stage, with RFC expected August 2026 per Cloudflare's timeline.

The composite signatures approach (draft-ietf-lamps-pq-composite-sigs, Ounsworth et al., Entrust) defines how to combine a classical signature (ECDSA P-256) with an ML-DSA signature into a single X.509 certificate. A composite ML-DSA-65 + ECDSA-P256-SHA512 signature is ~3,380 bytes. LAMPS reached WG Last Call in March 2026, targeting RFC Q4 2026. This is the standardization path for hybrid PQ/T certificates in enterprise PKI.

Sources: IETF 126 Datatracker, datatracker.ietf.org/meeting/126/; LAMPS composite sigs draft, lamps-wg.github.io/draft-composite-sigs/; TLS ML-DSA draft status, Cloudflare blog.

2. Merkle Tree Certificates — The Web PKI PQ Authentication Breakthrough

This is the most significant new development in PQ web authentication since the NIST standards were finalized. See the dedicated deep dive: Merkle Tree Certificates.

The problem: Putting ML-DSA directly into X.509 certificates creates a size explosion. An ML-DSA-65 signature is 3,309 bytes vs. ~72 bytes for ECDSA P-256. A full certificate chain (root → intermediate → leaf) with ML-DSA signatures adds ~10 KB to every TLS handshake. On constrained or high-latency links, this is problematic.

The MTC solution: Instead of signing each certificate individually, a CA batches many certificates into a Merkle tree and signs only the root. A client proves its certificate belongs to the signed tree using a short inclusion proof (logarithmic in batch size). This dramatically reduces the per-certificate signature overhead while maintaining post-quantum security (the root signature uses ML-DSA, but there's only one per batch of thousands).

Milestones: - Let's Encrypt (June 3, 2026): Committed to MTCs as its PQ Web PKI path. Staging late 2026, production 2027. Free, automated, available via ACME — no change to the user experience. - Chrome identified MTCs as its preferred approach for PQ certificates on the public web. - Cloudflare and Chrome are testing MTCs on live internet traffic. - IETF PLANTS WG has draft-ietf-plants-merkle-tree-certs in WG Last Call.

Enterprise concern (raised at IETF 126 MAPRG): Can relying parties still access Subject DN, SAN, EKU, Certificate Policies, Name Constraints, and enterprise-specific extensions? What happens with CDNs and proxies when browsers do MTC but enterprise servers use plain certs? These are open questions the PLANTS WG must resolve.

Relevance to ungovernable systems: MTCs represent a fundamental rethink of how web authentication works — moving from individual signatures to batch-verified inclusion proofs. This is architecturally aligned with decentralized identity thinking: a Merkle root is a compact commitment to a set of identities, verifiable without trusting each individual assertion. The technology could apply beyond Web PKI to any system that needs to prove membership in a trusted set (Nostr relay allow-lists, ENS subdomain batches, mesh network node registries).

3. CISA PQC Product Categories (July 23, 2026)

CISA published its Product Categories for Technologies That Use Post-Quantum Cryptography Standards on July 23, 2026 — the operational companion to Executive Order 14412. This is the document vendors and procurement officers will use to determine what "PQC-ready" means for different product classes.

The implication: CISA classifies cloud platforms, browsers, and messaging as categories where PQC is "widely available" — meaning federal procurement should demand PQC-only products now. Networking hardware, HSMs, and email are "transitioning" — PQC support exists but isn't ubiquitous. This creates direct vendor pressure: if you sell to the US government (directly or through the supply chain), your product category determines your PQC timeline.

Freedom-tech relevance: Decentralized messaging (Nostr, Signal, SimpleX) and cloud-adjacent services are in the "widely available" category. Mesh networking hardware falls under "transitioning." Open-source projects that want government-adjacent adoption should track these categories.

4. Cloudflare: "ML-DSA Will Have to Do" (July 2026)

Cloudflare published a detailed analysis by Bas Westerbaan and Christopher Patton arguing that despite ML-DSA's downsides, the first PQ migration must use it — better algorithms won't be ready in time.

The argument: - ML-DSA-44 signature: 2,420 bytes (vs. 64 bytes for Ed25519 — 38× larger) - ML-DSA-65 signature: 3,309 bytes - ML-DSA-87 signature: 4,627 bytes - SLH-DSA-128s: 7,856 bytes (123× Ed25519); SLH-DSA-128f: 17,088 bytes

Why alternatives aren't ready: - FN-DSA (Falcon): 666-byte signatures, but hard to implement side-channel secure; FIPS 206 still in IPD. - SQIsign: 148-byte signatures (beats RSA-2048!), but extremely slow signing and complex; Round 3 candidate, years from standardization. - UOV: 96-byte signatures, but 66 KB public keys; niche use only. - HAWK: 555-byte signatures, promising, but Round 3 candidate. - MAYO, SNOVA, FAEST, SDitH, MQOM: All Round 3 candidates; none production-ready.

Cloudflare's ML-DSA deployment timeline:

The core thesis: "ML-DSA is available today, and it will have to do for the first migration." Waiting for better signature schemes (SQIsign, HAWK, etc.) means ceding years of harvest-now-decrypt-later exposure. The pragmatic path is: deploy ML-DSA now, plan for algorithm agility, and migrate to better schemes when they're standardized (~2028–2030).

5. Global Risk Institute Quantum Threat Timeline 2025

The seventh annual Quantum Threat Timeline Report (GRI / evolutionQ, published April 2026, survey dated March 9, 2026) surveyed 26 international experts. Key findings:

• CRQC within 10 years: 28–49% probability (highest in the survey's history, up from prior years)
• CRQC within 15 years: 51–70% probability
• CRQC within 5 years: low but non-negligible

Google’s 25 March 2026 announcement sets a 2029 migration target; it does not date Q-Day or cite this survey. The report's authors are Dr. Michele Mosca (evolutionQ CEO, University of Waterloo) and Dr. Marco Piani.

Context: The 28–49% range reflects genuine expert uncertainty — the lower bound assumes significant engineering obstacles remain; the upper bound assumes current progress rates continue. Either way, the probability is high enough that the "harvest now, decrypt later" threat is operationally real for any data with a secrecy horizon beyond ~2030.

6. Policy Timeline: EO 14412 Milestones Hitting Now

Executive Order 14412 (June 22, 2026) sets in motion a cascade of deadlines. The July 2026 milestone has already passed — each federal agency head was required to identify a PQC migration lead and report their name to OMB and the National Cyber Director.

The September 2026 OMB guidance is the next critical milestone — it will define what "transition" means, potentially requiring that quantum-vulnerable algorithms be fully disabled (not just that PQ is "supported"). Cloudflare specifically warned about the downgrade attack risk: a system that supports ML-KEM but still allows classical-only TLS is vulnerable if an attacker can force a downgrade.

The FIPS 140-2 sunset (September 21, 2026) is a separate but related pressure point. After this date, only FIPS 140-3 validated modules may be used for new federal procurement. Since PQ algorithm implementations must be FIPS 140-3 validated for federal use, this constrains the migration timeline: vendors without FIPS 140-3 modules are locked out.

7. G7 Cyber Expert Group PQC Coordination (January 2026)

On January 13, 2026, the G7 Cyber Expert Group issued a statement on advancing a coordinated roadmap for the transition to post-quantum cryptography. This establishes PQC migration as a coordinated multilateral priority among G7 nations, complementing:

• US: EO 14412 (2030 key establishment / 2031 signatures)
• EU: Coordinated PQC Transition Roadmap (critical infrastructure by end 2030)
• France (ANSSI): Certification mandate from 2027; quantum-safe products only by 2030
• Canada: Federal PQC roadmap — every department must have a migration plan by April 2026, high-priority transitions by end 2031
• Germany (BSI): Full migration by 2030; hybrid deployment during transition
• UK (NCSC): "Start planning now" for long-lived data protection systems

8. Implementation Ecosystem Update

• Go 1.27: Adds ML-DSA to the standard library (crypto/mldsa), following Go 1.24's crypto/mlkem. This is significant — Go's standard library is the backbone of cloud-native infrastructure (Kubernetes, Terraform, Docker, Consul). ML-DSA in stdlib means Go-based systems can generate and verify PQ signatures without external dependencies.
• liboqs 0.16.0 (July 9, 2026): Remains the canonical C reference library. Full FIPS-aligned ML-KEM, ML-DSA, SLH-DSA. SPHINCS+ (the pre-standardization name) removed in favor of SLH-DSA (FIPS 205). No new release since July 9; ecosystem bindings (oqs-provider for OpenSSL, Rust/Go/Python) continue maturing.
• OpenSSL 3.5+ / 4.0: Native ML-KEM, ML-DSA, SLH-DSA support. OpenSSL 4.0.0 (April 14, 2026) added FIPS 140-3 module and curveSM2MLKEM768 hybrid. The reference platform for self-hosted PQ infrastructure.
• pyca/cryptography: Tracking PQC support (issue #14690, April 2026). OpenSSL 3.5 shipped PQ support in March 2026; pyca is working on exposing it through the Python API.

9. Signature Placement in PQ TLS (ePrint 2026/666)

José Luis Delgado's paper Signature Placement in Post-Quantum TLS Certificate Hierarchies (ePrint 2026/666, April 2026, revised May 2026) provides the first systematic experimental study of where to place ML-DSA and SLH-DSA signatures in a TLS 1.3 certificate chain.

Key finding: Signature placement in the hierarchy (root vs. intermediate vs. leaf) dramatically affects handshake size and latency. A leaf-only ML-DSA deployment (classical root/intermediate, PQ leaf) minimizes disruption but leaves the chain partially quantum-vulnerable. A full-chain PQ deployment (ML-DSA at all levels) adds ~10 KB to the handshake. The paper provides concrete measurements for deployment planning.

10. Research Community: Upcoming Conferences (August 2026)

• Workshop on Algebraic Methods in Post-Quantum Cryptography (AM-PQC 2026): Ohrid, Macedonia, August 10–14, 2026. Focus on algebraic structure in lattice-based and code-based cryptosystems — directly relevant to the security of ML-KEM and ML-DSA.
• Crypto 2026: Santa Barbara, August 15–19, 2026. The flagship IACR cryptology conference. Expect new cryptanalysis results that could affect PQ parameter choices.
• Mathematics of Post-Quantum Cryptography: Raitenhaslach, Germany, September 7–11, 2026.

These conferences are where the next wave of lattice cryptanalysis results will surface — potentially tightening or loosening the security estimates for ML-KEM and ML-DSA parameters.

Evidence at a Glance

PQ Signature Size Reference (from Cloudflare's July 2026 Analysis)

Primary sources

• Google’s 2029 PQC migration target