Post-Quantum Saturday — September 12 2026 Weekly Update

Weekly companion to Overview - Post-Quantum Cryptography, PQC Deployment and Libraries Tracker, The Dihedral Coset Attack Line, algorithm notes (ML-KEM, ML-DSA, SLH-DSA, HQC, FN-DSA Falcon), Merkle Tree Certificates, Hybrid KEM Migration, and Bitcoin PQ Migration. This note covers the week since the September 5 update — the September 5–11 window, with the IETF turning the page on the most procedurally stuck authentication document of the year.

TL;DR — This Week

2. The ML-DSA appeal record is now complete and on the page. The seven Bernstein filings touching the TLS WG chairs, the SEC ADs, the IESG, and the IAB are now publicly archived and dated, ending with the 2026-07-08 complaint regarding IESG removing an appeal process (IESG follow-up 2026-07-09) — which is the artifact that triggered the freeze we just exited. The IESG's 2026-05-30 response to the original 2026-05-19 appeal declined to terminate the IETF Last Call and gated further processing on resolution of the SEC-AD complaint; with that gating condition satisfied by the July 19 ML-KEM consensus determination's frame and the 2026-09-02 ML-KEM-10 IESG approval precedent, the ML-DSA document was free to advance once editor-side queue work was complete.

3. Composite ML-DSA (draft-ietf-lamps-pq-composite-sigs-19) is now 49 days in the RFC Editor queue (since the Sep 5 note: IANA review state Version Changed - Review Needed, IANA action RFC-Ed-Ack, expert reviews OK, RFC Editor status In Progress (First Edit), last touched 2026-08-26). This is the longest any PQ-PKI document has sat in the queue without publication; RFC 9980 (OpenPGP PQC, hybrid-only) shipped in 11 days from queue to publication, RFC 9935 (ML-KEM algorithm identifiers) in 22 days. The drag is the IANA version-changed review back-cycle; nothing in the document is in public dispute. Private/enterprise PKI planning around ECDSA+ML-DSA composite X.509 should treat this document as imminent but assume a further 2–6 weeks before publication.

4. FN-DSA / FIPS 206 IPD landed in the public review period in the closing days of August. The draft has been under initial public comment since NIST submitted it on 2025-08-28; the public comment window, on the timeline published for the prior three standards, would close roughly mid-to-late September. DigiCert's 2026-07-15 note projects final FIPS 206 late 2026 / early 2027; nothing in this week's inputs contradicts that. Adjacent: the IETF draft-ietf-jose-pqc-kem-06 (Tschofenig/Reddy/Banerjee, last updated 2026-07-06, no shepherd, no responsible AD) still cites FIPS 206 as the upstream.

5. The federal procurement deadline clock: 110 days. January 1, 2027 — every new National Security System acquisition must be CNSA 2.0-compliant by default. The full enforcement milestone (CNSA 2.0 required, not merely "supported") is December 31, 2031, with the legacy phase-out window 2030–2031 and full NSS PQ compliance 2035. OMB M-26-15's signature-migration 2031 phase aligns with the CNSA enforcement date. Federal civilian agencies' PQC Migration Plans are due to OMB+ONCD October 22, 2026 (per the Sept 5 note); GSA's 2026 PQC Summit is tomorrow, September 16, 2026 (hybrid, .gov/.mil only, 20 F Street + Zoom for Government). The Ethernet of PQC compliance is now on the procurement calendar, not the research calendar.

