PQC移行の今 -- IETF からみた現在地

2026年9月25日の #pqc_study「耐量子暗号って結局どうやって使うの？」で発表した「PQC移行の今 ― IETF からみた現在地」の資料です。

Transcript

1. #pqc_study PQC移行の今 IETF からみた現在地 2026年9月25日 菅野 哲（かんの さとる） GMOコネクト株式会社 E-mail: kanno@gmo-connect.jp / X: satorukanno / Facebook: satoru.kanno 本資料の記載内容は 2026年9月24日 時点の調査に基づく
2. この人、誰？ 名前 菅野 哲（かんの さとる） 所属 GMOコネクト株式会社 執行役員CTO（2025年7月〜） 自己紹介 公正取引委員会 デジタルアナリスト（2024年5月〜）／チーフテクノロジスト（2025年7月〜） GMOインターネットグループ 主席研究員（2026年1月〜） これまで 学生時代は暗号プロトコルの研究開発 NTTテクノクロスで暗号ライブラリと情報セキュリティ関連システムを開発 IETF では Camellia 関連の標準化に関わった いま 会社の経営と、研究開発の支援や開発プロジェクト IETF には今も出ている。直近は 2026年7月の IETF 126（ウィーン）で 24 セッション 1
3. 鍵交換は完了！ 証明書はこれから。 今日の結論 鍵交換 ― もう終わっている 証明書 ― まだ始まっていない • Cloudflare を通る人間由来トラフィックの • 同じ調査で、ハイブリッドPQ証明書は 0% 65% 超 • 32,011 ドメインの調査で 49.3% が対応 • RFC 10024 として標準化ずみ。IANA の Recommended は Y • 主要ブラウザは既定で有効。Edge 147 以降は 無効化するポリシー自体が消えた • OpenSSL 3.5 / Go 1.24 以降は、設定を書か • X.509 の部品は RFC 化済み（RFC 9881 ほか） それでも公開の Web では発行できない • CA/Browser Forum のバロットは Draft のPull Request のまま。議論期間にも入っていない • TLS で ML-DSA 署名を使う仕様はまだ RFC 前 。IANA の Recommended も N • いつ現行方式をやめるのかを決めた組織はない なくても有効 前半はこの左側の話。あなたが何もしないうちに終わっていた理由を見ます。 後半は右側。なぜ同じようにはいかないのかを見ます。 出典: Cloudflare（2026-04-07）／ Dubey & Varshney "Measurement Study of Post-Quantum Readiness of Internet: 2026" arXiv:2606.16473（2026-06-15） https://arxiv.org/abs/2606.16473 ／ IANA TLS Supported Groups 2
4. 今日ここに申し込んだとき、もう使っていた 実測 for h in connpass.com www.google.com www.gmo.jp github.com www.debian.org gmo-connect.jp; do o=$(openssl s_client -connect $h:443 -servername $h -tls1_3 </dev/null 2>/dev/null) g=$(echo "$o" | sed -n 's/.*Negotiated TLS1.3 group: //p') [ -z "$g" ] && g=$(echo "$o" | sed -n 's/.*Peer Temp Key: //p' | cut -d, -f1) s=$(curl -sI https://$h/ | sed -n 's/^[Ss]erver: //p' | tr -d '\r') printf "%-18s %-16s %s\n" "$h" "$g" "$s" done connpass.com X25519MLKEM768 CloudFront www.google.com X25519MLKEM768 gws www.gmo.jp X25519MLKEM768 cloudflare github.com X25519 github.com www.debian.org X25519 Apache gmo-connect.jp X25519 nginx 上の3つは CDN のエッジが応答している。下の3つは各組織が自分で立てたサーバ。 gmo.jp と gmo-connect.jp は同じグループ。CDN の上にあるほうだけが耐量子計算機暗号対応。 計測: 2026年9月24日 18:35 JST / OpenSSL 3.6.4（macOS・日本から） 3
5. ブラウザ側は終わり、サーバ側は始まったばかり Cloudflare を通る人間由来トラフィック サーバ側の対応率 2024年初 3% 未満 2023年 2025年10月 2026年4月 過半を超えた 65% 超 2026年2月 約 10% 2026年9月8日 12.8% 普及率 0.5% ブラウザ側は2年で 3% → 65%。サーバ側は3年で 0.5% → 12.8%。桁がひとつ違う。 業種で、さらに違う（IETF 126 の実測・抜粋） PQC 率 第三者に預けている割合 インターネット全体 63.0% 61.3% 病院 48.7% 95.4% US Financials 31.0% 100.0% 医療・政府 18.5% 95.8% 預けている割合が高いほど、自分では決められない。US Financials は自社ASN ゼロで PQC 率31%。 出典: Cloudflare Radar 関連記事（2026-02-27 / 04-07 / 09-08）／ Nalini Elkins "Measuring Deployment Characteristics of PQ TLS Authentication Mechanisms", IETF 126 PLANTS（n は公開IP数） 4
6. 誰も設定していない。既定が変わっただけ 2024年4月 Chrome 124 デスクトップで既定有効。当時は Kyber 2024年11月 Chrome 131 / Firefox 132 Kyber を打ち切り X25519MLKEM768 へ 2025年2月 Go 1.24 未設定なら既定で有効 2025年4月 OpenSSL 3.5（LTS） 既定の keyshare が X25519MLKEM768 に 2025年4月 OpenSSH 10.0 鍵交換の既定に 2025年10月 Apple iOS 26 / macOS Tahoe 26 の ClientHello に追加 経緯 Go で書いて nginx で公開していれば、もう使っている。設定した記憶がなくてもOK？ そして、もうやめられない Microsoft Edge は 147 以降、無効化するポリシー自体が削除された。原文は 「Post-quantum key agreement is now enabled by default and cannot be disabled.」。Chrome のポリシーも 146 まで。 出典: 各プロジェクトの公式リリースノート ／ Microsoft Edge ポリシー文書（逐語） 5
7. リクエストが、1パケットに収まらなくなった 何が起きたか 現行 X25519 鍵共有だけで 32 バイト → 1,216 バイト X25519MLKEM768 ClientHello 全体では 236 バイト → 1,422 バイト ブラウザはもっと大きい 仕様側でも問題として書かれている GREASE や ALPN など拡張をさらに積むので、 ここから更に膨らむ。 key share may exceed the MTU, potentially causing the ClientHello message to be fragmented across multiple packets. — draft-ietf-uta-pqc-app §4.1 計測: 2026年9月24日 connpass.com 宛。openssl s_client -msg の出力を text2pcap で pcap 化し Wireshark で表示 ／ draft-ietf-uta-pqc-app-03 https://datatracker.ietf.org/doc/draft-ietf-uta-pqc-app/ 6
8. 壊れたのは、PQC が原因なのか？ 非互換 Google 自身の言葉（Chromium Blog, 2024-05-23） This rollout revealed a number of previously-existing bugs in several TLS middlebox products. (意訳) 今回のことでいくつかのTLSミドルボックス製品に以前から存在していた複数の不具合が明らかになった。 原因は、TLS レコードの2バイトの長さフィールドを読み切るループを書いていないこと 「Most buggy servers are not prepared to have to call read() more than once」— tldr.fail 実名で記録されている製品 Vercel 2023-08 修正 ZScaler 2023-09 修正 Palo Alto 2025-03 修正 (PAN-247099) Fortinet IPS Engine 更新 (#1097642) Apache Traffic Server 2025-06 修正 Envoy not planned でクローズ Broadcom ProxySG 2024年後半 修正 Ingress Nginx 未修正・リポジトリはアーカイブ Cloudflare「この互換性問題がなければ、Chrome の PQ 鍵交換の展開は5年早かっただろう」（訳） 結論 → もともとあったバグを、PQC が踏んだだけ 出典: "Advancing Our Amazing Bet on Asymmetric Cryptography" Chromium Blog 2024-05-23 https://blog.google/chromium/advancing-our-amazing-bet-onasymmetric/ ／ tldr.fail https://tldr.fail/ ／ "State of the post-quantum Internet in 2025" https://blog.cloudflare.com/pq-2025/ 7
9. ユーザに見えたのは、これだけ 非互換 The connection to Outgoing server (SMTP) timed out Thunderbird 138〜142 で、Office 365 にメールを送れなくなった人がいた。 条件は「PQ 鍵交換が有効」かつ「経路上に大きい ClientHello を落とすファイアウォールや UTM がある」 だけ Mozilla の判定 RESOLVED INVALID ― 「Thunderbird の欠陥ではない。経路上の機器か、接続先のサーバ側を直す必要がある」という結論。 回避策は security.tls.enable_kyber を false にすること。 Microsoft も同じことを書いている。「これらの機器は post-quantum-ready ではない。ベンダーに修正を依頼せよ」。 そして Edge 147 で、逃げ道のポリシーは消えた。 他に記録されているエラー: ERR_CONNECTION_RESET ／ ERR_SSL_PROTOCOL_ERROR ／ ERR_TIMED_OUT 誰も自分の欠陥だとは言わないまま、ユーザだけが困るという困った状況… 出典: Bugzilla Bug 1967998 "SMTP sending fails with Office 365 on Thunderbird Release 138-142" https://bugzilla.mozilla.org/show_bug.cgi?id=1967998 ／ Microsoft Learn "PostQuantumKeyAgreementEnabled" https://learn.microsoft.com/deployedge/microsoft-edge-browser-policies/postquantumkeyagreementenabled 8
10. アルゴリズムは、もう選び終わっている NIST 2016年12月 公募開始 Call for Proposals 2017年11月 提出締切 ここから約8年 2024年8月13日 FIPS 203 / 204 / 205 発行 ML-KEM（鍵交換・格子）／ ML-DSA（署名・格子）／ SLH-DSA（署名 ・ハッシュ） 2025年3月11日 HQC を追加選定 符号ベース。ML-KEM が依存する格子問題とは別の問題に安全性を置く 2026年5月14日 追加署名 9本が第3ラウンドへ 多変数・符号・ハッシュ・同種写像など、格子以外を中心に9本 なぜ何本も選ぶのか 格子問題に何かあったとき、全部が一度に倒れないようにするため。 だから HQC（符号）と SLH-DSA（ハッシュ）が別枠で要る。 FN-DSA（FIPS 206・格子）は開発中で、2026年9月時点ではドラフトも出ていない。 PQCアルゴリズムは選び終わった。残っているのは、それをどう載せるか 出典: csrc.nist.gov（2026-09-22 確認） 9
11. 各国での PQC 選定 各国 鍵確立（KEM） 署名 NIST（FIPS） ML-KEM ／ HQC 選定済 ML-DSA ／ SLH-DSA ／ FN-DSA（開発中） NSA CNSA 2.0（米 NSS） ML-KEM-1024 のみ ML-DSA-87 のみ ＋ LMS / XMSS。SLH-DSA は 非承認 ドイツ BSI ML-KEM ＋ FrodoKEM ＋ Classic McEliece ML-DSA ／ SLH-DSA 韓国 ML-KEM ＋ 独自の NTRU+ ／ SMAUG-T ML-DSA ／ SLH-DSA ＋ 独自の HAETAE ／ AIMer 中国 独自公募の第1ラウンド候補を公表した段階 同左。確定した選定結果はまだ無い 日本 CRYPTREC ML-KEM-768 / 1024 を掲載 未掲載（2026年度の継続検討課題） SLH-DSA は NIST 標準だが、NSA は自国の国家安全保障システムには採用していない。 BSI は NIST が本命にしなかった FrodoKEM と Classic McEliece も併記している。 独自公募を持つ国も、NIST 標準を捨てるわけではない 韓国は独自4本と NIST 標準を並べて制度に載せる。中国の受理拒否は公募のルールであって、使用の禁止ではない。 出典: 各国の技術ガイドライン（最終確認 2026-06-23）／ 中国 ICCS 第1ラウンド候補公表（2026-09-20、署名34・鍵カプセル化41・鍵交換9・ハッシュ35） https://www.niccs.org.cn/niccs/Notice/pc/content/content_2100875480644800512.html 10
12. どこも、鍵交換を先に済ませている 共通点 選択するアルゴリズムは各国で異なる。それでも鍵交換を先に片付けて署名を後回しにする点だけは共通している。 鍵交換 ― もう決まっている 署名・証明書 ― まだ決まっていない RFC 10024 として発行ずみ draft-ietf-tls-mldsa は RFC Editor 待ち IANA の Recommended = Y IANA の Recommended = N 日本 CRYPTREC ML-KEM を推奨リストに掲載済み 未掲載。2026年度の継続検討課題 韓国の暗号モジュール検証 2029年1月に搭載を義務化 その1年後の 2030年 Web の実態 人間由来トラフィックの 65% 超 公開の証明書は、まだ発行できない IETF の勧告レベル 鍵交換が先行したのは、ハイブリッド方式で古い相手と互換を保てたから。署名は、証明書を受け取る側すべてが対応する まで切り替えられない。 つまり今日の話の後半は、まだ誰も終わっていない領域の話 出典: IANA TLS Supported Groups ／ CRYPTREC 電子政府推奨暗号リスト LS-0001-2022R2 ／ 韓国の日程は ZDNet Korea 2026-09-20 の報道（二次情報） 11
13. TLS で送る署名まわりのデータが、桁で増える サイズ 署名 検証鍵（公開鍵） 署名鍵（秘密鍵） Ed25519 64 32 32 ML-DSA-44 2,420 1,312 2,560 ML-DSA-65 3,309 1,952 4,032 ML-DSA-87 4,627 2,592 4,896 SLH-DSA-128s 7,856 32 64 SLH-DSA-256s 29,792 64 128 相手に送るのは署名と検証鍵。署名鍵は手元に残るので回線には出ない。 鍵交換側も、X25519 の 32 バイトが X25519MLKEM768 で 1,216 バイトになる。 現在の TLS ハンドシェイクが運んでいるもの 平均で 署名 5つ および 検証鍵 2つ（リーフ署名・中間CA署名・クロス署名・SCT 2つ） SCT は Certificate Transparency のログ証明。ブラウザが証明書の公開記録を確かめるために要求する 中間証明書を直接信頼していても、SCT 2つとリーフ署名を ML-DSA-44 にするだけで +7,260 バイト 素直に置き換えると、1回のハンドシェイクが 10 キロバイトを軽く超える 1つが大きいだけでなく、7つ載っている 出典: FIPS 204 Table 2 / FIPS 205 Table 2（いずれも確定版）／ draft-ietf-plants-merkle-tree-certs-05 §1 ／ Let's Encrypt "A Post-Quantum Future for Let's Encrypt" （2026-06-03） 12
14. 証明書チェーンにある 10 キロバイトの壁 性能 Cloudflare の実測 Chrome が設定した許容上限 証明書チェーンが 10 kB を超えると、初期輻輳 ハンドシェイク時間の悪化は 10% まで ウィンドウの都合で性能が急に落ちる 鍵交換を PQ にした時点で、すでに 4% 使った 9 kB でも、ハンドシェイク時間は約 15% 悪化 残り 6% で、署名を 20倍にしなければならない 10 kB を超える証明書チェーンを嫌うクライアントや中間装置は、実在する。 2021年の実験では、ダミー証明書を足していくと 10 kB と 30 kB にはっきりコブが出た。 35 kB 追加すると、ハンドシェイクの中央値は 40% 遅くなる。 ちなみに、再開なしの QUIC 接続の過半では、サーバ→クライアントの転送量の約40%が証明書。 だから「ML-DSA に置き換える」が、そのままでは通らない 出典: Cloudflare, State of the post-quantum Internet in 2025 ／ Sizing Up Post-Quantum Signatures (2021) 13
15. 工夫が効くのは、鍵交換までだった 1,000人グループ MLS Welcome Commit 現行（X25519+Ed25519） 251 KB 1.5 KB 鍵交換のみ PQ（署名は現行） 2.6 MB 25 KB 鍵交換も署名も Pure PQC 10.5 MB 46 KB SlimMLS 適用後 7.7 MB 9.3 KB 1,000人のグループに1人が参加するときの Welcome Msg。 「Pure PQC」はハイブリッドなしの構成。 ※ MLS ＝ IETF が標準化したグループメッセージングの暗号プロトコル 右端はハイブリッドを挟まない Pure PQC の構成（ML-KEM-1024 + ML-DSA-87）。 MLS WG は縮小案を3つ同時に出した（SlimMLS / Partial MLS / Server-Aided MLS）。SlimMLS は署名の最適化にも手を付けてい る。手を付けたうえで、7.7 MB で止まった。 出典: IETF 126 MLS WG, SlimMLS（Raphael Robert / Konrad Kohbrok）p.34 14
16. 現在、Web ではまだ ML-DSA 証明書を出せない 制度 CA/Browser Forumにおいて… TLS で ML-DSA を許可するバロットは、2026年9月時点で Draft の Pull Request（SC-106）のまま。 議論期間にすら入っていない。手続きが滞っているのではなく、中身で揉んでいる。 2026年8月31日のコメント：これはブラウザ向けなのか、組織内で閉じた PKI 向けなのか Chrome 150 ML-DSA 証明書に対応した。ただし「it is not currently possible to issue a publicly trusted ML-DSA certificate」 Mozilla Root Store Policy v3.1（2026年7月発効）に PQC の記載なし Microsoft PQC TLS Pilot は公開信頼されず、CCADB にも CT にも入らない S/MIME こちらは可決済み（2025年8月）。TLS だけが動いていない アルゴリズムは2年前に決まったのに、まだ発行できる状態にない 出典: cabforum/servercert PR #679（2026-09-22 確認）／ Chrome Enterprise リリースノート 15
17. Web PKI が選んだのは、証明書の形を変えること MTC Merkle Tree Certificates（MTC） CA が多数の証明書をまとめて1つの Merkle Treeに載せ、TreeのRootだけに署名する方式 個々の証明書には署名を付けず、そのTreeに入っていることを示す短い証拠を代わりに添える。 署名 5つ ＋ 検証鍵 2つ → 署名 1つ ＋ 検証鍵 1つ ＋ inclusion proof 1つ（800 バイト未満） ML-DSA をそのまま証明書に入れると 10 キロバイトの壁に当たる。だから運び方ごと変えた Let's Encrypt（CA） staging 2026年後半 ／ production 2027年 を目標 Chrome（ブラウザ） MTC 専用の別ルートストア（CQRS）を 2027年 Q1・Q3 の2段階で Cloudflare（CDN） 実装を表明。Chrome と実現可能性の検証を実施済み IETF 専用WG「PLANTS」を新設。標準文書は 2026年11月 提出目標 仕様の著者は David Benjamin（Google）／ Devon O'Brien（Apple）／ Bas Westerbaan・Luke Valenta（Cloudflare）／ Filippo Valsorda。ブラウザ2社と CDN が並んでいる。 出典: letsencrypt.org (2026-06-03) ／ draft-ietf-plants-merkle-tree-certs-05 16
18. 一方、現行方式との併用をどうするかは未決定 現場 前のページの MTC は「証明書をどう運ぶか」の作業。こちらは「PQC と現行方式の署名をどう併用するか」で、別の作業。 IETF 126 TLS WG 金曜（2026年7月24日・出席170名）の意向確認 進め方を決めるだけの情報は揃っているか 賛成 67 反対 10 WG は PQ と現行方式のハイブリッド署名に取り組むべきか 賛成 53 反対 20 dual certificates（2枚使う）だけをやるべきか 賛成 8 反対 51 composite（1枚に束ねる）だけをやるべきか 賛成 53 反対 8 しかし、全体会議での発言 chairs の裁定の結果は個人的に支持するが、これは consensus ではない ― Martin Thomson 前回会合以降に IETF へ提起された不服申立6件のうち、5件が TLS WG に関するもの。 「両方やるか」「どちらを先にやるか」を問う3つの設問は、用意されたが実施されなかった。 53対8の支持を得た composite の仕様は、2か月たっても個人ドラフトのまま。採択の呼びかけが出ていない。（2026年9月 22日 確認） 出典: IETF 126 TLS WG（Meetecho の投票記録）／ plenary 議事録 ／ datatracker 17
19. 配り始めても、終わらない S字カーブ IETF 126 SAAG / David Benjamin 更新済みのクライアントが互換性の ために現行証明書を受け入れ続ける 限り、CRQC を持つ攻撃者は、 現行証明書を偽造するだけで接続を破れる CRQC ＝ いまの公開鍵暗号を現実的な時間で解ける規模の量子計算機 配ることと、現行証明書の受け入れをやめることは、 別の工程。 IAB も同じことを言っている Post-quantum authentication is the harder half, and 赤い部分は、すべて守れていない。 緑になるのは、クライアントが PQ を必須にしてから。 it lags. 鍵交換ではなく認証のほう、つまり署名と証明書のワ ークショップが、この2週間後にプラハで開かれる。 図の出典: David Benjamin "How to beat the S-curve: Post-Quantum Authentication" p.15、IETF 126 SAAG（2026-07-24） ／ IAB pqws Call for Papers 18
20. 明日から、3つだけ 1 実務 確かめる $ openssl version # 3.5.0 以上が要る $ openssl s_client -connect example.com:443 -servername example.com \ -tls1_3 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group" 2 有効にする ― nginx なら、実は何も書かなくていい OpenSSL 3.5 以上とリンクしていれば既定で有効。書くなら ssl_ecdh_curve に X25519MLKEM768 を先頭で並べるだけ。 ただし OpenSSL 3.5 を同梱するディストリは Debian 13 / Alpine 3.22 / RHEL系 10.1 / SLES 16 くらい。 3 読む RFC 9958「Post-Quantum Cryptography for Engineers」（2026年6月） IETF の PQUIP WG が、実装者向けに用語と落とし穴をまとめたもの。数式は出てこない。 次の観測点は2つ。IAB が、鍵交換ではなく認証（署名と証明書）に絞ったワークショップを 10月11〜12日にプラハで開催。 OpenSSL カンファレンスとの併催。 そして IETF 127（11月14日〜・サンフランシスコ）で、前のページの composite が動くかどうか気になりますね！ RFC 9958 https://www.rfc-editor.org/rfc/rfc9958.html ／ IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication (pqws) https://datatracker.ietf.org/group/pqws/about/ 19
21. 持ち帰ってほしい3つ 1 まとめ あなたはもう PQC を使っている。設定した記憶がなくても。 CDN とライブラリの既定が変わっただけ 2 壊れたのは PQC のせいではない。もともとあったバグを踏んだだけ。 read() を1回しか呼んでいない実装が、大きくなった ClientHello で落ちた 3 証明書は、配り始めても守れない。現行証明書の受け入れをやめるまでは。 そして、いつやめるのかを決めた人はまだいない 出典は付録 E に一覧があります。質問は kanno@gmo-connect.jp まで。 20
22. 付録 当日は話さないが、後で読み返せるように
23. なぜ鍵交換だけ、先に片付いたのか 付録 A 脅威の性質が、鍵交換と署名とで違うため。 鍵交換が守るもの ― 受動的な攻撃 署名が守るもの ― 能動的な攻撃 いま通信を録っておいて、量子計算機が 接続しているその場で証明書を偽造し、 できてから復号する。 通信に割り込む。 録るだけなので、攻撃者は今この瞬間に 偽造には、その瞬間に量子計算機が要る。 何も持っていなくてよい。 過去に遡って破ることはできない。 できる前に手を打たないと間に合わない。 できるまでに間に合えばよい。 NIST IR 8547（ドラフト） Encrypted data remains at risk because of the "harvest now, decrypt later" threat in which adversaries collect encrypted data now with the goal of decrypting it once quantum technology matures. IETF 126 SAAG / David Benjamin Actual goal is a security property: an active quantum adversary cannot intercept connections between updated clients and updated services. この差が、本編の「どこも鍵交換を先に済ませている」の理由。急ぐ理由が、そもそも違う。 出典: NIST IR 8547 ipd ／ David Benjamin "How to beat the S-curve" p.7・p.11、IETF 126 SAAG 21
24. 主要な標準のいま（正式タイトル） 付録 B 文書番号 正式タイトル 状態 備考 RFC 10024 Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 Proposed Standard / 2026 Recommended = Y 年8月 RFC 9954 Hybrid Key Exchange in TLS 1.3 Informational / 2026年7月 RFC 10042 Post-Quantum Traditional Hybrid Key Exchange in SSH Informational / 2026年8月 RFC 9846 The Transport Layer Security (TLS) Protocol Version 1.3 Standards Track / 2026年 7月 RFC 9958 Post-Quantum Cryptography for Engineers Informational / 2026年6月 最初に読む1本 draft-ietf-tls-mlkem-11 ML-KEM Post-Quantum Key Agreement for TLS 1.3 RFC Editor 待ち Recommended = N draft-ietf-tls-mldsa-06 Use of ML-DSA in TLS 1.3 RFC Editor 待ち Recommended = N draft-ietf-plantsmerkle-tree-certs-05 Merkle Tree Certificates PLANTS WG 文書 標準文書は2026年11 月目標 draft-ietf-tlstrust-anchor-ids-05 Trust Anchor Identifiers TLS WG 文書 Chrome は M152 で 既定 ON draft-reddy-tlscomposite-mldsa-12 Use of Composite ML-DSA in TLS 1.3 個人ドラフトのまま 採択の呼びかけなし RFC 8446 を廃止 2026年9月22〜23日 時点。タイトルは rfc-editor.org および datatracker.ietf.org の記載どおり。X.509 側は RFC 9881（ML-DSA）/ 9909（SLH-DSA）/ 9935（ML-KEM） 22
25. 自分の環境を確かめる 付録 C # 手元の OpenSSL が対応しているか（3.5.0 以上が必要） $ openssl version $ openssl list -tls-groups | tr ':' '\n' | grep -i mlkem # サーバが対応しているか $ openssl s_client -connect example.com:443 -servername example.com \ -tls1_3 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group" # 中身まで見る（key_share のバイト数が出る） $ openssl s_client -connect example.com:443 -servername example.com \ -tls1_3 -groups X25519MLKEM768 -trace </dev/null 2>&1 \ | grep -A3 "extension_type=key_share" ブラウザで見る Chrome DevTools → Security タブ → Key Exchange Group テストサイト pq.cloudflareresearch.com 普及率を見る radar.cloudflare.com/post-quantum 自分の実装が壊れていないか tldr.fail 23
26. 言語・ミドルウェアの対応 付録 D 時期 内容 OpenSSL 3.5.0（LTS・2030年4月まで） 2025年4月 既定の keyshare が X25519MLKEM768 + X25519 Go 1.24 2025年2月 crypto/mlkem。未設定なら既定で有効 Go 1.27 2026年8月 crypto/mldsa。TLS 1.3 で ML-DSA 署名に対応 Node.js 24.7.0 2025年9月 crypto.encapsulate / decapsulate（ML-KEM） JDK 24 2025年3月 JEP 496 / 497 で ML-KEM・ML-DSA を JCA に JDK 27（JEP 527） — rustls 0.23.22 以降 — TLS 1.3 のハイブリッド鍵交換。 X25519MLKEM768 が既定 prefer-post-quantum feature で最優先 nginx — OpenSSL 3.5 以上とリンクしていれば既定で有効 OpenSSH 10.0 / 10.1 2025年4月 / 10月 既定化、そして非 PQ での警告表示 OpenSSL 3.5 を同梱するディストリは Debian 13 / Alpine 3.22 / RHEL系 10.1 / SLES 16 など。 ライブラリが対応していることと、手元のディストリに載っていることは別。 24
27. 外から来ている期限 付録 E 米 大統領令 EO 14412 2026年6月署名 連邦の重要システム: 鍵確立 2030年12月末 / 署名 2031年12月末。契約者も 2030年 末 NIST IR 8547 まだドラフト RSA・ECDSA は 112bit が 2030年以降 Deprecated、128bit 以上が 2035年以降 Disallowed EU 2025年6月 2026年末までに全加盟国が着手 / 2030年末までに重要インフラ / 2035年までに全シ ステム 英 NCSC 2025年3月 2028年 棚卸しと計画 / 2031年 優先度の高い移行 / 2035年 完了 NSA CNSA 2.0 — Web ブラウザ・サーバ・クラウドは 2025年に support&prefer、2033年に exclusively use 日本 CRYPTREC 2026年3月30日 ML-KEM を電子政府推奨暗号リストに追加 日本 内閣官房 2025年11月 原則として2035年までを目指し、2026年度に工程表を策定 「2030年に RSA が禁止される」は誤り。2030年は 112bit 相当の Deprecated（＝使ってよいがリスクは自己判断）。 25
28. NIST と CNSA 2.0 は、目指すものが違う 付録 F NIST は格子が崩れたときの予備まで揃える。NSA は NSS 向けに、汎用の方式を1つずつに絞る。 NIST ― 選択肢を揃える NSA CNSA 2.0 ― 絞って義務にする 対象: NSS 以外の政府システム 格子の予備: SLH-DSA（ハッシュ）／ HQC（符号） パラメータ: 3段階（ML-KEM-512 / 768 / 1024 など） 対象: 国家安全保障システム（NSS）だけ。他には求めない 前提: 長期の保護。戦時も想定した、資源の豊富な攻撃者 パラメータ: 最大のみ（ML-KEM-1024 / ML-DSA-87） NIST にあって CNSA 2.0 にないもの ― NSA 自身の説明 SLH-DSA NSS では用途を問わず非承認（"not approved for any use in NSS"）。外した理由は FAQ に書かれていない FN-DSA 実装ミスを起こしやすく、安全性に響くおそれ。ML-DSA を優先する点は NIST と同意見。FIPS 206 が出ても追加 しない見込み 今後の NIST 標準 （HQC など） 追加の予定はない。アルゴリズムを増やすほど相互運用が複雑になるため。（FAQ は HQC 選定の約3か月前の文書 で、HQC を名指ししてはいない） LMS / XMSS （CNSA 側の別枠） ソフトウェア・ファームウェア署名に限った枠（NIST SP 800-208）。ファームの検証処理は製品の寿命まで変え にくく急ぐうえ、先に標準化され検証済み実装もあった ML-KEM-768 は NIST 標準だが、CNSA 2.0 には準拠しない 出典: NSA "The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ" Ver. 2.1（2024-12、PP-24-4014）／ NSA "Announcing the Commercial National Security Algorithm Suite 2.0"（2022-09）。2026-09-27 確認 26
29. 出典（1/2） 標準・仕様 RFC 10024 Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 付録 G 2026-08 https://www.rfc-editor.org/rfc/rfc10024.html RFC 9954 Hybrid Key Exchange in TLS 1.3 2026-07 https://www.rfc-editor.org/rfc/rfc9954.html RFC 10042 Post-Quantum Traditional Hybrid Key Exchange in SSH 2026-08 https://www.rfc-editor.org/rfc/rfc10042.html RFC 9846 The Transport Layer Security (TLS) Protocol Version 1.3 2026-07 https://www.rfc-editor.org/rfc/rfc9846.html RFC 9958 Post-Quantum Cryptography for Engineers 2026-06 https://www.rfc-editor.org/rfc/rfc9958.html FIPS 204 Module-Lattice-Based Digital Signature Standard 2024-08-13 https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf FIPS 205 Stateless Hash-Based Digital Signature Standard 2024-08-13 https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf I-D Merkle Tree Certificates (draft-ietf-plants-merkle-tree-certs-05) 2026-07-06 https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/ I-D Post-Quantum Cryptography Recommendations for TLS-based Applications (draft-ietf-uta-pqc-app-03) 2026-07-04 https://datatracker.ietf.org/doc/draft-ietf-uta-pqc-app/ IANA TLS Supported Groups レジストリ 随時更新 https://www.iana.org/assignments/tls-parameters/ 27
30. 出典（2/2） 実測・制度 Cloudflare State of the post-quantum Internet in 2025 付録 G 2025-10-28 https://blog.cloudflare.com/pq-2025/ Cloudflare Keeping the Internet fast and secure: introducing Merkle Tree Certificates 2025-10-28 https://blog.cloudflare.com/bootstrap-mtc/ Cloudflare Automatic Key Exchange for origins 2026-09-08 https://blog.cloudflare.com/automatic-key-exchange-for-origins/ ISRG A Post-Quantum Future for Let's Encrypt 2026-06-03 https://letsencrypt.org/2026/06/03/pq-certs Chromium Advancing Our Amazing Bet on Asymmetric Cryptography 2024-05-23 https://blog.google/chromium/advancing-our-amazing-bet-on-asymmetric/ D. Adrian ほか tldr.fail — ClientHello が分割されると壊れる実装の一覧 随時更新 https://tldr.fail/ Dubey & Varshney Measurement Study of Post-Quantum Readiness of Internet: 2026 2026-06-15 https://arxiv.org/abs/2606.16473 Mozilla Bug 1967998 — SMTP sending fails with Office 365 on Thunderbird 138-142 — https://bugzilla.mozilla.org/show_bug.cgi?id=1967998 28
31. 出典（3/3） 制度・機関 IETF 126 Proceedings 付録 G PLANTS / MLS / TLS / SAAG の各スライドと議事録（2026-07） https://datatracker.ietf.org/meeting/126/proceedings CA/Browser Forum SC-106: Enable Post-Quantum Cryptography (PQ) Key Pairs in TLS Server Certificates（2026-08-26 提出、Draft） https://github.com/cabforum/servercert/pull/679 IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication (pqws)（2026-10-11/12 プラハ） https://datatracker.ietf.org/group/pqws/about/ Google Cultivating a robust and efficient quantum-safe HTTPS（2026-02-27） https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html Chrome Enterprise Chrome 150 リリースノート（ML-DSA は local trust anchor 限定） https://support.google.com/chrome/a/answer/10314655 CRYPTREC 電子政府における調達のために参照すべき暗号のリスト LS-0001-2022R2（最終更新 2026-03-30） https://www.cryptrec.go.jp/list.html ICCS（中国） 新一代商用密码算法征集活动 第1ラウンド候補（2026-09-20） https://www.niccs.org.cn/niccs/Notice/pc/content/content_2100875480644800512.html NIST Post-Quantum Cryptography Standardization（HQC 選定・追加署名第3ラウンド） https://csrc.nist.gov/projects/post-quantum-cryptography NSA The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ Ver. 2.1（2024-12） https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF 数値はすべて一次資料で確認し、値・単位・出典・確認日を記録しています。二次情報しか得られなかったものは、本文中でその旨を明記しました。確認日は 2026年9月21日〜23日（付録 F のみ 27日）です。 29