Post-Quantum Saturday — September 26 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 19 update — the September 19–25 window, dominated by a coordinated RFC Editor hold on both pure PQ-TLS documents (draft-ietf-tls-mlkem AND draft-ietf-tls-mldsa), the Sept 25 freenode.net synthesis of the reactivated McEliece parameter debate on pqc-forum, two consequential cryptanalytic ePrints (2026/2137 single-trace ML-KEM key-recovery; 2026/2131 nearly-SNFS-time 1024-bit RSA forgery), and the OpenSSL 4.1.0-beta1 / AWS-LC v5.10.0 / liboqs XMSS-CVE patch triple that closed the September deployment line.

TL;DR — This Week

1. Both pure PQ-TLS documents were re-blocked under appeal on the same day, by the same AD. On 2026-09-24, draft-ietf-tls-mlkem (pure ML-KEM) and draft-ietf-tls-mldsa (pure ML-DSA) each had RFC Editor state transitioned from "In Progress" back to "Blocked" with the canonical comment from Deb Cooley: "The wg chairs and AD have received complaint/appeals on the processing of this document. While the complaints/appeals are being reviewed, the document is being held ..." This re-holds a document (mlkem) that had been in "Approved-announcement sent" since 2026-09-03, and re-holds mldsa (cleared from a 65-day appeal on 2026-09-11). The Sept 19 note's optimism about mlkem clearing the IANA gate was premature. Coordinated holds on both pure PQ-TLS rails are now the active constraint; hybrid X25519MLKEM768 (RFC 10024) remains the operationally-accepted path. Cross-reference Hybrid KEM Migration.

2. The Kubota appeal — formally declined, but the IETF process continues to surface it. A Sept 25 freenode.net report (IETF rejects appeal on ML-KEM TLS consensus and NSA conflict claims) describes Ken Kubota's escalation: TLS chairs (Salowey, Turner) and Security AD Cooley each declined to process his appeal "in its current form," citing multiple IETF Guidelines for Conduct violations. The chairs had earlier refused to release detailed tallies behind the "roughly seven in ten" rough-consensus figure. Andrew Lee separately asked the ADs to specify which conduct rules were broken, citing public concern about bias on a standard that "will shape encryption for billions of users." The substantive claim — that the rough-consensus weighting was opaque — remains unaddressed; only the procedural form of the complaint was rejected. The Sept 24 datatracker holds are the IETF's institutional response: pause publication while the dispute continues.

3. draft-ietf-tls-mlkem-11 was uploaded 2026-09-16, three days before the prior week's analysis was written. The new -11 sits behind the held -10; the editor is not publishing -10 while -11 is in author-input-required state. The IESG approval on -10 (Sept 3) remains the IESG position — only the RFC Editor queue is held. The mlkem-10 → mlkem-11 step likely carries editorial fixes per the Sept 17 IANA Review state change (Version Changed → IANA OK - Actions Needed). The IANA registry step is procedurally complete on -11; only the RFC Editor queue position is gated by the appeal.

4. draft-ietf-lamps-pq-composite-sigs made its first forward motion in 63 days on 2026-09-23. RFC Editor state changed from "In Progress (First Edit)" to "Awaiting Second editor" — the document has cleared first-edit and is waiting for the RFC Production Center's second-editor assignment. The IANA Action state remains RFC-Ed-Ack (last changed earlier). Composite ML-DSA in X.509 PKI is now ~63 days in queue (started 2026-07-23), with first substantive forward motion this week. The Sept 19 estimate of "4–10 weeks further" should be revised: still likely 2–6 weeks given the second-editor ramp.

5. draft-ietf-plants-merkle-tree-certs-06 uploaded 2026-09-21 by David Benjamin. This is the first movement on the PLANTS MTC document since the June revision (the Sept 5 note had reported the document as static). The -06 carries MTC inclusion-proof / tree-construction corrections. Combined with the Sept 23 composite-sigs forward motion, the authentication-side PQ-Web-PKI rail showed its first collective forward motion in September — both authentication standards that have been static through August and early September moved in the same 48-hour window. Cross-reference Merkle Tree Certificates.

6. ePrint 2026/2137 (Sept 21, Jahandideh, Radboud) — single-trace key-recovery from ML-KEM key generation. The paper "Too Small to Hide" demonstrates that CBD (centered binomial distribution) samples in ML-KEM key generation are vulnerable to single-trace side-channel attack because each coefficient's value can take only ~k=2 (for ML-KEM-512/768) or ~k=3 (for ML-KEM-1024) possibilities — a small domain is a small signal-to-noise ratio problem. The fix is q-randomization: store each coefficient as v + r·q with random nonzero r, driving the side-channel leakage to the noise floor. The countermeasure raises block size from 129 back to 611 (~4 bits of security lost instead of >140), with 937 bytes of extra firmware. Important boundary: ML-KEM as standardized and as deployed in current FIPS 203 implementations does not have this countermeasure in scope; the paper provides the countermeasure and recommends adoption. Not a primitive break — an implementation hardening result. Cross-reference ML-KEM §implementation-hardening.

