耐量子署名と公開 TLS 証明書：実用化の準備状況を個別に確認する

概要

2026年10月25日時点の情報である。NIST は2024年8月13日、ML-DSA を規定する FIPS 204 と、SLH-DSA を規定する FIPS 205 を公開した。これらはデジタル署名の標準である。証明書の変更を計画する前に、NIST の正誤情報、IETF での公開状況、適用される CA/Browser Forum の要件を再確認する。FIPS 204 の案内ページには、2026年7月31日付で、軽微な問題を将来修正する予定についての注記が掲載されている。

アルゴリズムの標準化、証明書のエンコーディング、TLS 認証、公的な信頼基盤での受け入れは、それぞれ別の節目である。耐量子鍵交換を使っても、既存の証明書の公開鍵や発行者の署名が耐量子署名になるわけではない。

重要な理由

X.509 に統合するための標準はすでに存在する。2025年10月公開の RFC 9881 は、証明書と証明書失効リストで ML-DSA を使用する際の規約を定めている。そのプロファイルは純粋な ML-DSA の方式を対象とし、HashML-DSA は含めない。したがって、ML-DSA 証明書に関する作業がすべて未公開の提案段階にあるという主張は誤りである。

TLS への統合は、これとは別の進捗状況にある。IETF のトラッカーでは、2026年9月11日付の draft-ietf-tls-mldsa-06 が、RFC Editor のキューにある作業中の文書として掲載されている。トラッカーの最終更新日は2026年10月12日である。これは、TLS の RFC がすでに公開されたこととは異なる。

通常の、パブリックに信頼される TLS 証明書については、2026年10月4日付の CA/Browser Forum の Baseline Requirements バージョン 2.3.1 が、依然として関連するエンコーディングを従来型アルゴリズムに制限している。セクション 7.1.3.1 はサブジェクト公開鍵に RSA と ECDSA を認め、セクション 7.1.3.2 は従来型の署名エンコーディングを規定する。どちらも ML-DSA または SLH-DSA の発行プロファイルを提供していない。これが、この枠組みで従来型の証明書が引き続き必要な理由である。ただし、すべての CA、実験的な信頼システム、プライベート PKI を調査した結果ではない。

適用方法

• 鍵合意、証明書のサブジェクト公開鍵、発行者の署名、ハンドシェイク認証をそれぞれ追跡する。接続全体に付いた耐量子という1つのラベルだけで判断せず、各主張に根拠を求める。
• ML-DSA 証明書の実験では、正確なアルゴリズムの方式と証明書プロファイルを特定する。RFC 9881 はエンコーディングの基礎を提供するが、それだけで公開ルートプログラムやすべてのクライアントが受け入れると確認できるわけではない。
• 公開環境へのデプロイ前に、最新の TLS Baseline Requirements、関連する CA ポリシー、対象クライアントの信頼ポリシーを確認する。承認されたアルゴリズム変更と発効日を追跡する。ドラフトやアルゴリズム識別子の割り当てだけでは、デプロイの準備が整ったとは判断できない。
• プライベート PKI の試験と、公開証明書の発行に関する前提を分ける。実際に使うソフトウェアについて、チェーン検証、認証、更新、失効、相互運用性の結果を記録する。公開 TLS の Baseline Requirements は、企業内だけで使う PKI を明示的に対象外としている。
• FIPS 204 の修正、FIPS 205 の公開ページ、RFC の正誤情報、TLS ワーキンググループの文書の状況を追跡する。仕様が発表されただけの時点ではなく、デプロイ済み環境の動作が変わったときに台帳を更新する。

落とし穴

鍵交換への対応から署名への対応を推測したり、ライブラリのアルゴリズム一覧をブラウザーが信頼する証拠とみなしたりしてはならない。同様に、SLH-DSA が NIST で標準化されたことだけでは、公開 TLS 証明書のプロファイルは確立されない。ここでは、全ブラウザー共通の展開日、CA の移行期限、実験的デプロイの普及範囲について主張していない。それらには、個別に最新の一次資料が必要である。