6. New paper trail on the lattice-primitive side (mostly upstream of ML-KEM but on the same rings). ePrint 2026/1915 (Joux, Kubitza, List, Tue, Sep 8) — Externalizing the Decryption Oracle: Attacking ML-KEM with Side Channels Beyond s, e, 𝛽 — investigates side-channel attacks against ML-KEM targeting ciphertext components beyond the canonical (s, e, β) set. ePrint 2026/1922 (Hoque, Liu, Rahman, Saha, Sep 9) — Single-Trace Side-Channel Attack on CRYSTALS-Kyber Decapsulation Targeted to the m = 0 Case — reconstructs the secret key from a single power trace on a particular Kyber implementation under a degenerate-input condition. Both are implementation-research papers that do not move ML-KEM parameters and are aimed at hardening rather than breaking; their pattern (re-using the same rings, narrowing to specific implementation profiles) is exactly the one the Dihedral Coset story showed does not break lattice cryptography, but does meaningfully tighten the engineering bar for safe deployment. Cross-reference Hybrid KEM Migration and PQC Deployment and Libraries Tracker.

7. Library state-of-play: steady, not silent. liboqs main has continued to absorb mlkem-native and mldsa-native v2.0.0 backends since Sep 3; current tagged release remains 0.16.0 (2026-07-09, 3,054 stars). mldsa-native is at v2.0.0 (the formal release from 2026-08-07 with C90, AArch64 Neon + x86_64 AVX2 backends, memory- and type-safety proofs); the C90 split-frontend/backend design (per the PQCA mentorship writeup) matches the mlkem-native model. Trail of Bits' ptp-mldsa-native fork continues the high-assurance line. No fresh oqs-provider release this week; the AWS-LC merge of mlkem-native and mldsa-native v2 is queued, not shipped.

8. Two more PQC-relevant OpenSSL CVEs shipped September 9 in 4.0.3 / 3.6.5 / 3.5.9. Moderate severity. The five-week cadence of PQ-capable-branch security releases (August 25 → September 9) makes the case for keeping upgrade automation tight on anything running an OQS provider on top of OpenSSL 3.5+. None of the September 9 CVEs is PQ-algorithm-specific.

9. The Bernstein objection archive is now a fixed historical record. The seven Bernstein filings between 2025-10-15 and 2026-07-09 (artifact numbers 217, 230, [232], 312, 314, 316) cover the TLS WG chairs' consensus calls, the SEC ADs' refusal-to-process decisions, the moderation appeal under RFC 9945 §4.1, the IETF contribution-format question, and the IESG removal of an appeal process. Three were denied (the WG-chairs-consensus appeals 217, 230, and 314); two were resolved by the IESG recording the procedural objection and declining the substantive remedy (232, 313); one (the "removing an appeal process" complaint, 316) was acknowledged 2026-07-09 with IESG follow-up. The next-and-final IAB-tier appeal was filed 2024-12-15 and answered 2025-01-09. No IAB-tier appeal on the 2026 documents. What survives of the procedure: an off-list sustained objection series on the registry column Recommended=N (unresolved at the substance level), and an off-list sustained objection series on the independent publication of pure ML-KEM and ML-DSA (unresolved at the substance level). What ended: every procedural step that the IESG deemed required.

10. IETF-124 / 2026 meeting calendar context (for the record). IETF-124 (Singapore, March 2025) was the meeting at which the TLS WG formally adopted the pure-ML-KEM and pure-ML-DSA drafts. IETF-125 (Vancouver, March 2026) confirmed those drafts on the WG agenda with tls-mldsa-01; the ML-KEM Last Call followed. IETF-126 (Yokohama, July 2026) was the meeting at which the document state in the datatracker read "Approved-announcement sent" for both drafts in close succession (July 8 for mldsa-05; September 2-3 for mlkem-09/10). IETF-127 is November 14–20, 2026, San Francisco. Both pure drafts will likely be RFCs by then.