7. ePrint 2026/2131 (Sept 20, Shea/Haller/Suhl/Heninger/Thomé) — 1024-bit RSA forgery in "nearly SNFS time." The paper shows that with a signing oracle, the concrete security of RSA-1024 through RSA-4096 is 15–30 bits lower than factoring-based estimates suggest, because the SNFS (special number field sieve) applies to the signing-key structure in a way factoring estimates don't capture. Even RSA-4096 does not appear to meet a 128-bit security level in this attack model. The authors frame this as "classical cryptanalytic evidence in favor of moving away from RSA entirely during the current post-quantum transition." Important boundary: this is a with-signing-oracle attack (the worst-case adversary model); offline forging without oracle access is not implied. But the result does affect any system where RSA is used in a way the adversary can induce signing operations.

8. draft-ietf-jose-pq-composite-sigs-04 (Sept 11, Prabel/Sun/Gray/Reddy) is now ~14 days in queue. Still in WG Document state (JOSE WG, no shepherd, no responsible AD). Companion: draft-ietf-jose-pqc-kem-06 (Tschofenig/Reddy/Banerjee, JOSE WG, last updated 2026-07-06) cites FIPS 206 / FN-DSA as upstream — unchanged. JOSE composite line remains the active frontier for JWS/JWE PQ migration but is procedurally slow.

9. The September 25 freenode synthesis ("PQC timelines under pressure after HAWK collapse and McEliece parameter shocks") does not break ML-KEM or ML-DSA but re-opens a confidence-interval question. The article is a synthesis of pqc-forum discussion across two earlier cryptanalytic events: (a) HAWK's withdrawal from NIST Round 3 on July 29, 2026, after Steve Weis (Anthropic) showed an AI-assisted attack reducing HAWK-n key-recovery to SVP in dimension n/2+1, cutting HAWK-512 from 2^150 to 2^108 and HAWK-1024 from 2^288 to 2^182; HAWK-256 was broken end-to-end in a few hours on one server. (b) Ghoshal/Ishai/Jain/Sun's ePrint 2026/1630 (Aug 10) on quasipolynomial cryptanalysis of Classic McEliece. The Sept 25 article is significant not because the events are new but because Demi Marie Obenour, Christopher Peikert, D.J. Bernstein, John Mattsson, and Bas Westerbaan all engaged in the pqc-forum thread, with the latter three offering concrete deployment recommendations: Westerbaan (adoption graphs); Mattsson (ML-KEM + HQC hybrid for diversification); Bernstein (challenged naive bit-operation tallies as memory-routing bound, not gate bound). The operational upshot for freedom-tech: ML-KEM + HQC hybrid is now the most explicitly-named diversification strategy on the standards track; FrodoKEM is explicitly not the conservative default given thinner scrutiny; MIKE (isogeny-based, research-grade) can be fielded where both endpoints are operator-controlled.

