PQ証明書がまだ来ない理由 — ML-DSA署名サイズ、10kBの壁、そしてMerkle Tree Certificates

はじめに — 暗号化は半分まで来た、認証はまだスタートライン
問題はすべてサイズだ — FIPS 204が定める数字
なぜハンドシェイクに署名が5個も入っているのか
10kBの壁 — 2021年Cloudflareの測定
Merkle Tree Certificates — 署名をまるごと取り除く設計
736バイトという数字に付いた条件
今どこまで来ているか — PLANTS、Chrome、Let's Encrypt
このアプローチへの反論と残る穴
では今すぐ何をすべきか
おわりに
参考資料

はじめに — 暗号化は半分まで来た、認証はまだスタートライン

ここ数年、ポスト量子暗号(PQC)の話は事実上鍵交換の話でした。論理は単純です — 今やり取りされている暗号文をそのまま保存しておき、のちに量子コンピュータで解読する攻撃、いわゆるharvest now, decrypt later(HNDL)が可能なので、暗号化は今すぐ変えなければならない、というものでした。だからハイブリッド鍵交換であるX25519MLKEM768がブラウザとサーバーに急速に広まりました。Cloudflareは2025年10月時点で、自社のエッジネットワークに入ってくるトラフィックの約50%がこの脅威から保護されていると述べています(ベンダー自己測定 — 母集団はCloudflareのエッジに到達したトラフィックであり、インターネット全体ではありません)。

認証(authentication)は事情が異なります。署名の偽造は保存しておいて後でできることではなく、接続が生きているその瞬間に成し遂げなければなりません。だから署名はHNDLの対象ではなく、脅威は実際に暗号学的に意味のある量子コンピュータ(CRQC)が存在するかどうかにかかっています。Let's Encryptの言葉を借りれば、その事実がこれまで認証側を先送りにできる「慰め」でした。

しかし本当の理由は別にあります。PQ証明書をそのまま置き換えると、Webは遅くなります。それも、まだ来ていない脅威に備える代償として、今すぐ遅くなるのです。本稿はそのトレードオフの数字を一次資料で確認し、業界がその代償を避けるために選んだ迂回策が何かを見ていきます。

問題はすべてサイズだ — FIPS 204が定める数字

まず数字を押さえておきます。NIST FIPS 204のTable 2が、ML-DSAの鍵・署名サイズをバイト単位で規定しています。

パラメータセット   秘密鍵    公開鍵    署名        (FIPS 204 Table 2)
ML-DSA-44        2560     1312     2420        セキュリティ強度カテゴリ2
ML-DSA-65        4032     1952     3309        セキュリティ強度カテゴリ3
ML-DSA-87        4896     2592     4627        セキュリティ強度カテゴリ5

比較対象はこうです。今日のWebで最も一般的な署名であるECDSA P-256は署名64バイト、公開鍵64バイトです。RSA-2048は署名256バイト、公開鍵256バイトです。Ed25519は鍵32バイトに署名64バイトです(RFC 8032、MTCドラフトが引用する値)。

つまりML-DSA-44はECDSA P-256の約20倍です。Cloudflareはこれを「roughly a 20-fold increase in size」と表現しました。ここで重要なのは、ML-DSA-44が最小の選択肢だという点です。参考までに、ハッシュベースのSLH-DSA(FIPS 205、旧SPHINCS+)はCloudflareの測定基準で39kB増え、署名・検証の計算コストも大きくなります。その代わりハッシュだけに依拠するため安全性がはるかによく理解されているという利点があります — サイズと信頼度のトレードオフです。

なぜハンドシェイクに署名が5個も入っているのか

サイズが20倍というだけでは全体像はつかめません。核心はハンドシェイクが署名を何個運ぶかです。CloudflareのMerkle Tree Certificates紹介記事(2025年10月28日、Luke Valenta・Christopher Patton・Vânia Gonçalves・Bas Westerbaan)が、この階段を一段ずつ積み上げて見せてくれます。