Freedom-tech implication: the transport-PQC story is now substantively done at the IETF level — hybrid in production, pure as an Informational cite. The authentication-PQC story has one public IETF document left to publish (ML-DSA-in-TLS) and two queued (composite ML-DSA in the queue, FN-DSA in pre-final). The action item list for a TLS-using operator in late 2026 is now a procurement-compliance list, not a research-watch list: verify your OpenSSL provider path against liboqs ≥ 0.16.0 + oqs-provider current; verify your CA issuance pipeline against an ML-DSA-65 leaf; verify your code-signing path against SLH-DSA or composite ML-DSA; verify your HSM's FIPS 140-3 module supports ML-KEM, ML-DSA, and SLH-DSA in the IKE/TLS code paths you'll actually exercise. The next twelve weeks are dominated by the GSA PQC Summit (Sep 16), the OMB M-26-15 Migration Plan deadline (Oct 22), the Ethereum 2nd Annual PQ Research Retreat (Oct 9–12 Cambridge), the FN-DSA public-comment close (projected mid-to-late September), and the IETF-127 meeting (Nov 14–20).

The Week in Detail

1. ML-DSA in TLS — the 65-day freeze ends

The full sequence of relevant events:

The new draft's content (per the html rendered by tlswg/tls-mldsa) is unchanged from -05 on the substantive section 5 IANA considerations — the RECOMMENDED=N language, the RFC 9847-quoted rationale for the registry column value, the Security Considerations section expanded by David Benjamin in mid-June, the Robert Lyashevskyi acknowledgment removal, the rfc8446bis-references-to-rfc9846 substitution — all already in -05. The IANA review state reverted to Version Changed - Review Needed with the new submission, which is the expected back-cycle: when a document is modified after IANA has acted on it, IANA's review state resets to confirm no new IANA actions are needed for the new version. The substantive procedure has moved the document past the appeal hold; the IANA review and RFC Editor formatting queue are mechanical, not procedural.

What changed in the world since September 5: nothing substantive about the document. The IESG chose to advance the document. The default Cloudflare timeline prediction ("August 2026") was already missed at the September 5 update. The current realistic publication window is October; IETF-127 (November 14–20, San Francisco) is the last IETF meeting where a freshly-published ML-DSA-in-TLS RFC could meaningfully be presented to the WG without being a fait accompli.

What this means for an operator planning PQ-authenticated TLS work: the wire-level guidance is unchanged — deploy hybrid (Ed25519 + ML-DSA-65) for compatibility and rollback safety — but the citeable RFCs list now has a publishable imminent item for ML-DSA-in-TLS, joining RFC 10024 (hybrid ML-KEM) and RFC 9881 (ML-DSA algorithm identifiers). Cloudflare's roadmap has been validated end-to-end: hybrid in TLS KEX is RFC 10024, ML-DSA in CMS/X.509 is RFC 9881, ML-DSA in TLS authentication is imminent. The CNSA 2.0 / FIPS 204 compliance picture for a TLS-speaking stack is therefore about to be substantially citeable, not just operationally-possible.

2. Pure ML-KEM — the seven-day quiet after the September 3 approval

There is no public procedural dispute on this document. The September 5 note's covered points (Informational status, Recommended=N registry entries, the unresolved procedural complaint that the chairs did not publish rough-consensus weighting numbers) remain as the historical context, but no new filing appeared this week.

3. Composite ML-DSA — still queue-resident, still no substantive dispute

draft-ietf-lamps-pq-composite-sigs-19 (datatracker) shows IESG state RFC Ed Queue, IANA review state Version Changed - Review Needed, IANA action state RFC-Ed-Ack, expert reviews OK, RFC Editor status In Progress (First Edit), last touched 2026-08-26. 49 days in the queue.

What the September 5 update called "near-term" is now 49 days. The RFC Editor queue page is not informative on the reason; the IANA review state having reverted to Version Changed is the most likely explanation — when a new revision lands (the -19 was uploaded 2026-04-21 but the datatracker reflects later bookkeeping), IANA has to confirm no new IANA actions are needed for the new version. There is no public dispute on this document. The September 12 estimate for the September 5 note's "imminent but assume 2–6 weeks further" was on the lower end; with no movement since, that projection should be widened to 4–10 weeks.

