要約

  • IESGは2026年9月10日、異議申立てを退け、公開保留を解除し、draft-ietf-tls-mldsa-05の承認通知を出した。この文書はFIPS 204のML-DSA署名をTLS 1.3の認証に用いる方法を定める。想定するRFC種別はInformationalで、確認時点ではRFC番号のないInternet-Draftだった。
  • IANAのTLS SignatureSchemeレジストリには、mldsa44、mldsa65、mldsa87が0x0904、0x0905、0x0906として掲載され、いずれもRecommended: Nである。RFC 9847におけるNは、IETFが適合性を表明していないか合意がない状態であり、非推奨を示すDではない。
  • 文書公開の承認、相互運用できる値の割当て、導入推奨は別々の行為だ。異議申立ての棄却は公開手続をめぐる争いを終えたのであって、純粋方式と複合方式のどちらを全組織が使うかを決めたのではない。
  • 導入者は、対象となるTLS用途、選択したパラメータと方式、相手と証明書の範囲、検証日、失敗条件、ロールバック責任者、再審日を記した固有の判断票を残すべきだ。

公開できるという合意

Datatrackerの履歴を見ると、承認と公開には間がある。IESGは7月8日に文書を承認したが、同日に異議申立ての審査に入ったため保留した。9月10日に申立てを退け、保留を解除し、承認通知を改めて送った。公式通知はTLSワーキンググループの成果で、Informational RFCとして公開する予定だと説明する。

経緯には意見の相違も残っている。シェパードの要約は、約275通のメッセージがあり、前進を支持する比率をおよそ4対1とした。純粋なML-DSAを公開すべきでない、複合署名を推奨すべきだ、双方を並行して公開すべきだという立場があった。IESGの回答は、Working Group Last Callの反応を検討し、広い支持があり、反対意見も考慮され議論されたと判断した。申立ては棄却され、Security Area DirectorのDeb Cooleyはこの判断に加わっていない。

この決定の対象は、異論が残る中でも文書を公開できるかどうかだ。約4対1という記録は、実運用の選好を問う投票ではない。申立てを退けたことも、暗号上の懸念を無効にする証明ではない。rough consensusは仕様作業の前進を可能にするが、個々のサービスが受け入れる損失や相手環境までは引き受けない。

現在形にも注意が要る。文書ページはApproved-announcement sentを示す一方、05版を有効なInternet-Draftとしている。IANAレビューはVersion Changed - Review Needed、アクションはIn Progressだ。RFC番号はまだない。承認済みの将来のRFCと、発行済みのRFCを混同してはならない。

三つの値がそろえるもの

FIPS 204は耐量子デジタル署名ML-DSAを標準化した。今回の文書は、移行政策全体ではなく、TLS 1.3認証で三つのパラメータセットをどう交渉するかを定める。ML-DSA-44はmldsa44と0x0904、ML-DSA-65はmldsa65と0x0905、ML-DSA-87はmldsa87と0x0906に対応する。

RFC 9881には、X.509で使う三つのAlgorithmIdentifierがある。TLS文書はそれをSignatureSchemeと結び付ける。CertificateVerifyで用いる場合、FIPS 204に従い空のctxで署名・検証し、エンドエンティティ証明書には対応するAlgorithmIdentifierが必要だ。HashML-DSAの事前ハッシュ型は対象外である。

この定義があることで、別々の実装が同じ値と証明書表現を理解できる。だが、認証局が必要な証明書を発行すること、クライアントがチェーンを受け入れること、鍵を扱うハードウェアが安全であること、混在するフリートで撤回できることまでは立証しない。通信形式の一致は導入条件の一部にすぎない。

IANAの現行レジストリには三行があり、すべてNだ。参照先はまだ古いドラフト版で、DatatrackerではIANA処理が継続中になっている。したがって、「値は割当て済みで公開されている」と「発行作業がすべて完了した」を分ける必要がある。

Nを「不承認」と訳してはいけない