クライアントがサーバーの公開鍵をすでに知っていれば、署名1個で十分です。しかしWeb上にはTLSサーバーが約10億台あり、鍵は絶えず変わります。すべてのクライアントにすべてのサーバーの公開鍵をあらかじめ埋め込んでおくのは不可能です。PKI設計の出発点はこの拡張性の問題です。
そこで証明書が登場します。CAが「この公開鍵はこのドメインのものだ」と署名します。署名+1、公開鍵+1 → 合計署名2個、公開鍵1個。
最近のチェーンは通常証明書2枚以上です。CAも鍵を交代させる必要があり、新しい公開鍵が数十億のクライアントの信頼ストアに広まるには時間がかかります。その空白を埋めるため、古い鍵で新しい鍵の証明書を発行し、チェーンの末尾に付け加えます。署名+1、公開鍵+1 → 署名3個、公開鍵2個。
最後にCertificate Transparencyです。Chrome・Safari・Firefoxは、証明書が信頼されたログ最低2箇所に載っていなければ受け入れません。ログごとにSCT署名が一つずつ付きます。署名+2 → 最終的に署名5個、公開鍵2個。

Cloudflareの表現がこの状況を正確に要約しています — WebPKIで何かを直すたびに署名を一つずつ積み増してきており、伝統的な暗号があまりに安価だったためにその戦略が通用してきた、というのです。今、その請求書が回ってきています。

FIPS 204のサイズとCloudflareが数えた個数を掛け合わせるとこうなります(以下は二つの一次資料を組み合わせた筆者自身の計算であり、どちらか一方が発表した測定値ではありません)。

ML-DSA-44にすべて置き換えた場合の認証データ:
  署名5個 x 2,420 =  12,100 バイト
  公開鍵2個 x 1,312 =  2,624 バイト
  ------------------------------------
  合計                 14,724 バイト

同じ個数をECDSA P-256で計算すると:
  署名5個 x 64 + 公開鍵2個 x 64 = 448 バイト
(実際のチェーンはRSAが混じるため、実戦値はこれより大きくなります)

MTCドラフト自体はもっと保守的な計算も示しています。draft-ietf-tls-trust-anchor-idsによって中間証明書を直接信頼させ、チェーンを短縮したとしても、SCT 2個とリーフ証明書署名1個だけで、ML-DSA-44基準で7,260バイト、ML-DSA-65基準で9,927バイトの認証オーバーヘッドが付くと書かれています。つまりチェーンを最大限に切り詰めても、1万バイト前後です。

10kBの壁 — 2021年Cloudflareの測定

では、1万数千バイトがなぜ問題なのでしょうか。ここからは理論ではなく測定です。Cloudflareが2021年11月8日に公開したSizing Up Post-Quantum Signatures(Bas Westerbaan)は、実際のインターネット上で自社ネットワークに入ってくる接続にダミー証明書を付け、サイズの影響を測定した大規模実験です。ベンダー自己測定であり、母集団はCloudflareのネットワークに到達した実際のクライアント接続です。

背景となる概念が一つ必要です。TCPは輻輳を避けるため、最初はパケットを少しだけ送ります — 通常10個、約14kBです。これが初期輻輳ウィンドウ(initcwnd)です。ここを超えると往復が一回余分に発生します。

測定結果は二つでした(Cloudflareが続編記事で自ら要約した内容に基づきます)。

失敗: 既存の証明書チェーンに10kBを超えて加えると、クライアントとミドルボックスの失敗率が急激に上がりました。グラフでは10kBと30kBで急上昇する区間が現れ、これはそのサイズに耐えられないクライアントやミドルボックスが存在することを意味します。
遅延: 9kB未満を加えたとき、TLSハンドシェイク時間が約15%遅くなりました。Cloudflareはこれを「耐えられるが、理想的ではない」と評価しました。

ここでよく誤解される点を一つ指摘しておきます。Cloudflare自身のinitcwndは標準値の10ではなく30パケットです。だから35kBを加えても初期輻輳ウィンドウの中に収まります。それでも中央値のハンドシェイクは40%遅く、遅い側の10%は60%多く時間がかかりました。Cloudflareの結論はこうです — 輻輳ウィンドウの中に収まるからといって、追加データがまったくタダになるわけではない。

具体的な代入もあります。Dilithium2(ML-DSA-44の前身)をドロップイン置換すると約17kB増えますが、Cloudflareの30パケットウィンドウでは中央値20%の低下でした。そして標準initcwnd 10では60〜80%の低下を見込むと書かれています — これは測定ではなくCloudflareの推定です。

ブラウザ側の基準線も参考になります。ChromeはTLSハンドシェイク時間の劣化上限を10%に設定しており、PQ鍵合意を展開する際にすでに4%の低下を経験したと報告しています — サーバーからクライアントへ1.1kB、クライアントからサーバーへ1.2kBが増えた代償です。Cloudflareは、この比率が自社の「9kBで15%」より比例的に大きいと指摘し、アップロードがダウンロードより遅いためかもしれないと解釈しています。