For enterprise PKI planning around ECDSA+ML-DSA composite X.509, the planning guidance is proceed as if imminent, but do not yet cite the RFC number. The RFC Editor queue contains many security-area documents at any time; priority is not strictly FIFO.

4. FN-DSA / FIPS 206 — public-comment close projected mid-to-late September

NIST submitted the FIPS 206 (FN-DSA, Falcon) draft for internal approval on 2025-08-28. The Initial Public Draft (IPD) entered public review shortly thereafter. The published timeline, per the encryption-consulting writeup and the Wikipedia summary cited this week, projects final standard late 2026 / early 2027. There is no fresh public document from NIST in the September 5–11 window in this week's inputs.

The IETF draft-ietf-jose-pqc-kem-06 (Tschofenig/Reddy/Banerjee, JOSE WG, WG Document state, no shepherd, no responsible AD) last updated 2026-07-06 continues to cite FIPS 206 as the upstream standard. The companion draft for FN-DSA in JOSE/COSE (the draft-reddy-jose-pqc-sig line, also cited) has the same upstream dependency.

For a deployment planning around FN-DSA, the operative position this week is unchanged: wait for the final FIPS 206, do not write integration code against IPD text.

5. The federal compliance clock

The CNSA 2.0 timeline (NSA, September 7, 2022):

• Now–2025: Preparation and early adoption
• 2025: Vendors expected to support and prefer CNSA 2.0 algorithms in new software/firmware
• January 1, 2027: All new NSS acquisitions must be CNSA 2.0-compliant by default
• December 31, 2030: Non-compliant systems must be phased out
• December 31, 2031: Full enforcement (all NSS cryptographic implementations exclusively CNSA 2.0)
• 2035: Full quantum resistance across NSS

The federal civilian side adds:

• September 16, 2026 (tomorrow): GSA 2026 PQC Summit (hybrid; .gov/.mil only)
• September 21, 2026: FIPS 140-2 moves to Historical; only FIPS 140-3 validations qualify for new federal procurement
• October 22, 2026: OMB M-26-15 Migration Plan submission deadline
• 2031 (federal signature migration, per M-26-15): aligns with CNSA 2.0 full enforcement

The alignment of dates is striking: M-26-15's signature-migration 2031 phase, the CNSA 2.0 full enforcement 2031, the CNSA 2.0 non-compliant phase-out 2030–2031, and the IR 8547 disallowance of RSA/ECC after 2035. The federal procurement calendar is therefore: mandatory support starts Jan 1 2027; exclusive use enforced Dec 31 2031; classical public-key disallowed 2035. Anything shipped for federal use in the September 5–11 window is being timed against the procurement-window right now, not against the research deadline. Cross-reference Merkle Tree Certificates (which is the public-web analog of the enterprise M-26-15 mandate), Hybrid KEM Migration.

6. The lattice-primitive cryptanalysis update

Two papers this week worth flagging, both upstream-of-ML-KEM rather than breaking-it:

• ePrint 2026/1915 — "Externalizing the Decryption Oracle: Attacking ML-KEM with Side Channels Beyond s, e, β" (Joux, Kubitza, List, Tue, Sep 8). The paper investigates side-channel attacks on ML-KEM decapsulation against ciphertext components beyond the canonical (s, e, β) triple, expanding the attack surface under implementation-specific information leak. The relevant operational implication: deployments that have leaned on the (s, e, β)-only threat model for side-channel resistance should re-audit. This is implementation-research paper, not parameter-changing math.
• ePrint 2026/1922 — "Single-Trace Side-Channel Attack on CRYSTALS-Kyber Decapsulation Targeted to the m = 0 Case" (Hoque, Liu, Rahman, Saha, Sep 9). Single-power-trace key recovery against a particular Kyber implementation under the degenerate input condition m = 0. Real-world impact: constrained to implementations that admit this input, but in environments where an attacker can force the m = 0 case (e.g., a controlled message-replay attack on a malleable protocol surface), the attack is single-trace. Defenses: input validation that rejects m = 0, randomized encoding that rules out the degenerate case.

