要約

  • draft-ietf-tls-trust-anchor-ids-06 は、TLS の相手が証明書経路を選ぶための短い ID を提案する。要求リストは信頼ポリシーの完全な写しでも、選ばれた経路を受け入れる約束でもない。
  • 一致を示す空の拡張は、完全かつ正順で余分のない証明書列を要求する。経路構築は省略できても、RFC 5280 に沿った検証とアプリケーション固有の判断は残る。
  • 選択結果、検証結果、回復の一回限りの再接続、プライバシー条件を別々の証拠として残さなければならない。

証明書の処理では「どの経路を試すか」と「その経路を受け入れるか」がしばしば一つの成功率に押し込まれる。だが、両者は異なる問題である。中間証明書や複数のルートがあるとき、候補を組み立てる作業はグラフ探索になり得る。候補が一つに定まった後でも、名前、期限、制約、アルゴリズム、アンカー、アプリケーション要件を検証しなければならない。

TLS ワーキンググループの Trust Anchor IDs 案は、この境界を通信上にも表す。2026年9月30日に更新された revision 06 は、ヘッダーで Standards Track を意図すると記す。一方、保存した Datatracker レコードの intended_std_level と std_level は null である。これは Internet-Draft であって RFC ではなく、今回の資料は実装、普及、相互運用性を立証しない。

IDは候補を絞るためにある

サーバーは同じサービスについて複数の証明書経路を保持できる。従来の certificate_authorities 拡張でも受け入れ得る機関を示せるが、識別名の一覧は大きくなる。個別の Trust Anchor ID と複数アンカーを表すグループ ID は、より小さい選択信号を提供する。

依拠当事者は ClientHello または CertificateRequest に順序なしの RequestedTrustAnchorList を入れる。空でもよい。しかも、実際に信頼するアンカーを省いたり、信頼しないアンカーを含めたり、信頼しないメンバーを含むグループを示したりできる。メッセージ長とフィンガープリントの抑制が理由になり得る。

認証側は各候補経路に、発行アンカーの個別 ID と該当グループのパターンを関連付ける。要求と交差する経路を選び、certificate_authorities もある場合はどちらかを満たす候補を用い得る。一致しなければ handshake_failure で終了するか、フォールバック証明書を送る。

ここで得られるのは「選ぶ理由」である。クライアントの信頼ストアを遠隔で読む権利でも、変更する権利でもない。誤った経路メタデータは選択を誤らせる。意図的に不正確なクライアント一覧も同じことを起こす。結果は検証失敗であり、信頼の自動拡大ではない。

空の拡張が示す厳密さ

選んだ証明書が要求 ID と一致したとき、認証側は Certificate に空の trust_anchors 拡張を含められる。空であることは情報不足ではない。この印は、証明書リストが完全で、正しい順序にあり、無関係な証明書を含まないことを要求する。

依拠側はその列を構築済み経路として扱い、別の経路を探索しない選択ができる。RFC 4158 が扱う構築の複雑さを減らせる。一方、RFC 5280 の検証は続く。リストが美しく並んでいても、ローカルに許可されていないルートへ達することも、名前制約に反することも、期限切れであることもある。

したがって監査ログには少なくとも二つの記録が必要だ。一つは「要求 ID と一致したため、この経路が選ばれ、厳密な列として送られた」。もう一つは「ポリシー版 P が理由 R で受理または拒否した」。前者を後者の代用品にすると、障害時に探索問題と権限問題を区別できなくなる。

回復は経路を選び直す

草案は最初の推測が外れることを前提にする。サーバーは EncryptedExtensions で、利用可能な個別アンカー ID の非空リストをサーバーの好み順に送れる。クライアントが後で証明書を拒否した場合、実際に信頼するアンカーとの共通部分を探し、双方の優先度を考慮して一つを選び、新しい接続でその ID だけを要求する。

再試行は最大一回である。リストがない、信頼できる一致がない、または再試行にも失敗したなら、アプリケーションへエラーを返す。新しい接続には往復遅延が加わる。回復は検証規則を緩めず、最初に与えた選択信号の曖昧さだけを解消する。

新旧 CA の移行では、この性質が段階導入を可能にする。新しい経路を優先し、古い経路を回復用に残せる。しかし、再試行する端末群を放置すれば、移行措置は恒久的な遅延になる。成功率だけでなく、初回選択、拒否理由、再接続、最終結果を同じ相関 ID で追う必要がある。

グループは同意ではない

グループ ID は複数アンカーを圧縮するが、全メンバーへの信頼を意味しない。クライアントは一部を拒否するグループを送れる。サーバーがその拒否対象を選べば、正しいグループ照合と正しいローカル拒否が同時に成立する。

この矛盾に見える状態は、権限分散の結果である。問題はグループ定義の配布と版管理に移る。誰が ID を割り当て、いつメンバーを変え、サーバーの経路属性を更新し、古い実装を観測するのか。古い定義は信頼を付与しないが、可用性を損なう。

また、サーバーがある CA の経路を選んだからといって、その CA を制度的に支持したことにはならない。選択は在庫、メタデータ、要求、優先度の結果である。技術的な調整を正統性の証拠に変えてはならない。

送信条件が観測者を決める

草案は ID を送らない実装、条件付きで送る実装、常に送る実装を区別する。条件付き信号の観測には通常、能動的な刺激が要る。常時送信のリストは受動的に収集できる。ユーザー固有の常時リストは、短くても強い指紋になる。

そのため、一人だけが持つ常時リストを避け、多数が共有する匿名集合のリストを使うべきだとする。ただし、過去の接続状態からリストを作ればセッションを関連付け得る。グループも、利用人口が小さければ匿名性を与えない。

サーバーの利用可能アンカー一覧も、要求されたサービスと SNI に合わせて絞る必要がある。共有基盤の全在庫を返せば、不要な制度関係を公開する。機微なアンカーはこの仕組みに載せない方がよい。

最小の運用レシート

必要なのは中央集権的な信頼台帳ではなく、独立した判断を比較可能にする小さなレシートである。そこには七つの欄がある。

第一は信号方針で、送った個別・グループ ID、条件、匿名集合規則を残す。第二は経路在庫で、実在するチェーンとメタデータの出所・版を記す。第三は選択とフォールバックで、どの拡張が一致し、優先度と不一致時動作が何だったかを示す。

第四は権限を持つローカル検証、第五は利用可能一覧と一回の再試行を示す回復、第六は送信条件とサービス絞り込みを示すプライバシーである。第七に、実際の経路、ハンドシェイク結果、拒否理由、利用者に見えたサービス結果を置く。

この分離は、実行コードから事実を得ながら、将来の判断を各参加者に残す。選択を効率化しても、信頼を中央化する必要はない。

情報源