まこ

先に全体像をいうと、鍵共有はすでに決着、サーバ証明書は公開WebでMTCへ向かい、署名はレイヤと寿命で棲み分け、passkeyはML-DSAで実現できる(当面はコンポジット併用)、という流れです。順に見ていきます。 1. 鍵共有：ML-KEMハイブリッドで実質確定 ここはおっしゃるとおりです。TLS 1.3 では X25519MLKEM768、つまり現行暗号の X25519 と ML-KEM-768 を組み合わせたハイブリッドが事実上のデファクトになっていて、主要ブラウザと CDN で既に本番に乗っています。鍵共有については決着済みという認識で問題ありません。ハイブリッドにしているのは、ML-KEM 単体の実装と解析が枯れるのを待つ保険と、現行暗号側の実績ある安全性を同時に確保するためです。 2. サーバ証明書：公開Web PKIではMTCが本命 公開Web向けのTLSサーバ証明書については、MTC(Merkle Tree Certificates)が現状もっとも有力です。もともとは Google と Cloudflare の個人ドラフトでしたが、IETF に PLANTS WG(PKI, Logs, And Tree Signatures)が新設され、いまは draft-ietf-plants-merkle-tree-certs として標準化が進んでいます。エコシステムの足並みもそろってきていて、Chrome が公開WebのPQC証明書の本命と位置づけ、Cloudflare と Google が実トラフィックで実験し、DigiCert が Playground を公開、そして Let’s Encrypt が2026年6月に MTC 採用を表明しました(ステージング2026年後半、本番2027年目標)。発行量で過半を占める Let’s Encrypt が乗ったことで、Webの大半でこれが現実解になりつつあります。 ただし万能の置き換えではない点は押さえておきたいところです。MTC はブラウザのルートストア更新と landmark(部分木)の事前配布を前提にした、公開Web向けに最適化された仕組みです。社内PKIやmTLS、IoT、長期のオフライン検証といった世界では、引き続き ML-DSA 署名の X.509(LAMPS の ML-DSA 証明書プロファイル、移行期はコンポジット署名)が主役になるはずです。「公開WebはMTC、それ以外はML-DSA X.509」という棲み分けが現実的だと見ています。 3. 検証・CTログ・PKIへの影響：かなり変わります ここが本質的なところです。MTC の肝は、これまで別々だった「CAの署名」と「Certificate Transparency(CT)」を発行プロセスに統合してしまう点にあります。CA が Merkle 木のルート(ひとつの署名)で大量の証明書をまとめて担保し、個々の証明書は署名ではなく包含証明(inclusion proof)で示す、という構造です。signatureless 版では、最新状態の検証者に対しては包含証明(数百バイト規模で、ML-DSA 署名1本より小さい)だけで済むので、PQC署名の肥大化をほぼ回避できます。 その裏返しとして、従来型の SCT(CTログの署名付きタイムスタンプ)を積み増す必要がなくなる一方で、ルートストアと landmark の定期配布や、ACME とCA運用の手順変更が必要になります。検証者が landmark を最新化していないケースに備えて、standalone(フォールバック)形式も用意されています。要するに、CT と PKI の運用モデルそのものが組み直される、という理解で合っています。 4. 署名の棲み分け：レイヤと寿命・保証要件で分かれる 「トラフィックにセンシティブなTLS系」対「ドキュメント署名」という見立ては当たっていますが、もう一段分解すると見通しがよくなります。 まずTLSのハンドシェイク署名(CertificateVerify)は、1ハンドシェイクに1本なので ML-DSA でも許容範囲です。サイズ問題の主因は証明書チェーンと CT のほうにあって、そこを MTC が引き受ける、という分担になっています。つまりTLSは「ML-DSAを避ける」のではなく、「認証署名は ML-DSA、証明書層は MTC」という組み合わせで解く、という整理です。 一方ドキュメントやコードの署名は ML-DSA が基本線です。ただしファームウェアや長期保管、高保証が要る用途では、保守的なハッシュベース署名(SP 800-208 の LMS/XMSS、あるいは SLH-DSA)が推奨される場面が残ります。署名サイズは大きくなりますが、レイテンシに効かない用途なので許容できるからです。実際 NSA は、ソフトウェアやファームウェアの更新署名について、ほかの認証移行に先行して LMS/XMSS を採用するよう勧めています。 まとめると、署名アルゴリズムの選択は「TLSか文書か」だけでは決まらず、レイテンシ・寿命・保証要件の3つの軸で棲み分けます。ML-DSA を軸に、長期・高保証はハッシュベースを併用し、TLSの証明書層は MTC が受け持つ、という形です。 5に関しては返信欄へ