Summary

  • RFC 9932 の MATF では、中央の運営者がメンバーを審査し、信頼アンカーを管理し、エンティティー情報を JWS で署名する。検証できるのは配布された状態の出所と完全性であり、加盟判断の証拠や権限ではない。
  • 審査資料を全メンバーに配る必要はない。ただし、適用方針の版、判断主体、証拠の種類、例外の期限、次回審査、訂正・不服申立て先を記した最小のステータス受領票は、運用メタデータと別に残すべきだ。

ある学校システムの API が、別組織の API と通信を始める。相互 TLS は成功し、提示された公開鍵はローカルに事前登録されたピンと一致する。ピンをたどると、署名済みメタデータ内の entity_id に到達する。アプリケーションは相手の名前を得る。

ここまでの検証は、相手がフェデレーションの現在の状態に登録されていることを強く示す。だが、登録に至った審査の質は一度も検証していない。

RFC 9932 は、組織横断の機械間通信に相互認証 TLS を使う MATF を記述している。運営者がメンバー情報を集約して署名し、参加者がその文書から接続先、公開鍵ピン、発行者証明書、組織名やタグを取得する。認証のための共通状態を、各組織が個別に手入力しなくてよい点は実務上大きい。

だからこそ、何を機械化したのかを狭く定義する必要がある。MATF が機械化するのは承認済み状態の配布であって、承認理由の審査ではない。

独立投稿 RFC という出所

RFC 9932 の公開記録 は、文書を Informational、ストリームを Independent Submission としている。本文も、IETF Standards Track の仕様ではなく、IETF の成果物でも、IETF コミュニティーの合意でもないと明記する。TLS 1.3 自体を変更する文書でもない。

RFC 7841 がストリーム、ヘッダー、定型文を区別するのは、RFC という共通の出版形式の中でも制度上の出所が異なるからだ。独立の提案が有用であることと、インターネット標準として承認されたことは同義ではない。

この点を曖昧にすると、採用組織が自ら説明すべき加盟基準に「IETF が認めた」という権威を借りてしまう。RFC 9932 はむしろ、詳細なメンバー審査を各フェデレーションの枠組みに委ねている。

採用の正当性も、個別の加盟判断の正当性も、実際に決める組織が示さなければならない。

一つの運営者に集まる役割

RFC 9932 におけるフェデレーション運営者は、中央の信頼アンカーを管理し、新規メンバーを審査し、セキュリティー方針を執行し、メタデータを保守する。参加者はその完全性と能力を十分に信頼する必要があるとされる。

運営者は、申請者を評価するだけではない。提出内容の真正性を確認し、識別子と組織を結び、エンドポイントとピンを掲載し、集約文書に署名し、更新・期限・キャッシュ規則を決める。鍵が信用できなくなれば、ピンを削除した新しい状態も発行する。

この集中は、必ずしも欠陥ではない。対象分野が限定された小規模な共同体では、一つの運営者が明確に責任を持つ方が安全な場合もある。問題は、最後に作られる署名済み一覧だけを見て、先行する判断まで監査済みだと扱うことだ。

文書は境界を隠していない。詳細なメンバー審査は適用範囲外であり、メンバーが提出する情報をどの経路で受け取り、どう認証するかもフェデレーションや規制機関に委ねられる。技術仕様は、誰を入れるべきかを決めていない。

JWS が確定するもの

RFC 7515 の JWS は、デジタル署名または MAC で保護された内容を表現する。MATF の受信者は、信頼するフェデレーション検証鍵を使い、署名者の出所と保護対象の完全性を確かめられる。

したがって、「このエンティティー一覧とピンは運営者が認証した内容である」「発行時刻と有効期限はこの値である」という命題には強い根拠がある。

一方、次の命題は JWS からは出てこない。

  • 審査時に正しい方針版が使われた。
  • 証拠は最新で、要求された保証水準を満たした。
  • 例外を承認した役割に権限があった。
  • 暫定加盟は期限前に再審査された。
  • 同等の申請者に同じ基準が適用された。
  • 停止や除外に訂正・異議申立ての機会があった。

署名が壊れた文書と、判断が不適切でも正しく署名された文書は、別種の問題である。前者の検出だけを強化しても、後者の説明責任は生まれない。

Lu Heng の Policy Mirror の考え方を当てはめると、メタデータは方針決定を忠実に映す鏡だ。鏡像が正確でも、決定者の権限や判断過程は鏡の外にある。

必須チェックが対象にする範囲

リポジトリへの追加前に、RFC 9932 は少なくとも形式適合、entity_id の一意性、異なるエンティティー間でのピンの一意性、発行者証明書の構文・期限・アルゴリズム、タグの構文や許可語彙を検証するよう求める。