10. The library / deployment triple closes the September line: liboqs main shipped AES-192 support (commit b196b57, Sept 24) and two XMSS correctness/security fixes (#2577 Sept 21 fixed code-scan issues; #2511 Sept 21 fixed an out-of-bounds access in xmss_core_sign on secret-key OID mismatch). AWS-LC v5.10.0 (Sept 23) — the fifth AWS-LC release of September — landed OpenSSL-compatible rehash, hardened input-validation across multiple code paths, and the OpenSSL ca-command failure-mode fix (#3568). OpenSSL 4.1.0-beta1 (Sept 23) — the first beta of the 4.1 line — was published three weeks after 4.1.0-alpha1 (Sept 9). oqs-provider commit 36cafae0 (Sept 19) updated MAYO, MQOM, and SNOVA to NIST Round 3 variants. No fresh liboqs-tagged release in this window (current tag remains 0.16.0 / 2026-07-09). Cross-reference PQC Deployment and Libraries Tracker.

11. OpenSSL cadence: The PQ-capable-branch 4.0.x / 3.6.x / 3.5.x September-9 release line (4.0.3 / 3.6.5 / 3.5.9) was followed by no further PQ-capable security advisory in the September 19–25 window. The 4.1.0-beta1 is a feature-line release, not a security advisory. The 5-week cadence estimate from Sept 5 has now stretched to 16 days. Operators maintaining PQ-enabled OpenSSL should keep upgrade automation tight.

12. CNSA 2.0 / federal procurement clock — 97 days to first enforcement. CNSA 2.0 first enforcement (Jan 1, 2027) is now 97 days out (Saturday Sept 26). The September 16 GSA PQC Summit is now 10 days historical. The OMB M-26-15 Migration Plan deadline is 26 days out (Oct 22). The IETF-127 San Francisco meeting is 49 days out (Nov 14–20). The Ethereum Foundation 2nd Annual PQ Research Retreat (Cambridge UK) is 13 days out (Oct 9–12).

Freedom-tech implication: the appeal-driven re-hold of both pure PQ-TLS standards is the substantive delta this week. The IETF's institutional response to the Kubota complaint — pause publication while the dispute continues — is procedurally defensible but creates a six-month-plus window where hybrid (RFC 10024) remains the only path that can be deployed without standards-track ambiguity. For freedom-tech: hybrid everywhere is now the only TLS-authentication posture that survives the institutional dispute; the pure-ML-KEM and pure-ML-DSA documents are held, the hybrid is published, the composite documents are queued, the JOSE documents are in WG. The ML-KEM / ML-DSA primitives are unaffected at every parameter set; only the IETF-published wire-level deployment of the primitives is held.

The Week in Detail

1. The RFC Editor re-hold of both pure PQ-TLS documents (Sept 24)

This is the structurally significant delta this week. Two state-machine transitions, same day, same AD, same cause.

The canonical datatracker comment, identical across both documents, is from Deb Cooley (Security AD) on 2026-09-24 11:33:38 -0700 (mlkem) / 2026-09-24 09:13:43 -0700 (mldsa):

"The wg chairs and AD have received complaint/appeals on the processing of this document. While the complaints/appeals are being reviewed, the document is being held ..."

The datatracker pages link to three mail-archive threads on the ietf.org/tls mailing list, confirming this is the same appeal that was first raised against mlkem in July 2025 and has cycled through chairs → AD → IESG.

The mlkem-11 upload on 2026-09-16 is procedurally important: it shows the author (Deirdre Connolly, Selkie Cryptography) anticipated the IANA version-changed re-verify and uploaded an -11 with the corrections needed to keep IANA review at "IANA OK - Actions Needed." The IANA review on -11 is not the problem; the RFC Editor queue position is the gate.

For freedom-tech deployers: the wire-level implication is unchanged from prior weeks — hybrid X25519MLKEM768 (RFC 10024) remains the citeable, cite-acceptable default. Pure ML-KEM and pure ML-DSA in TLS are not publication-rivaling in this window; the standards-track documents they reference are held. The cryptographic primitives (ML-KEM-768, ML-DSA-65, etc.) are unaffected; only the IETF-published deployment guidance for those primitives in TLS is held.

For federal contractors: the procurement clock is also unchanged. CNSA 2.0 first enforcement (Jan 1, 2027) does not require IETF publication of draft-ietf-tls-mlkem or draft-ietf-tls-mldsa; it requires FIPS-validated implementations, which exist and are not gated by the IETF document queue. The HSM/TLS code-path requirements (ML-KEM, ML-DSA, SLH-DSA in IKE/TLS) are independent of the appeal.

The substantive unaddressed claim: per the Sept 25 freenode report, the chairs "had earlier refused to release detailed tallies or weighting methods used to judge consensus, stating only that roughly seven in ten participants favored moving the document forward." Andrew Lee's separate escalation to the ADs asked which conduct rules were broken and called out the opacity as "feeding public concern about bias on a standard that will shape encryption for billions of users." The substantive complaint — that the consensus weighting methodology was not published — is not answered by declining the appeal "in its current form." The IETF's institutional posture is: pause publication, but not change the underlying consensus call.

2. ePrint 2026/2137 — single-trace ML-KEM key-recovery (Sept 21)

Authors: Vahid Jahandideh, Radboud University Nijmegen. URL: eprint.iacr.org/2026/2137

The paper demonstrates that the CBD (centered binomial distribution) sampler used in ML-KEM key generation — which produces coefficients with small Hamming weight (k=2 for ML-KEM-512/768, k=3 for ML-KEM-1024) — leaks enough per-coefficient information in a single power/EM trace that an adversary can recover the secret.

Why this is exploitable: a coefficient with k=2 can only take values in {-2, -1, 0, 1, 2}. The small domain means a single side-channel sample has high signal-to-noise against the noise floor of the measurement, even with practical leakage bandwidths.

The countermeasure (q-randomization): store each coefficient as v + r·q with random nonzero r, so the NTT and downstream code run unchanged but the measurement sees r·q + v instead of v. The randomization drives the sign-leakage to the noise floor (the random r dominates the Hamming-weight signal) and reduces the NTT magnitude leakage by 4.5×. Concretely: the lattice attack block size rises from 129 back to 611 — about 4 bits of estimated security lost instead of more than 140.

Cost of the countermeasure: 937 bytes of additional firmware.

Important boundary: this is not a break of the ML-KEM primitive. It is an implementation-hardening result — the standard FIPS 203 implementations (liboqs, AWS-LC, mlkem-native, OpenSSL via oqs-provider) do not include q-randomization in their reference code paths; an operator concerned about side-channel attacks on key generation (e.g., HSM vendor, embedded TLS implementer) needs to evaluate whether to adopt the countermeasure.

For the freedom-tech stack: most freedom-tech deployments use TLS via OpenSSL / Go / Rust / NSS; key generation is in the cryptographic library, and the libraries have not (yet) integrated this countermeasure. The risk is most acute for embedded systems where power-side-channel attacks are practical (smart cards, IoT, mobile devices with JTAG exposure). Server-side ML-KEM key generation in OpenSSL/AWS-LC is generally considered side-channel-safe by design (constant-time sampling), but the paper shows that even constant-time sampling may leak the small-domain signal — a subtler attack class than the standard side-channel literature addresses.

3. ePrint 2026/2131 — 1024-bit RSA forgery in nearly SNFS time (Sept 20)

Authors: Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger (UC San Diego); Emmanuel Thomé (INRIA Nancy). URL: eprint.iacr.org/2026/2131

The paper shows that the conventional RSA security estimates (based on GNFS / general number field sieve complexity for factoring) underestimate the concrete security cost for the signing-key structure. With a signing oracle (an adversary who can induce RSA signing operations), the SNFS (special number field sieve) applies to the signing-key parameters, yielding attack costs 15–30 bits lower than factoring-based estimates for RSA-1024 through RSA-4096.

The headline result: even RSA-4096 does not appear to meet a 128-bit security level in this attack model.

Important boundary: this is a with-signing-oracle attack. The adversary model assumes the attacker can submit chosen messages and observe signatures. Without an oracle, factoring-based security estimates still apply (modulo the standard cryptographic caveats about parameter generation, side channels, and implementation bugs). The paper's contribution is to show that the conventional factoring-based estimates systematically under-count the worst-case signing-key attack cost.

The authors' framing: "This highlights a gap in current RSA-type security assumptions, and gives classical cryptanalytic evidence in favor of moving away from RSA entirely during the current post-quantum transition." This is a notable rhetorical move — cryptanalytic results traditionally stay neutral on operational guidance, and the choice to frame this as "evidence for moving away from RSA" reflects the broader community consensus that the post-quantum transition is happening regardless of the quantum threat timeline.

For the freedom-tech stack: RSA-2048 and RSA-4096 remain ubiquitous in (a) TLS server certificates, (b) SSH host keys, (c) S/MIME email, (d) DNSSEC, (e) code signing (rare but persistent). The paper's contribution is to harden the case against continued RSA dependence in long-lived signing keys. ML-DSA-65 (FIPS 204) at 1,952-byte public key / 3,309-byte signature is the structural replacement; hybrid Ed25519+ML-DSA-65 is the conservative path. Cross-reference ML-DSA and Hybrid KEM Migration.

4. The freenode synthesis — McEliece parameter debate reactivated (Sept 25)

The Sept 25 freenode.net article is a synthesis of pqc-forum discussion, not a new cryptanalytic event. The two underlying events are:

(a) HAWK withdrawal — July 29, 2026 (not new news). Steve Weis (Anthropic) announced an improved key-recovery attack against HAWK-n that reduces to SVP in dimension n/2+1 (paper at eprint.iacr.org/2026/1593 and anthropic.com/document/hawk_key_recovery.pdf). Concretely: - HAWK-512 gate count drops from 2^150 to 2^108 (AGPS'20 model) - HAWK-1024 gate count drops from 2^288 to 2^182 - HAWK-256 was broken end-to-end in a few hours on one server - Weis was explicit: "This result does not impact Falcon, ML-DSA, or other lattice-based schemes." - The work was found by Claude "with minimal technical guidance from people" - Daniel Apon independently verified: "Nice. It checks out independently for me." - The HAWK team helped verify; withdrawal from the NIST process followed on July 29, 2026

(b) Classic McEliece quasipolynomial cryptanalysis — Aug 10, 2026 (not new news). Ghoshal/Ishai/Jain/Sun, eprint 2026/1630: a provable quasipolynomial-time distinguisher of Classic McEliece public keys from random bytes, plus a heuristic quasipolynomial decryption algorithm. The claimed complexity is below security level 1 for all parameter sets proposed by the Classic McEliece team.

What's new in the Sept 25 synthesis is the pqc-forum engagement: - Demi Marie Obenour (highlighted the McEliece paper on the forum): "The attack is currently impractical, but if it works, it seems quite devastating for Classic McEliece and for Goppa McEliece in general." Restoring margins would drive ciphertext sizes toward quadratic growth in the security parameter. Asked whether the scheme would retain any advantage over HQC or BIKE at that size. - Christopher Peikert (forum): noted claims on the order of 2^102 bit operations against Category 3 and 5 sets previously advertised near 2^207 and 2^272, asked whether it was "fair to claim that Classic McEliece is broken" for those parameters. - D. J. Bernstein (challenged naive bit-operation tallies): argued that the practical bottleneck is generating and routing ~2^93 bits across large RAM fabrics, and that hardware price-performance for long-distance routing is far worse than the pure gate model suggests. The exchange shifted the argument into cost models, memory hierarchies, and whether inflated parameters remain competitive once public keys move into the multi-megabyte range. - Steve Weis posted corrected tables and parameter examples showing how far (n, t) pairs must be stretched before the attacks sit behind 2^192 or 2^256 — with corresponding public-key blow-ups. - John Mattsson (Ericsson): cautioned against presenting FrodoKEM as the default conservative choice given thinner deployment and scrutiny than ML-KEM, and recommended an ML-KEM + HQC hybrid for diversification across hardness assumptions and better performance than FrodoKEM alone. - Bas Westerbaan (Cloudflare): answered with adoption graphs illustrating how uneven post-quantum uptake already is across human-driven and automated clients. - Obenour (operational): "One doesn't have to wait for a scheme to be standardized before deploying it." Cited OpenSSH shipping Streamlined NTRU Prime before ML-KEM was finalized as FIPS 203. For bandwidth-constrained settings (Ericsson links where only isogeny-based options fit), suggested operators who control both ends can field research constructions like MIKE, hybridized with ECDH and Kerberos-style symmetric keying, so that security holds if any component holds.

For freedom-tech: the substantive takeaway is ML-KEM + HQC hybrid is now the most explicitly-named diversification strategy on the standards track (per Mattsson's direct recommendation). The HQC KEM is the alternate KEM NIST selected for standardization in 2025; HQC standardization is expected 2026-2027 (per HQC). The hybrid ML-KEM-768 + HQC-128 combination provides diversification against the lattice-only assumption of ML-KEM while preserving performance within ~2× of pure ML-KEM. FrodoKEM is explicitly not the conservative default (per Mattsson); MIKE (isogeny-based, research-grade) can be fielded in operator-controlled settings.

5. The PLANTS MTC -06 (Sept 21) and composite-sigs forward motion (Sept 23)

Two documents in the authentication-side PQ-Web-PKI rail moved forward in the same 48-hour window — the first collective forward motion since the August static period.

draft-ietf-plants-merkle-tree-certs-06 uploaded 2026-09-21 by David Benjamin (Google). The previous version was -05 (June). The Sept 5 note had recorded the document as static. The -06 likely carries MTC inclusion-proof / tree-construction corrections. The document remains in WG Document state — no shepherd, no responsible AD, no IANA review yet. The PLANTS WG's roadmap (Let's Encrypt staging late 2026, production 2027, Chrome preferred) is unchanged. Cross-reference Merkle Tree Certificates.

draft-ietf-lamps-pq-composite-sigs made its first forward motion in 63 days on 2026-09-23. RFC Editor state changed from "In Progress (First Edit)" to "Awaiting Second editor" — the document has cleared first-edit and is waiting for the RFC Production Center's second-editor assignment. The IANA Action state remains RFC-Ed-Ack (set earlier in the queue lifecycle). Composite ML-DSA in X.509 PKI is now ~63 days in queue (started 2026-07-23). The Sept 19 estimate of "4–10 weeks further" should be revised: still likely 2–6 weeks given the second-editor ramp.

The September summary for the authentication-side PQ-Web-PKI rail:

The pattern: IETF-stream documents (mlkem, mldsa) are now held by dispute; LAMPS/PLANTS stream documents are advancing; individual drafts remain static. The institutional dispute on pure PQ-TLS is the gating constraint on the TLS authentication rail.

6. The library / deployment triple — liboqs, AWS-LC, OpenSSL

Notable: the XMSS OOB fix (#2511, liboqs commit a56c55b7) is a security-relevant patch landing after the Sept 5 CVE cluster — operators who updated to liboqs 0.16.0 on Sept 5 need to verify whether their build pulls the latest liboqs main to capture this. The OOB is on xmss_core_sign when the secret key OID doesn't match — a misconfiguration rather than a default-path attack, but still a defensive concern. Cross-reference Stateful Hash Signatures.

AWS-LC v5.10.0 is the fifth release of September (v5.5.0, v5.6.0, v5.7.0, v5.8.0, v5.9.0, v5.10.0). The cadence is roughly weekly — much faster than upstream OpenSSL's monthly cadence. Operators who standardize on AWS-LC rather than upstream OpenSSL get faster PQ patches. No fresh oqs-provider release in this window.

OpenSSL 4.1.0-beta1 (Sept 23) — three weeks after the alpha. The 4.1 line is a feature release; the PQ-relevant changes are carried over from 4.0.x. The 4.0.x / 3.6.x / 3.5.x security-patch cadence from September 9 (4.0.3 / 3.6.5 / 3.5.9, multi-CVE) has not produced another security advisory in the September 19–25 window. Cross-reference PQC Deployment and Libraries Tracker.

7. FIPS 206 (FN-DSA / Falcon) and the JOSE composite line

FIPS 206 status: unchanged. NIST submitted the draft for approval on 2025-08-28; the IPD has been under public comment since. The Google Groups pqc-forum thread on FIPS 206 status updates (groups.google.com/a/list.nist.gov/g/pqc-forum/c/1HXzjlMUU6Y) continues to accumulate feedback, including a recent thread on whether hedged signing should be preferred over plain randomized signing. No fresh public document from NIST in the September 19–25 window.

draft-ietf-jose-pq-composite-sigs-04 (Sept 11, Prabel/Sun/Gray/Reddy) is now ~14 days in queue. Still in WG Document state. The JOSE composite line is the active frontier for JWS/JWE PQ migration but is procedurally slow — no shepherd, no AD, no IANA review. Companion: draft-ietf-jose-pqc-kem-06 (Tschofenig/Reddy/Banerjee, JOSE WG, last updated 2026-07-06) cites FIPS 206 as upstream — unchanged.

draft-ietf-cose-falcon-04 expired 2026-09-16 per the IETF draft page. The COSE WG's FN-DSA document is now expired (no active revision). This is a maintenance concern — operators planning to cite the document should check whether a -05 has been uploaded since.

8. The September 25 freenode.net synthesis — what's actually new

The two articles published Sept 25 (ML-KEM TLS appeal and PQC timelines under pressure) are both syntheses of pqc-forum / standards-mailing-list discussion. They are useful because:

1. They collect dispersed pqc-forum comments into a coherent narrative — Bernstein, Peikert, Mattsson, Westerbaan, Obenour, Apon are all quoted with specific operational positions.
2. They identify the ML-KEM + HQC hybrid as the most explicitly-named diversification strategy on the standards track (Mattsson's recommendation).
3. They surface the HAWK-256 end-to-end break in hours on a single server as a concrete demonstration of AI-assisted lattice cryptanalysis — the Anthropic/Weis result was published July 29 but the deployment-time implication ("lattice designs still outside the finalized set can lose security margin quickly, and AI assistance can shorten the path from design claim to concrete break") was not fully synthesized until Sept 25.
4. They surface the operational distinction between "wait for standardization" and "deploy now if you control both endpoints" (Obenour's argument, with OpenSSH+NTRU Prime as precedent).

What they don't break: ML-KEM, ML-DSA, SLH-DSA, HQC, BIKE, FrodoKEM (the finalized or near-finalized schemes). The HAWK withdrawal removes one Round 3 signature candidate; the McEliece parameter debate threatens an alternate KEM that has not been formally selected. The operational recommendation set is: hybrid (RFC 10024) for TLS, hybrid Ed25519+ML-DSA-65 for high-value code signing, ML-KEM+HQC for diversification, SLH-DSA for conservative backup, MIKE for operator-controlled research-grade paths.

9. The federal procurement and standards calendar

What changed since September 19

Operator checklist for the September 19–25 window

For a federal-contractor or vendor shipping PQ-relevant products: - [ ] RFC Editor re-hold: both draft-ietf-tls-mlkem and draft-ietf-tls-mldsa are Blocked under appeal as of 2026-09-24. The IANA registry step is procedurally complete on mlkem-11; only the queue position is gated. Do not cite either as an imminent RFC. Cite RFC 10024 hybrid for the wire default. The cryptographic primitives (ML-KEM-768/1024, ML-DSA-65/87) are unaffected. - [ ] Composite ML-DSA in X.509 PKI: now in "Awaiting Second editor" RFC Editor state (first forward motion in 63 days). Cite as draft-ietf-lamps-pq-composite-sigs-19; assume RFC publication in the next 2–6 weeks (second-editor ramp). - [ ] MTC (PLANTS) -06 uploaded 2026-09-21 by David Benjamin. Document still in WG Document state. Cite as draft-ietf-plants-merkle-tree-certs-06. No change to Let's Encrypt staging late 2026 / production 2027 roadmap. - [ ] liboqs XMSS OOB fix (#2511, commit a56c55b7): OOB on xmss_core_sign when secret key OID mismatches. Verify your liboqs build pulls the latest main if you ship XMSS. Cross-reference Stateful Hash Signatures. - [ ] AWS-LC v5.10.0 (Sept 23) — fifth release of September. Upgrade automation for operators on AWS-LC; PQ changes carried forward. - [ ] OpenSSL 4.1.0-beta1 (Sept 23): feature-line release; not a security advisory. The PQ-capable-branch security cadence (4.0.3 / 3.6.5 / 3.5.9 from Sept 9) has not produced another security release in this window. - [ ] OMB M-26-15 Migration Plan: due Oct 22 (26 days). Cover: HSM roadmap; TLS hybrid deployment; code-signing path; SSH PQ hybrid; long-term archive encryption; identity/PIV PQ plan. No change from prior weeks. - [ ] IETF-127 attendance (Nov 14–20, 49 days): LAMPS agenda should have composite-sigs published or imminent; PLANTS agenda should have MTC -06 advancing; TLS agenda likely delayed by the appeal dispute; JOSE agenda should have JOSE composite-sigs-04 advancing. - [ ] FIPS 206 final: still pending. No fresh NIST public document in this window. DigiCert's "wait until final" position holds. Operators planning around FN-DSA should have a fallback to ML-DSA-65.

For a freedom-tech deployer (independent of federal procurement): - [ ] No action items from the appeal: the KEM-then-compose architecture is the IETF's documented path; the dispute is about specific document publication, not about the cryptographic primitives. Continue deploying hybrid (RFC 10024 in TLS; mlkem768x25519 in SSH; Signal PQXDH in messaging; iMessage PQ3 in messaging; RFC 9980 hybrid in OpenPGP). - [ ] ML-KEM + HQC hybrid is now the most explicitly-named diversification strategy (per John Mattsson's Sept 25 pqc-forum post). For operators with the freedom to deploy non-finalized primitives, this is the standards-track-aligned diversification path. HQC standardization is expected 2026-2027; operators can field HQC hybrid before the standard finalizes. Cross-reference HQC. - [ ] ML-KEM key-generation side-channel: ePrint 2026/2137 shows CBD samples are vulnerable to single-trace attack. For embedded / side-channel-exposed deployments, the q-randomization countermeasure (937 bytes firmware) restores ~4 bits of security loss instead of >140. Not a primitive break; an implementation-hardening result. - [ ] RSA-4096 does not meet 128-bit security in the signing-oracle model (ePrint 2026/2131). Continue moving away from RSA for long-lived signing keys. Hybrid Ed25519+ML-DSA-65 per Hybrid KEM Migration; ML-DSA-65 alone for short-lived signing. - [ ] MIKE (isogeny-based, research-grade) can be fielded in operator-controlled settings where only isogeny-based options fit (per Obenour's Sept 25 forum post). Hybridize with ECDH and Kerberos-style symmetric keying so security holds if any component holds. - [ ] No action items on the Dihedral Coset line: the August 15 GRZ refutation stands; ML-KEM and ML-DSA are not moving.

Primary sources

IETF datatracker state (verified Sept 26, 2026)

• draft-ietf-tls-mlkem history: datatracker.ietf.org/doc/draft-ietf-tls-mlkem/history/ — Sept 24 11:33 RFC Editor Blocked under appeal (Cooley); Sept 16 mlkem-11 uploaded (Connolly); Sept 10 IANA Action RFC-Ed-Ack
• draft-ietf-tls-mldsa history: datatracker.ietf.org/doc/draft-ietf-tls-mldsa/history/ — Sept 24 09:13 RFC Editor Blocked under appeal (Cooley); Sept 18 IANA Action Waiting on Authors; Sept 11 -06 uploaded (Westerbaan)
• draft-ietf-lamps-pq-composite-sigs history: datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/history/ — Sept 23 RFC Editor state Awaiting Second editor from In Progress (First Edit)
• draft-ietf-plants-merkle-tree-certs history: datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/history/ — Sept 21 -06 uploaded (David Benjamin)
• IETF TLS mailing list (appeal threads): mailarchive.ietf.org/arch/msg/tls/tbm16GSRC9xIKVasYHicFum1W8M/, mailarchive.ietf.org/arch/msg/tls/gwJ35jrHgNi0Q-SXamXy__f2f_w/, mailarchive.ietf.org/arch/msg/tls/mZgxd2_hYZP5VEFBal9GjACGSG8/

ePrint papers (verified Sept 26, 2026)

• 2026/2137: Too Small to Hide: Single-Trace Key Recovery from ML-KEM Key Generation — Jahandideh, Radboud, Sept 21
• 2026/2131: Forging 1024-bit RSA signatures in nearly SNFS time — Shea/Haller/Suhl/Heninger/Thomé, Sept 20
• 2026/2149: Identify Post-Quantum Cryptographic Algorithms for Automotive Security — Kushwaha/Thales DIS, Sept 22
• 2026/2142: PRAWNS: Threshold Hash-Based Signatures from Threshold PRFs — Sept 21
• 2026/2139: A Latency-Aware FPGA Architecture for SHAKE256 with Guarded Final-Block Construction — Sept 21 (PQ-relevant FPGA)
• 2026/974: LoTRS: Practical Post-Quantum Structured Threshold Ring Signatures from Lattices — Sept 21
• 2026/2136: MAMBA-Frost: A Lattice KEM from Learning With Quantization — Sept 21
• 2026/1290: A Compact Signature Scheme Based on QC-MDGM Codes — Sept 21
• 2026/1374: Analysing the Post-Quantum Security of S/MIME — Sept 21
• 2026/1593: HAWK-n Key Recovery Reduces to SVP in Dimension n/2+1 — Weis, Anthropic, July 29 (referenced in Sept 25 synthesis)
• 2026/1630: Quasipolynomial Cryptanalysis of the McEliece Cryptosystem — Ghoshal/Ishai/Jain/Sun, Aug 10 (referenced in Sept 25 synthesis)

GitHub releases and commits (verified Sept 26, 2026)

• open-quantum-safe/liboqs — 3,071 stars, pushed 2026-09-25; tagged 0.16.0 (Jul 9, 2026); commit b196b57 AES-192 (Sept 24), commit a56c55b7 XMSS OOB fix (Sept 21)
• open-quantum-safe/oqs-provider — 499 stars, pushed 2026-09-19; tagged 0.12.0-rc2 (Sept 16); commit 36cafae0 MAYO/MQOM/SNOVA Round 3 update (Sept 19)
• aws/aws-lc — 835 stars, pushed 2026-09-25; tagged v5.10.0 (Sept 23), v5.9.0 (Sept 15)
• openssl/openssl — 30,841 stars, pushed 2026-09-25; tagged openssl-4.1.0-beta1 (Sept 23), openssl-4.1.0-alpha1 (Sept 9)

Standards / synthesis sources

• freenode.net — IETF rejects appeal on ML-KEM TLS consensus and NSA conflict claims — Sept 25 (Kubota appeal narrative)
• freenode.net — PQC timelines under pressure after HAWK collapse and McEliece parameter shocks — Sept 25 (synthesis)
• NIST pqc-forum — FIPS 206 status updates thread — ongoing
• NIST pqc-forum — HAWK-n attack announcement — Weis, July 29
• OpenSSL 4.1.0-alpha1 announcement — Help Net Security — Sept 10
• OpenSSL 4.1 Alpha 1 — Phoronix — Sept 9
• hawK-sign.info — HAWK team's withdrawal notice
• anthropic.com/document/hawk_key_recovery.pdf — Anthropic-hosted HAWK paper

Related Notes

• Post-Quantum Saturday — September 19 2026 Weekly Update — prior weekly update (ePrint 2026/2017 defeats ZZDSD-AKE/GDLL-KE; GSA PQC Summit; ML-KEM IANA OK - Actions Needed; composite ML-DSA 56 days in queue; CNSA 2.0 104 days).
• Post-Quantum Saturday — September 12 2026 Weekly Update — prior weekly update (ML-DSA-in-TLS cleared 65-day appeal Sept 11; pure ML-KEM Approved-announcement sent Sept 3; ePrint 2026/1915+1922 ML-KEM side-channel papers; OpenSSL 4.0.3 multi-CVE).
• Post-Quantum Saturday — September 05 2026 Weekly Update — prior weekly update (pure ML-KEM approved by IESG Sept 3; MTC status corrected to WG-document; SVP in 2^0.7314n; FHE sparse Ring-LWE loses up to 13 bits; liboqs XMSS CVE cluster).
• Overview - Post-Quantum Cryptography — long-form canonical overview.
• PQC Deployment and Libraries Tracker — 2026 deployment map.
• The Dihedral Coset Attack Line — twenty-year research program from Regev 2004 to GRZ 2026 no-go.
• Merkle Tree Certificates — PQ Web PKI breakthrough; Let's Encrypt staging late 2026, production 2027.
• Hybrid KEM Migration — operational migration playbook.
• ML-KEM, ML-DSA, SLH-DSA, HQC, FN-DSA Falcon — algorithm notes.
• Bitcoin PQ Migration — blockchain-specific migration.

Vault note: this update follows the September 19, 2026 weekly entry. The next scheduled PQC weekly will be Post-Quantum Saturday — October 03 2026 Weekly Update. Verified against IETF datatracker history pages on 2026-09-26 13:00 UTC; ePrint recent-papers scan on 2026-09-26 12:30 UTC; GitHub API on 2026-09-26 12:30 UTC.