RFC 9847の推奨欄は二択ではない。Yは、定義された目的に適しているとIETFが合意し推奨する状態で、適用条件の確認はなお必要だ。Dは、理由を明示して非推奨とする状態である。Nは、IETFが適合性を評価・表明していない、合意がない、または用途が限定される状態を示す。

同RFCは、Nだからといって方式に欠陥があるとは限らないと明記する。値の割当ては導入の青信号ではなく、Nも赤信号ではない。相互運用のために名称を確保しながら、一般推奨が存在しないことを正確に保持する欄である。

番号を承認とみなせば、レジストリ運営が意図せずセキュリティ審査になる。Nを拒絶とみなせば、限定的な試験まで制度上否定されたように見える。どちらも、共有レイヤーが実際に下した判断より大きな権限を与えてしまう。

純粋方式と複合方式は同じ段階にない

承認文書は純粋なML-DSAを扱う。別に、TLS 1.3でML-DSAと従来署名を組み合わせる有効な個人Internet-Draftがある。Datatrackerは、この個人ドラフトにはIETFストリームの支持がないと表示する。代替設計が具体的に存在する証拠ではあるが、同格の制度的推奨ではない。

純粋方式は二つ目の署名を検証する負担がない代わりに、ML-DSAとその実装へ保証を集中させる。複合方式は新方式に不具合が起きた際に従来要素を残せる一方、証明書とメッセージの大型化、計算、設定、相互運用の失敗点を増やす。どちらを選ぶかは、保護する対象と相手の集合によって変わる。

承認通知にある実装名も、同じ粒度で読むべきだ。OpenSSL、BoringSSL、rustls-post-quantum、s2n-tls、wolfSSL、Bouncy Castle、GnuTLSにコードがあることは実装証拠である。既定有効化、本番トラフィック、利用可能な証明書チェーン、共通設定、許容性能、撤回試験の証拠ではない。

導入判断票に必要な項目

最初に「耐量子対応」という広い言葉を捨て、TLSのどの面を対象にするかを書く。サーバー認証かクライアント認証か、限定された私設サービスか公開試験か。ML-DSAのパラメータと、純粋方式か複合方式かも明記する。

次に相手の集合を定める。発行者、証明書プロファイル、エンドポイント、クライアント、ライブラリ、鍵のハードウェア境界を列挙する。相手が新しい値を提示しない場合、拒否するのか、別チェーンへ切り替えるのか、許可した従来方式へ戻るのか。観測できないフォールバックは、接続を保ちながら目的の保証を失わせる。

試験結果には日付が要る。同じライブラリの二つのビルドだけでなく、異なる実装間で接続する。現実的な同時接続下で、ハンドシェイクサイズ、CPU、遅延を測る。鍵生成、署名、検証、乱数または決定論的モード、実装の漏えいを実際の境界で確認し、証明書の発行からチェーン検証まで通す。

最後に、範囲を広げる人、停止できる人、ロールバックを起動する観測値、配布済みの鍵と証明書を退役させる方法、証拠の期限、次回判断日を置く。これはIETFの結論を上書きする文書ではない。IETFが一組織に代わっては決められない部分を埋める文書だ。

証拠の限界

引用資料は、三方式の既定有効化や一般的な本番利用を示さない。純粋方式と複合方式の普遍的な優劣も決めない。異議申立てへの回答は手続判断であり、暗号学的証明ではない。NISTの標準化は特定TLS環境の導入評価ではない。IANAの値が見えることも、全発行工程の終了を意味しない。

確認できるのは、IETFがTLS 1.3で三つのML-DSAパラメータを相互運用可能に記述する文書の公開を承認し、レジストリの推奨状態がNのままということだ。次の判断と証拠は導入者に属する。

出典

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Use of ML-DSA in TLS 1.3 承認通知
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — 文書履歴
  7. IESG — 異議申立てへの回答、資料320
  8. IANA — TLSパラメータ
  9. RFC 9847 — TLS・DTLS向けIANAレジストリ更新
  10. NIST — FIPS 204、ML-DSA標準
  11. RFC 9881 — ML-DSAのアルゴリズム識別子
  12. RFC 9846 — TLS 1.3プロトコル
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3