この組は相互運用に不可欠だ。二つのエンティティーが同じ識別子やクライアントピンを主張する混乱を防ぎ、壊れた証明書や想定外のタグが流通するのを抑える。

しかし、一意性は加盟資格ではない。未失効の証明書は組織の継続的適格性ではない。許可されたタグ文字列は、タグ付与の根拠ではない。組織名が正当な所有者に対応することを検証する仕組みも、具体的方法は運営者が選ぶ。

では審査資料を署名済み集約に追加すればよいか。そうではない。教育記録、事業証明、セキュリティー評価、個人情報を広く複製されるローカルメタデータへ入れるのは、監査可能性と引き換えに過剰な露出を招く。

必要なのは公開と秘匿の二択ではなく、状態と理由の分離だ。認証に必要な最小状態は高速に配布し、判断の出所は権限に応じて参照できる別の受領票にする。

発見と認証の後にも判断がある

MATF のメタデータは、相手を探すためにも使われる。クライアントは組織やタグでサーバーを選び、base_uri とピンを取得する。サーバーは接続方針に合うクライアントのピンだけを事前登録できる。掲載の有無とタグ付けは、通信可能性に直接影響する。

それでも、RFC 9932 は認証とアプリケーション権限を同一視しない。中間装置が TLS を終端する場合、証明書、導出ピン、または entity_id を完全性とエンドポイント認証のある経路でアプリケーションへ伝える。相手が HTTP ヘッダーで持ち込んだ同名の値は削除し、中間装置が信頼できる値を設定する。アプリケーションは、その後に自分の認可方針を適用する。

RFC 8446 は TLS 1.3 を、RFC 5280 は X.509 の証明書とパス検証を定める。鍵の所持とエンティティーの解決は、特定業務を実行する許可とは違う。

加盟についても同じである。登録されたアイデンティティーは後段判断の入力であり、あらゆる場面の信頼を保証するものではない。

検証鍵の配布と権限の拡大

フェデレーション署名鍵は、RFC 7517 の JWK Set で公開され、ロールオーバーを可能にする。RFC 7638 の JWK Thumbprint を別経路で照合すれば、取得元一つだけに依存せず検証鍵を確認できる。

これは良い証拠設計だ。同時に、いったん信頼アンカーが確立されると、運営者が次の集約へ加えたエンティティーは多数の参加者に自動展開される。鍵配布の効率は、運営判断の到達範囲も広げる。

署名鍵の連続性は「同じ運営者が発行した」を支える。加盟方針の連続性や個別判断の公平性は支えない。表現も、「この状態で鍵とエンティティーの対応を認める」と限定すべきで、「組織全体を信頼する」まで広げるべきではない。

exp は判断を更新しない

メタデータには発行時刻 iat と失効時刻 exp があり、RFC 7519 の NumericDate を使う。任意の cache_ttl はローカル更新間隔を支える。配布障害時には未失効のコピーを使えるが、exp を過ぎれば信頼してはならない。

この時計が測るのは文書の利用可能期間だ。メンバーの資格を自動再評価する時計ではない。水曜日に期限を迎えた例外が、日曜日まで有効な集約に残ることはあり得る。次の集約の配布失敗で、適格なメンバーの制度上の資格まで消えるわけでもない。

鍵ローテーションでは、新しいピンを追加し、伝播を待ち、証明書を切り替え、旧ピンを削除する。RFC 7469 は参照される SPKI ピンの基礎だが、MATF はブラウザーの HPKP 運用そのものではない。

鍵の時間と加盟判断の時間は、互いに照合する必要がある。どちらか一つで両方を代用してはいけない。

判断受領票に残す最小項目

ここで提案する受領票は RFC 9932 の要件ではない。既存のフェデレーション判断に、監査できる継ぎ目を設ける編集上の提案である。

受領票は、フェデレーションとエンティティーを特定し、加盟、制限、停止、除外、期限切れの状態と発効時刻を示す。適用した方針と版、責任を負う役割、確認した証拠の分類と確認日を残す。例外があれば、種類、範囲、承認者の役割、期限を記す。許可されたサービスや発見タグには根拠を結び、次回審査と訂正・不服申立て先を定める。

詳細な証拠はアクセス制御下で保管できる。外部には、決定種別の件数、期限超過の例外、覆った決定、未処理の異議などを集計して示せばよい。必要なら運用状態と受領票のダイジェストを結び、監査者だけが内容を照合する。

除外にも同じ仕組みが要る。緊急停止は直ちに反映しつつ、理由分類、決定役割、審査期限を持たせる。最終判断は後続受領票で確定し、過去を消さずに訂正できる。

Sources