Cloudflareが2021年に下した実務的な結論は一文にまとめられます — 署名6個と公開鍵2個が9kB以内に収まれば移行が最も容易だろう、というものです。先ほど計算した14,724バイトはその目標をはるかに超えています。

一つ正直に付け加えると、この測定は2021年のものです。ミドルボックスもクライアントもその間に変わった可能性があり、Cloudflare自身もその後の記事でこのデータを引用し続けてはいますが、更新された大規模実測を新たに示してはいません。

Merkle Tree Certificates — 署名をまるごと取り除く設計

数字がこうなると、選択肢は三つです。(1)遅くなることを受け入れる、(2)Q-dayが近づくまで先延ばしする、(3)ハンドシェイクが運ぶ署名の個数そのものを減らす。

(2)は危険です。移行は常に予想より長くかかり、Cloudflareの表現では「火遊び」です。業界が選んだのは(3)です。

核心となる発想はこうです。証明書を一つずつ個別に署名するのではなく、バッチにまとめて、一本のツリーの頭(tree head)だけに署名する。各証明書はそのツリーの葉になり、内部ノードは子の集合のハッシュです。すると、ブラウザに送られる「証明書」は重い署名チェーンではなく、自分がそのツリーに含まれているという軽量な包含証明(inclusion proof)になります。Googleの表現をそのまま移すと、CAは数百万枚を代表する一本のツリーヘッドに署名し、ブラウザに渡る証明書はそのツリーに対する軽量な包含証明にすぎません。

