原題: A Post-Quantum Future for Let’s Encrypt
著者: Andrew Gabbitas
公開日: 2026年6月3日
ソースURL: A Post-Quantum Future for Let’s Encrypt
アーカイブ日: 2026-06-04
Let’s Encryptが、ポスト量子時代のWeb PKI（公開鍵基盤）に対する自らの計画を公式ブログで発表した。その核心はMerkle Tree Certificates（MTCs）と呼ばれる新しい証明書方式であり、従来のTLSハンドシェイクの速度と信頼性を犠牲にすることなく、耐量子認証を実現するという。
なぜ今なのか。 ここ数年のポスト量子暗号の議論はもっぱら暗号化（encryption）についてだった。攻撃者が今日の暗号化通信を記録しておき、将来の量子コンピュータで解読するという「蓄えて後で解く（harvest now, decrypt later）」脅威が最優先課題とされてきた。認証（authentication）については、量子コンピュータがリアルタイムで署名を偽造する必要があるため、CRQC（暗号学的に関連する量子コンピュータ）の実現を待たねばならず、緊急性は低いと見なされていた。しかし、この認識は急速に変わりつつある。
米国NSAのCNSA 2.0スイートは2022年以降、国家セキュリティシステムに2030〜2035年のスケジュールで耐量子アルゴリズムへの移行を指示している。NISTの移行ガイダンス草案は、RSA-2048とP-256を2030年以降に非推奨、2035年以降に禁止する方針だ。EUのロードマップも、ハイリスクシステムについては2030年末、広範な移行については2035年までを目標とする。これらの義務はパブリックWeb PKIを直接拘束するものではないが、エコシステム全体が依存するベンダー、ライブラリ、標準化団体がすでに動き出している。
そして本年、タイムラインはさらに短縮された。Googleは2029年までの自社サービスの移行を発表し、その理由としてCRQC到来時期の見積もりが厳しくなったことを挙げている。Cloudflareも同様のコミットメントを発表した。Go 1.27がNIST標準の耐量子署名方式ML-DSAを標準ライブラリに追加したことも、耐量子署名が実用的なインフラになりつつあることを示している。
Web PKI固有の難しさ。 パブリックWeb PKIは、耐量子署名を導入するには極めて難しい領域である。その理由はサイズにある。NIST標準化された耐量子署名のうち比較的小さいML-DSA-44でさえ、署名サイズは約2,420バイト。現在使われているRSA-2048が256バイト、ECDSA-P256が64バイトであるのと比較すると桁違いだ。公開鍵も同様で、ML-DSA-44が1,312バイトに対し、RSA-2048が256バイト、ECDSA-P256が64バイトである。今日の典型的なWeb PKIのTLSハンドシェイクは5つの署名と2つの公開鍵を運んでいる。これをML-DSAに置き換えると、単一のTLSハンドシェイクが10キロバイトを優に超える。Cloudflareの研究によれば、この規模になると現実のネットワークでTLS接続のうち無視できない割合が失敗し、成功するものも遅くなる。まだ現実化していない脅威のために、すべてのTLS接続にこれだけのコストを課すのは引き受け難い。
Merkle Tree Certificates（MTCs）。 この問題に対するLet’s Encryptの答えがMTCsである。MTCでは、認証局は証明書を1枚ずつ個別に署名するのではなく、バッチ単位で発行し、1つの署名でバッチ全体をカバーする。ブラウザはこれらのバッチ署名（「ランドマーク」と呼ばれる）をTLSハンドシェイクとは別に最新に保つ。通常時のMTCハンドシェイクが運ぶのは、1つの署名、1つの公開鍵、1つの包含証明のみであり、これは耐量子アルゴリズムを使いながらも今日のWeb PKIハンドシェイクよりも小さい。
MTCの利点はサイズ最適化だけではない。すべての証明書が公開マークル木の一部となるため、透明性（transparency）が発行自体の属性になる。今日のCertificate Transparency（CT）は事後的に付け加えられた仕組みであり、CAが発行した証明書を別途ログに記録し、TLSハンドシェイクに追加の署名を載せてログへの記録を証明している。MTCでは、証明書がマークル木の外に存在することは原理的にできない。CTが組み込まれているのだ。Let’s Encryptは2019年からCTログを運用しており、マークル木という同じデータ構造を本番環境で長年にわたり大規模運用してきた実績を持つ。
CloudflareとChromeはすでにMTCの実現可能性実験を実際のインターネットトラフィックに対して開始している。IETFのPLANTSワーキンググループが標準化を進めており、ChromeはMTCをパブリックWebへの耐量子証明書追加の優先経路として公表している。
Let’s Encryptの具体的計画。 Let’s Encryptは2026年後半を目標にMTC発行のステージング環境を立ち上げ、2027年に本番環境を提供する計画である。これは大規模な工事であり、発行インフラ、ACMEプロトコル（証明書取得に使われる）、失効処理、運用ツール、そしてMTCに統合される透過性ログインフラに至るまで、スタック全体の変更が必要となる。同組織はすでにIETFのPLANTSおよびACMEワーキンググループに参加し、標準が形作られる過程に参画している。ML-DSA署名のX.509（RFC 9881）およびTLS（draft-ietf-tls-mldsa）の標準化も並行して追跡している。
今すぐ変わること、そして今すぐできること。 現時点では利用者に変更は一切ない。既存のLet’s Encrypt証明書はこれまで通り発行・更新される。耐量子証明書が利用可能になる際も、ACMEクライアントを持つ誰にでも無料で自動提供される。移行には時間がかかり、ブラウザ、ライブラリ、ACMEクライアント、ルートプログラムの要件定義などエコシステム全体での準備が必要である。
記事の末尾でGabbitasは重要な注意を促している。ポスト量子暗号化（encryption）の方がより緊急な問題であり、耐量子鍵交換なしのTLS接続はすべて後日解読される可能性がある。サーバ運用者はハイブリッド耐量子鍵交換（X25519MLKEM768）を確実に有効化すべきであり、これは今年可能な最大の効果を生む対策の一つであると述べている。
この記事が重要なのは、ポスト量子Web PKIという極めて複雑な移行問題に対して、具体的かつ実行可能な技術的選択肢を提示した点にある。特にML-DSA署名のサイズ問題を定量的に示した上で、MTCが「今日のハンドシェイクよりも小さい」という逆転の設計を可能にする理由を明確に説明している。耐量子暗号というと鍵サイズの増大は不可避のトレードオフと捉えられがちだが、アーキテクチャの変更によってこれを克服しようとする発想は示唆に富む。
また、Certificate Transparencyが「後付け」から「組み込み」へと進化する点も見逃せない。証明書がマークル木の外に存在できないという性質は、監査可能性の質的な飛躍を意味する。CTの運用を2019年から続けてきたLet’s Encryptだからこそ、このアプローチの実現可能性を説得力を持って語ることができる。
タイムラインに関しては、2026年後半のステージングと2027年の本番というスケジュールは意欲的だが、標準化の進捗とエコシステムの準備状況を考慮すると妥当なラインといえる。ACMEクライアントの保守者に対して今から準備を促す呼びかけは実務的な助言であり、エコシステム全体で移行を進めるためには不可欠な協力の呼びかけである。
ポスト量子Web PKIの移行は、HTTPからHTTPSへの移行（Let’s Encrypt自身が主導した）に匹敵する規模のインフラ転換になるだろう。その中心でLet’s EncryptがMTCという具体的なビジョンを掲げたことの意義は大きく、今後の標準化と実装の進展を追いかけていく価値がある。