Both papers reinforce a trend the The Dihedral Coset Attack Line observed: algebraic structure of the rings (Z_q[x]/(x^N+1)) is being exploited at the implementation layer faster than at the parameter layer, and the engineering bar for "this ML-KEM is hardened" is rising every quarter. Cross-reference Hybrid KEM Migration §3 (side-channel hardening matrix) and PQC Deployment and Libraries Tracker §4 (implementation-maturity tier list).

7. Library state-of-play

• liboqs: tagged release 0.16.0 (2026-07-09), main branch has carried mlkem-native v2.0.0 and mldsa-native v2.0.0 backends since Sep 3. No new tag this week; no new release-candidate this week. NVIDIA cuPQC integration work landed in #2044 (per the 0.13.0-rc1 release notes cached); this is the GPU-accelerated ML-KEM backend. Worth tracking for any high-throughput server-side PQC deployment.
• mlkem-native: v1.3 LTS gets bugfixes only through Feb 2027; v2.0.0 is current. AWS-LC merge queued.
• mldsa-native: v2.0.0 (Aug 7, 2026) is the first stable release, C90, AArch64 Neon + x86_64 AVX2, SLOTHY-super-optimizer-generated backends, memory- and type-safety proofs. Trail of Bits' ptp-mldsa-native fork continues the high-assurance line. AWS-LC merge queued.
• oqs-provider: no new release this week; 0.10.0 / 0.11.0 / 0.12.0 series stable; current tag in sync with liboqs 0.16.0.
• OpenSSL: 3.5.9 / 3.6.5 / 4.0.3 security releases shipped September 9, 2026. Moderate severity. No PQ-algorithm-specific CVEs.

8. The eight Bernstein filings — complete record

For the historical record, the eight Bernstein filings between 2024-12 and 2026-07 are now publicly archived and dated. Counting only the IETF/IESG/IAB-track filings (excluding the MODPOD-list and BCP 78 issues, which were tangential):

The pattern: every filing produced a public IESG response. None produced a substantive reversal on the underlying TLS WG decisions. The IESG's responses consistently distinguished between (a) procedural objections the IESG was willing to record, and (b) substantive objections the IESG deemed already addressed by the WG process. The ML-DSA hold from 2026-07-08 was the procedural consequence of this entire sequence; the 2026-09-11 lift of the hold is the procedural end of it. What remains after September 11: the off-list sustained objection series on the registry column Recommended=N and on the independent publication of pure ML-KEM and ML-DSA, both of which remain on the public record but unadopted by the IESG.

Evidence at a glance

Primary sources

• IETF datatracker — draft-ietf-tls-mldsa, draft-ietf-tls-mlkem, draft-ietf-lamps-pq-composite-sigs, draft-ietf-plants-merkle-tree-certs
• IESG Appeals — artifact 316 (the filing that triggered the ML-DSA hold), artifact 273 (the IESG response declining to terminate the IETF LC), appeals index
• ePrint — 2026/1915 (ML-KEM side channels beyond s,e,β), 2026/1922 (single-trace Kyber m=0)
• NSA CNSA 2.0; OMB M-26-15; GSA 2026 PQC Summit
• liboqs, mlkem-native, mldsa-native, ptp-mldsa-native, oqs-provider, PQCA mentorship writeup
• OpenSSL 4.0.3 / 3.6.5 / 3.5.9 release notes
• RFC 10024 (hybrid TLS PQ/T), RFC 9881 (ML-DSA algs in X.509), RFC 9980 (OpenPGP PQC), RFC 9935 (ML-KEM algs in X.509)
• NIST CSRC PQC project; NIST IR 8547 (transition timeline)
• Cloudflare: Why we cannot wait for better post-quantum signature algorithms