要約

  • RFC 5217 の例では、PKI2 が二つのドメインに参加しているため、PKI1 から PKI3 までの証明書パスを構築できる。しかし両端はドメイン1を共有しないので、そのポリシーによる検証は成功してはならない。
  • クロス証明書や Bridge CA は経路を作る材料である。受諾には、信頼アンカー、ポリシーマッピング、名前・ポリシー制約、参加状態、失効情報、そして特定用途に対する依拠当事者の検証結果が別に必要になる。

拒否ログを障害票にしない

検証器は必要な証明書をすべて見つけていた。候補パスの署名は順に確認でき、起点は設定済みの信頼アンカーだった。それでも結果は拒否である。

可用性だけを見る運用では、この行は修正対象に見える。しかし RFC 5217 の構造に当てはめると、拒否こそが正解になり得る。

PKI2 はドメイン1とドメイン2の双方に所属する。PKI1 から PKI2、PKI2 から PKI3 へパスがあり、構築アルゴリズムは両者を結べる。だが PKI1 と PKI3 は同じドメイン1の構成員ではない。ドメイン1の検証ポリシーを使うなら、そのパスは成功してはならない。

パスの存在は証明書グラフの事実である。受諾は権限と目的に関する別の事実だ。

パス構築は候補の発見にすぎない

パス構築は、信頼アンカーから終端証明書まで並ぶ候補列を探す。検証はその候補にポリシー、制約、用途、時刻、失効状態を適用する。実装上は連続処理でも、証拠としては分けなければならない。

ブリッジやメッシュは探索できる範囲を広げ、二者間のクロス証明書を減らす。遠い発行者へ到達しやすくなる一方、あらゆるアプリケーションがその発行者を受け入れる理由にはならない。

RFC 5217 では、各 PKI が自分の Certificate Policy OID と Principal CA を保つ。外部 PKI のポリシー文書と統治資料を調べ、どの保証水準を対応させるか決めてから関係を作る。クロス証明書はその限定された判断を技術的に表すもので、制度全体の統合証明ではない。

二重参加が経路を漏らす

PKI2 の二重参加は、別々の世界に横道を作る。制約が不十分なら、ソフトウェアは片側で与えられた信頼をもう片側へ継承できるように見せてしまう。各署名が正しいことは、この越境を正当化しない。

RFC 5217 は、ポリシーマッピングや名前制約などをクロス証明書に入れて、ドメイン外の検証を防ぐよう求める。境界を確実にしたいドメインは、依拠当事者が同じローカル設定を偶然選ぶことに頼るべきではない。

参加状態の変更も運用イベントである。PKI が別のドメインへ加入・離脱すれば、構築可能な経路が変わる。関係するドメインへ通知し、制約を見直し、許可される経路が変わるならクロス証明書を失効させて再発行する必要がある。

署名は文書の完全性を守るが、文書の前提となる関係まで固定しない。

正しい署名が答えない問い

誤解が生まれるのは、暗号学的な真正性を業務上の適合性まで広げたときである。クロス証明書の署名は、ある CA がポリシーマッピングや制約を確かに発行したことを示し、配送途中の改変を検出できる。しかし、依拠当事者の初期ポリシー集合を選ばず、ログイン、契約、コード署名といった用途の適否も決めない。判断時点で失効情報が十分に新しいことさえ、署名単独では証明できない。

RFC 5217 は、ドメイン側が確実に経路を制限したいなら、依拠当事者のローカル設定だけに頼らずクロス証明書へ明記すべきだとする。同時に、依拠当事者も正式な外観を理由に自分の検証入力を省略できない。署名は「誰が宣言したか」に答え、検証は「この目的で宣言に依拠できるか」に答える。

運用ログもこの違いを残す必要がある。no path、ポリシー不一致、名前制約違反、失効情報の取得不能、未承認アンカーは別の状態である。すべてを「証明書エラー」にまとめると、修復すべき接続と維持すべき拒否を見分けられない。

Bridge CA は共通の根ではない

Bridge CA はクロス認証の数を減らし、複数ドメインの関係を扱いやすくする。RFC 5217 は同時に、Bridge CA を参加ドメインの信頼アンカーとして使用してはならないとする。通常の終端証明書も発行せず、中立な立場で独自のドメインポリシー OID を用いてマッピングする。

中心に置かれた便利な装置を、最高権限へ昇格させない設計である。依拠当事者は自分のドメインが選んだアンカーから始め、ブリッジを通る各関係の制約を処理する。接続の中心性と決定権は一致しない。

信頼リストは判断主体を隠せない

Local Trust List では、依拠当事者が自分のアンカーを直接管理する。クロス認証を必要としない単純さと引き換えに、更新責任は個別に残る。Trust Authority は複数の依拠当事者向けにリストを管理し、作業を集約する。

どちらでも判断は必要だ。PKI を追加する前に、ポリシー、保証水準、依拠当事者の義務、保証内容を審査し、失効や危殆化の通知を継続的に確認する。他メンバーへの信頼を継承したくない場合は、ポリシーマッピングを抑止する。

リストの一行は運用権限である。CA の追加は新たな証明書を受け入れ、削除はサービスを止め得る。変更者、根拠、対象用途、時刻が追跡できなければならない。

受諾権限のレシートを残す

重要な判断にはチェーン以外の記録が要る。依拠当事者とアプリケーション、判断時刻、検証器の版、信頼アンカーの指紋と導入元、対象ドメイン、用途、初期ポリシー集合を結び付ける。

候補パスの全証明書、各段で処理したマッピングと名前制約、ドメイン参加状態、クロス証明書の失効、Trust List の版、CRL・OCSP の鮮度、最終結果と理由、実際に許可または拒否した処理も保存する。

構築できたが拒否されたパスも捨てない。到達性を見つけても権限へ膨らませなかった証拠だからだ。

適用範囲

RFC 5217 は Informational 文書であり、相互運用の方法を一つに限定しない。同じパスでも、別の信頼アンカーや用途、コミュニティなら結果が変わる。本稿は特定の CA や製品の欠陥を主張しない。

重要なのは、署名の正しさ、パスの存在、ドメイン参加、アプリケーションの受諾を一つの緑表示にしないことだ。その圧縮こそが、暗号技術の外から権限を作ってしまう。

出典

追加の標準記録

  1. RFC 5217 プレーンテキスト
  2. RFC 5217 情報ページ
  3. IETF Datatracker 記録
  4. IETF Datatracker 履歴
  5. RFC 4949：インターネットセキュリティ用語集
  6. RFC 5914：Trust Anchor Format
  7. RFC 5934：信頼アンカー管理要件
  8. RFC 6024：信頼アンカー管理プロトコル要件
  9. RFC 5055：サーバーベース証明書検証
  10. RFC 6818：RFC 5280 の更新
  11. RFC 6960：オンライン証明書状態プロトコル
  12. RFC 5019：軽量 OCSP プロファイル
  13. RFC 6962：証明書透明性
  14. RFC 7030：安全な転送による登録