用語はdraft-ietf-plants-merkle-tree-certs-05(2026年7月6日、100ページ — David Benjamin/Google、Devon O'Brien/Apple、Bas Westerbaan・Luke Valenta/Cloudflare、Filippo Valsorda/Geomys)の定義に従うのが正確です。

Cosignature: CAまたは他のcosignerがチェックポイントやサブツリーに対して行う署名。
Landmark: 信頼されたサブツリーをrelying partyにあらかじめ配布するために使う、飛び飛びのツリーサイズの部分集合。
Standalone certificate: あるサブツリーへの包含証明 + そのサブツリーに対するcosignature複数。
Landmark-relative certificate: landmarkサブツリーへの包含証明だけを持ち、署名が一つもない最適化された証明書。

最後の項目がこの設計の核心です。クライアントがlandmarkをあらかじめ知っていれば、サーバーは署名をまったく送らなくてもよいのです。

おまけがもう一つあります。Certificate Transparencyが設計に組み込まれます。今日のCTは後から継ぎ足された構造です — CAが発行し、別途ログに載せ、その事実を証言するSCT署名をハンドシェイクに乗せます。MTCでは、証明書がマークルツリーの外に存在することができません。Googleの表現では、公開ツリーに入れずに証明書を発行することは不可能です。だから今日のCTが与えるセキュリティ特性がデフォルトで付いてきて、ハンドシェイクに乗っていたSCTオーバーヘッドは消えます。

ドラフトはログ運用コスト側の利点も指摘します。ログエントリが公開鍵をハッシュに置き換え、署名を含まないため、ログエントリのサイズが公開鍵・署名のサイズに比例して大きくならなくなります。そして期限切れのエントリは古くなればpruningできるので、ログサイズはログの寿命ではなく保存ポリシーによって決まります。証明書の寿命が短くなる傾向と噛み合う部分です。

736バイトという数字に付いた条件

MTCを紹介する記事が好んで引用する数字が736バイトです。この数字の出典はGoogleやCloudflareのブログではなくドラフト6.5節Size Estimatesであり、条件が細かく付いています。条件を抜きにして引用すると誤解になります。

ドラフトが明示する仮定はこうです。

ログのハッシュ関数はSHA-256。
2025年6月9日時点の公開統計: Let's Encrypt単独CAの有効証明書約5億5,800万枚、MerkleTown基準でCTログの未失効証明書全体約21億枚、全CA発行率が時間あたり約44万4千枚。
短命証明書に移行したWebを仮定: 証明書寿命7日、サブスクライバーが寿命の75%時点で更新 → 126時間ごとに再発行 → CA一つあたり時間あたり約440万枚、全体で約1,700万枚。

この仮定の上で計算が出てきます。

landmarkを毎時1個割り当てる場合:
  サブツリーが約4,400,000枚を含む
  -> 包含証明ハッシュ23個
  -> 736バイト、署名なし

standalone証明書(チェックポイントを2秒ごとに打つ場合):
  サブツリーが約2,500枚を含む
  -> 包含証明ハッシュ12個 = 384バイト
  -> ここにrelying partyの要求を満たすだけの署名を追加で載せる必要がある

証明サイズは対数スケール:
  ハッシュ32個 = 1024バイトなら2^32(約43億)枚までカバー

ドラフト自身が付けている比較が印象的です — 736バイトはML-DSA-44署名たった1個(2,420バイト)よりも小さく、PQ SCTを含めるのに必要なML-DSA-44署名3個(7,260バイト)よりほぼ10倍小さいのです。ポスト量子アルゴリズムを使いながらも今日のハンドシェイクより小さくなるというLet's Encryptの主張は、ここから来ています。

ただし強調すべき点があります。これは測定ではなく、明示された仮定の上の推定値です。ドラフト自身も、現在のWeb PKIの発行率が短命証明書移行後のWebを代表していない可能性があると書き記しています。そして736バイトはlandmark-relative証明書、つまり最新状態のクライアントにのみ当てはまります。ドラフトの要約(abstract)の表現そのままに、この最適化は「最新状態のrelying partyにのみ適用され、それ以外はより古い証明書になる」という代償を払います。

今どこまで来ているか — PLANTS、Chrome、Let's Encrypt

この設計がスライドウェアではない根拠は、スケジュールとコードです。

IETF。PLANTSワーキンググループ(PKI, Logs, And Tree Signatures)が結成され、活動しています。憲章に書かれた目標は明確です — CT(RFC 6962、RFC 9162)を使うPKIにおいて、大きなポスト量子署名のコストを、TLS(RFC 8446)のような対話型プロトコルで削減すること。憲章はサイズが主な動機だとしつつ、成果物が伝統的な署名にも使えるようにすると述べています。WGドラフトは上で見た-05(2026年7月6日)まで来ています。

Chrome。Googleは2026年2月、Cultivating a robust and efficient quantum-safe HTTPSで方針を明確にしました。エコシステムの拡張性と効率のため、PQCを含む伝統的なX.509証明書をChrome Root Storeに追加する即時の計画はないというものです。代わりにMTCを推し進め、ロールアウトを3段階に設定しました。

フェーズ1(進行中): Cloudflareと共同のfeasibility study。この実験では、すべてのMTCベースの接続が伝統的な、信頼されたX.509証明書に裏付けられます。Googleが「fail safe」と呼ぶ仕組みで、ユーザー接続のセキュリティや安定性を賭けずに、実際の性能向上と発行の信頼性を測るためのものです。
フェーズ2(2027年第1四半期目標): 2026年2月1日より前にChromeで「usable」なログを一つ以上運用していたCTログ運用者を招待し、公開MTCインフラをブートストラップします。この段階の初頭で、新しい信頼ストアであるCQRS(Chrome Quantum-resistant Root Store)と、MTCのみをサポートするルートプログラムの要件を確定します。既存のChrome Root Programと並行運用し、サイトがダウングレード保護をopt-inできるようにします。
フェーズ3(2027年第3四半期目標): 追加のCAをCQRSにオンボーディングします。

Googleは、プライベートPKI(Chrome Root Storeに入らないPKI)向けには、量子耐性アルゴリズムを使う「伝統的な」X.509を今年中にサポートする見込みだと付け加えています。公開Webとプライベート PKIの経路が分かれるということです。

Cloudflare。実験の方式が巧妙です。まともなCAになるにはブラウザの信頼を得るのに何年もかかるため、Cloudflareはこの実験で本物のCAにはならず、MTCAの役割をmockします。Workers上でStaticCTログをベースにMTCAを動かしつつ、発行するMTCそれぞれについて、信頼されたCAが発行した既存の証明書を一緒に公開します。これをbootstrap certificateと呼びます。ChromeのインフラがMTCAのログを取得する際、このbootstrap証明書も一緒に取得して互いに一致するか確認し、一致したときだけlandmarkをChromeクライアントに配信します。要するにCloudflareは、(信頼されたCAがドメイン検証を行った)既存の証明書をMTCに「再エンコード」しているだけであり、ChromeはCTでCloudflareを牽制します。信頼関係を一切変えずに設計を実験する方法です。対象は測定に使える程度のトラフィックがある無料顧客の一部であり、ロールアウトの速度はChromeが管理します。

Let's Encrypt。2026年6月3日、Andrew Gabbitasが書いたA Post-Quantum Future for Let's Encryptで、MTCを経路として採用すると発表しました。目標は2026年末にMTCを発行するステージング環境、2027年にプロダクション対応環境です。Let's Encryptは、これが小さな仕事ではないと明確に書いています — 発行インフラ、サブスクライバーが使うACMEプロトコル、失効・運用ツール、そしてMTCが吸収してしまう透明性ログインフラまで、スタック全体を変える必要があります。根拠として挙げる資産は2019年から運用してきたCTログです。そのログがappend-onlyのマークルツリー、すなわちMTCと同じデータ構造だというのです。

周辺の標準と実装。ML-DSAをX.509で使う規約はRFC 9881(2025年10月、Standards Track)としてすでに出ており、TLS 1.3で使う側はdraft-ietf-tls-mldsa(2026年7月8日時点で-05)が進行中です。言語ランタイムも追随します — Goはcrypto/mldsaパッケージを新設し、FIPS 204のML-DSAを実装、crypto/x509がML-DSAの鍵と署名を、crypto/tlsがTLS 1.3でMLDSA44/MLDSA65/MLDSA87のSignatureSchemeをサポートします。ただしこれはGo 1.27のリリースノート基準であり、1.27はまだリリース前です(現在のstableは1.26.x)。Let's Encryptはこれを「ポスト量子署名が実用インフラになりつつある兆候」として挙げています。

このアプローチへの反論と残る穴

ここまで読むと、MTCはきれいな勝利のように見えます。正直に反対側も見てみましょう。興味深いことに、以下の反論の多くはCloudflare自身が自社の記事に書き記したものです。

「ハンドシェイク時間にこだわるのが正しいのか」というpushbackがあります。根拠は二つです。第一に、セッション再開(session resumption)を使えば、証明書を毎回送り直す必要はありません。第二に、典型的なWebサイト訪問が転送するデータ量は、PQ証明書が加える数kBを圧倒します。Cloudflareが直接引用する例が2024年のAmazon研究者によるシミュレーション論文で、典型的な接続は複数回リクエストを送り、数百kBを転送するため、そうした接続ではハンドシェイクの劣化は誤差の範囲に埋もれるという主張です。参考までに、Cloudflare自身もTLSハンドシェイクは、Webページが表示されるまでの長い連鎖のうち5〜20%程度を占める一段階にすぎないと書いています。

MTCの利益はクライアントが最新状態のときにしか出ません。Cloudflareが今回の実験で答えを得たいと思っている問いがまさにこれです — 「どれだけ多くのクライアントが最新状態を維持するのか?」 MTCの寿命は1週間程度と見込まれていますが、クライアントが持つ最新のlandmarkがそれより古ければ、サーバーはより大きな証明書にフォールバックしなければなりません。そのフォールバックがどれだけ頻繁に起きるかがプロトコルパラメータ調整の核心であり、まだ答えはありません。736バイトというバラ色の数字とstandaloneフォールバックとの実際の比率は、この実験が終わらなければ出てきません。

新しい信頼ストアはタダではありません。CQRSは既存のChrome Root Storeとは別の、MTCのみをサポートするルートプログラムです。技術的にはクリーンですが、エコシステムを二つに分け、CAに新しい編入経路を要求することでもあります。Google自身がこれを「risk-managed transition」と呼び、二つのトラックを並行運用すると表明していること自体、それだけ運用負担が大きいということでもあります。

スケジュールはすべて予測です。そして予測の根っこであるQ-dayは誰も知りません。ここは特に注意が必要です。Let's Encryptは「今年に入ってスケジュールが前倒しになった」と書き、GoogleがCRQC到来の推定を絞り込んでいることを根拠に、2029年までに自社サービスを移行すると発表し、Cloudflareがそれに続いたと記しています。これはそれらの企業の予測であり宣言であって、量子コンピュータが2029年に来るという事実ではありません。

規制のスケジュールも草案です。よく引用されるNISTの移行指針IR 8547は、2024年11月12日に公開された初期公開草案(Initial Public Draft)であり、意見募集は2025年1月10日に締め切られました。内容もよくある要約より込み入っています。草案の表は署名アルゴリズム群をセキュリティ強度で分け、112ビット強度(RSA-2048など)は2030年以降deprecated、2035年以降disallowed、128ビット以上は2035年以降disallowedと記しています。つまり「RSAとECCは2030年にすべて死ぬ」というような要約は、草案の表よりも粗いのです。そしてLet's Encryptが指摘するように、こうした指針は公開WebPKIを直接拘束するものではありません — ただし、WebPKIが依拠するベンダー・ライブラリ・標準化団体をその時計に合わせて動かす効果はあります。NSAのCNSA 2.0は2022年から国家安全保障システムに2030〜2035年のスケジュールを提示しており、EUのロードマップは高リスクシステム2030年末、広範な移行2035年を目標としています。

では今すぐ何をすべきか

本稿の実務的な結論は、少し拍子抜けするものです。今サーバー運用者がやるべきことは証明書ではなく鍵交換です。

Let's Encryptが記事の末尾に残した推奨がまさにそれです。広いインターネットコミュニティにとってより急を要する問題はポスト量子暗号化であり、PQ鍵交換のないTLS接続は、後で復号するために今すぐ収穫され得るからです。サーバーを運用しているなら、ハイブリッドPQ鍵交換(X25519MLKEM768)をサポートするようにしてください。主要なブラウザとOSはすでに対応しており、サーバー側でこれを有効にすることが今年できる中で最もレバレッジの大きい行動だというのが彼らの表現です。

証明書の側はまだ標準化が終わっていないので、今できることは三つです。

追跡。ACMEクライアントを保守している、あるいはACMEベースの証明書パイプラインを運用しているなら、PLANTSワーキンググループとmtcs@chromium.orgメーリングリストを見守る時期です。Let's Encryptが直接そう推奨しています — 来るべき変更の一部はクライアント側の対応を必要とし、発行側が準備できたときにクライアントも準備できていて初めてエコシステムが回るからです。
インベントリと暗号アジリティ。どこでどの署名を使っているかを把握していなければ、どんなスケジュールも意味を持ちません。公開WebPKIとプライベートPKIは経路が分かれます — プライベートPKIはPQCを使う伝統的なX.509に先に移行できますし、Chromeもその用途はサポートすると明言しています。
今すぐ何も変わらないという事実を受け入れる。Let's Encryptの表現通り、今日変わることは何もありません。既存の証明書はこれまで通り発行され、更新されます。

急ぐ必要がないという意味ではありません。急ぐべき場所が証明書ではないということです。

おわりに

まとめるとこうです。ポスト量子移行において暗号化はすでに半分ほど来ており、認証は暗号理論ではなくサイズのせいで行き詰まっていました。FIPS 204が定めるML-DSA-44署名2,420バイトに、今日のハンドシェイクが運ぶ署名5個・公開鍵2個を掛けると1万4千バイト台になり、これはCloudflareが2021年に実測した「10kBを超えると失敗率が急増し、9kB未満でも15%遅くなる」という壁のはるか外側です。

Merkle Tree Certificatesはこの問題をアルゴリズムではなく構造で解きます — 証明書をバッチにまとめてツリーヘッド一つだけに署名し、ハンドシェイクには包含証明だけを載せ、CTを発行プロセスに組み込んでSCT署名を消し去ります。ドラフトの推定では、最新状態のクライアントに対して736バイト、署名0個です。ポスト量子に移行しながらもむしろ今日より小さくなるという主張は、ここから来ています。

その代わり条件が付きます。その数字は7日の寿命・毎時のlandmarkといった仮定の上の推定値であり、クライアントが最新のlandmarkを持っているときにのみ成立し、そうでなければより大きなフォールバックに落ちます。どれだけ頻繁に落ちるかは、今まさにChromeとCloudflareが実際のトラフィックで測っている最中であり、その答えが出るまで736バイトは目標値であって実測値ではありません。標準は-05ドラフトであり、Let's Encryptのプロダクションは2027年、Chromeの新しいルートストアは2027年第3四半期の計画です。すべてまだ計画です。

エンジニアとしてここから得るべき教訓は、少し一般的なものです。WebPKIがこの20年、何かを直すたびに署名を一つずつ積み増してきたのは、伝統的な暗号が安価だったからこそ可能だったことであり、その積み重なった便利さは、アルゴリズムが20倍大きくなった瞬間に請求書として返ってきました。サイズが20倍になれば、個数を20分の1にするしかありません。MTCがやっていることはまさにそれです。