要約

  • RFC 9932 は、署名された連盟メタデータと事前読込みした pin により、機械同士の TLS 相手を識別する MATF を説明する。これは独立提出の情報 RFC であり、IETF 標準や実運用の証明ではない。
  • pin の一致と TLS 由来の entity_id は、アプリケーションが認可を判断するための入力である。接続、操作許可、実行、結果を自動的に証明するものではない。

連盟の仕組みでは、「このメンバーは信頼できる」という言葉が便利に使われる。しかしその言葉は、誰が何を検証したかを隠しやすい。連盟運営者がメンバーを審査したこと、署名したメタデータを公開したこと、ローカル・ストアが更新されたこと、pin が読み込まれたこと、提示証明書が一致したこと、アプリケーションが行為を許可したことは、同じ出来事ではない。前の出来事は後のための条件になり得るが、後の出来事の記録にはならない。

RFC 9932 は Mutually Authenticating TLS in the Context of Federations を、機械対機械の認証のための枠組みとして扱う。最初にその文書の地位を守る必要がある。これは独立提出の Informational RFC であり、TLS を変更せず、IETF の合意や標準化された実装義務を表明しない。ブラウザ認証を対象にしたものでもない。したがって、RFC が公開されているという事実を、特定の連盟、ソフトウェア、証明書、接続が存在するという証拠へ膨らませることはできない。

出発点は連盟メタデータである。運営者はメンバーのエンティティ情報、エンドポイント、pin、発行者証明書などを集め、JSON Web Signature として配布する。受け手は、あらかじめ信頼すると決めた検証鍵に対して、そのオブジェクトの署名と完全性を確かめられる。この検証は重要だが、答える問いは限られる。「この内容のオブジェクトは、その鍵で署名されたか」である。「接続プログラムがいま最新のオブジェクトを使ったか」「選ばれた相手が意図した相手か」「サービス規則がそのままか」までは答えない。

更新と期限は、その差を見える形にする。RFC 9932 では、メタデータは exp を過ぎたら、キャッシュに残っていても拒否しなければならない。また連盟には期限とキャッシュを管理する規則が求められる。ここでは、署名に入った発行時刻、各メンバーがローカルに更新した時刻、接続するコンポーネントがその版を参照した時刻を分けて記録する必要がある。署名が正しいことと、古い pin が残っていないことは別である。公開が済んだことと、全員が新しい鍵を事前読込みしたことも別である。

次に TLS の相手検証がある。メンバーは接続しようとする、または受け入れる対象の pin を事前に読み込む。TLS 接続では、相手が提示した証明書の公開鍵を、そのメタデータ上の pin と照合する。一致がなければ接続を止める。この規則は、公開された pin 方針を満たさない相手を受け入れないための境界である。だが pin がリポジトリにあることは、今回その証明書が提示された証明ではない。照合が成功したとしても、それはアプリケーションが特定のデータ読取り、書込み、削除、顧客操作を許すかという判断とは異なる。

RFC 9932 は中継者を通る場合に、その順序を厳しくする。プロキシが TLS を終端するなら、後ろのアプリケーションは相手自身が送ったヘッダや任意のフィールドを認証済みの身元として受け取ってはならない。中継者が pin を検証するか、証明書、派生 pin、entity_id を完全性保護とエンドポイント認証を持つ経路で伝える必要がある。伝える値は TLS セッションから直接導かれなければならない。文書がこの情報を渡す目的として述べるのは、アプリケーションが認可を行えるようにするためである。ここには二つの主体がいる。相手の身元を検証する主体と、資源の使用を許す主体である。

鍵のローテーションは、制度面でもこの区別を試す。新 pin をメタデータへ追加する。運営者が署名済みの集約を再公開する。他のメンバーが更新し、新 pin を読み込む。終端が新しい証明書を提示する。十分な移行期間の後に旧 pin を除く。公開、配布、採用、切替、削除は同じ完了記録ではない。どこかが遅れると、正当な接続拒否や一時的な不達が起こり得る。さらに、TLS が成功した後のアプリケーション認可は、これらの手順のどれにも吸収されない。

運用記録には、署名集約の発行者とハッシュ、exp、ローカル版と更新結果、選択したエンドポイント、提示された証明書または派生 pin、照合結果、照合をしたコンポーネントを分けて残す。中継を越えたなら、身元を渡した保護経路も残す。その次に、サービス固有の方針、認可判断、要求、実行、観測された結果を置く。この順序を保てば、「連盟のメンバーだった」という表示が、いつ、どこで、どの規則によって操作の許可へ変わったかを検証できる。

RFC 9932 は中央の信頼アンカーを万能な権力として設計していない。連盟運営者は、メンバー情報を扱い、公開の整合性を保つ責任を持つ。資源所有者は、データ公開や不可逆操作の損失を負うため、認可規則を持ち続ける。署名済みメタデータは相手を読めるようにする。どの行為を受け入れるかを署名するのは、なおそのサービスである。

出典