要約

  • FCI.DelegatedCredentials は下流 CDN の上限と暗号化公開鍵を広告し、MI.DelegatedCredentials は資格情報と任意の秘密鍵を運ぶが、どちらもエッジ単位の導入確認ではない。
  • 広告数はサーバー台数と一致するとは限らず、一つの資格情報を複数エンドポイントで使う構成も、エンドポイントごとに分ける構成も許される。
  • 運用上の完了には、発行、秘密鍵の来歴、メタデータ取得、各ノードの導入、ルーティング、クライアント提示、選択アルゴリズム、フォールバック、HTTP 結果を別々の証拠として結ぶ必要がある。

最終判定者は管理画面ではなく一回のハンドシェイク

同じ時刻に二人の利用者が同じホスト名へ接続しても、別のエッジに到達し得る。一方は新しい委任資格情報を提示するノード、もう一方は従来証明書へフォールバックしたノードである。どちらも接続に成功すれば、可用性のグラフは緑になる。しかし「委任資格情報への移行が完了した」という主張は片方にしか当てはまらない。

RFC 9677 が標準化するのは、その前段にある CDN 間の受け渡しだ。証明書の長期秘密鍵を多数の外部エッジへ複製せず、短命の鍵へ限定して TLS 終端権限を委任できる。これは重要な安全性の改善である。同時に、短命の秘密を誰が作り、どこへ配り、どのノードが使ったかという別の台帳を必要とする。

仕様の価値を守るには、受け渡しが証明する範囲を広げ過ぎないことが必要だ。MI の取得成功は、実行中の TLS プロセスから返った証拠ではない。

能力広告は配備地図ではない

下流 CDN は FCI.Metadata で MI.DelegatedCredentials 対応を示せる。さらに FCI.DelegatedCredentials で対応可能な委任資格情報の最大数を示し、秘密鍵輸送に使う PrivateKeyEncryptionKey を JWK として提供できる。

最大数は送信量を調整するための情報であり、予約でも実在サーバー一覧でもない。RFC は、その数が対象サーバー数に通常対応し得る一方、必ずしも一致しないと明記する。一つの資格情報を複数エンドポイントへ展開してもよく、十分な数が提供されれば個別資格情報を割り当ててもよい。

従って「最大十」は、十台の稼働、十枠の空き、十地域の収束を意味しない。広告をそのまま導入率へ変換する監視は、プロトコルに存在しない事実を作ってしまう。

秘密鍵が通る経路は一つではない

MI.DelegatedCredentials の配列には、RFC 9345 の構造を含む CertificateEntry が base64 で入る。対応秘密鍵は任意だ。含める場合、下流が広告した公開鍵で暗号化したコンパクト JWE として運ばなければならない。

秘密鍵が省略された場合、下流 CDN が鍵ペアを生成し、公開鍵だけを帯域外で上流へ渡していることが想定される。この方式なら秘密鍵は下流領域を出ない。ただし、帯域外の公開鍵要求と、後から届く委任資格情報と、ローカル秘密鍵の三者を結ぶ証拠が必要になる。

輸送方式では、上流が秘密鍵を扱った事実、JWE の宛先鍵、復号コンポーネントと秘密保管庫が重要になる。ローカル生成方式では、生成地点と公開鍵要求の真正性が重要になる。両者を「資格情報を受領」の一語にまとめれば、保管責任が消える。

暗号化された封筒にも過去がある

RFC 9677 は MI を通じた秘密鍵送信を推奨していない。送るなら、JWE 用の鍵は保護対象と同等以上の強度を持つ必要がある。輸送時の秘匿性は得られるが、前方秘匿性はない。将来、下流の復号秘密鍵が漏えいすれば、保存された過去の JWE が解読され得る。

委任資格情報の短い寿命は、不正使用可能な時間を狭める。しかし暗号文の保存、鍵の複製、キャッシュからの削除、HSM への格納を証明しない。七日という標準上限は、ログを捨ててよい理由でも事故調査を省略してよい理由でもない。

台帳には証明書と資格情報の指紋、受信鍵 ID、JWE アルゴリズム、時刻、検証結果、実行主体を残す。秘密鍵そのものは残さない。また、公開構造を解析できた状態と、対応秘密鍵で署名できる状態を分ける。

RFC 9345 の条件は配布後に効いてくる

クライアントは ClientHello で委任資格情報拡張と対応署名方式を提示する。提示していないクライアントへサーバーは委任資格情報を送れない。クライアントは通常どおり証明書チェーンと期待するサービス ID を検証し、委任署名、有効期間、アルゴリズム、CertificateVerify を確認する。

標準の最大有効期間は七日で、委任元証明書の有効期間を越えられない。資格情報は特定の署名方式にも拘束される。従って、CDNI で正しく受け取ったデータでも、クライアントの提示方式、証明書設定、時刻、有効期限によって拒否される。

クライアントが対応していても、サーバーは委任資格情報を送らない選択ができる。旧クライアント向けの通常証明書や遠隔署名を併用できるからだ。TLS 成功だけでは、どの経路が使われたかは分からない。必要なのは実際のハンドシェイク記録である。

取得と利用の間に運用の本体がある

RFC のコールフローは、能力広告、MI 取得、利用者との TLS、期限前の更新を示す。MI 取得と TLS の間に「全ノード導入済み」を表す規範的メッセージはない。その空白では、検証、復号、秘密保管、設定生成、段階展開、プロセス再読込、ヘルスチェック、トラフィック移行が動く。

ジョブをキューへ入れたことは実行ではない。秘密を保存したことは有効化ではない。有効化はルート選択を保証しない。ルート選択はクライアント互換性を保証しない。この連鎖の各接続点に別の領収書が要る。

フリート状態には対象集合を明記し、各ノードを導入済み、稼働中、旧版、失敗、ドレイン済み、未観測、フォールバックに分ける。割合だけでは、依然として少量の本番トラフィックを受ける一台を隠せる。

期限切れは曖昧さを接続拒否へ変える

FCI オブジェクトは更新を扱わない。上流 CDN は提供した資格情報と期限を監視し、適時に更新することが求められる。期限切れ資格情報しか持たない下流サーバーは、有効な委任資格情報を必要とする新規接続を拒否しなければならない。

その拒否は、観測したノードについては強い証拠だ。しかし他ノードの状態までは語らない。後継へ切り替え済み、重複期間中、通常証明書へフォールバック、ドレイン済み、到達不能などが混在し得る。

短命化は漏えい時の影響時間を減らす一方、ローテーション回数を増やす。可用性の目標は「期限前に発行」では足りない。旧経路の役割が終わる前に、ルーティング対象全体で後継が利用可能となり、互換性のないクライアントには検証済みの代替があることを測るべきだ。

十段階の証拠で意味の飛躍を止める

第一は委任元証明書の ID、指紋、許可拡張、有効期間。第二は委任資格情報の公開鍵、署名方式、指紋、期限。第三は秘密鍵の出所。第四は FCI の版、フットプリント、上限、暗号化鍵 ID である。

第五は正確な MI 版の取得と完全性。第六は対象ノードごとの検証・導入。第七は失敗、旧版、ドレイン、フォールバックを含む収束。第八はどの要求をどのエッジへ送ったかというルーティング判断。

第九がクライアントの提示、TLS 版、選択署名方式、証明書チェーン、委任拡張、検証結果を含むハンドシェイク。第十が HTTP とアプリケーションの結果だ。RFC 9677 はこの一部を規定する。残りは運用システムが偽らずに結ぶ必要がある。

初回ローテーション前に失敗時の動作を決める

能力広告がなければ、明示的に対応した経路を使う。上限が需要より小さければ、集合を減らすか構成を変え、予約と呼ばない。対応秘密鍵がない、または JWE を復号できない場合は隔離し、不明な状態で再配布しない。

混在フリートでは、旧ノードをドレインするか、検証済みフォールバックを保つ。カナリアには拡張対応・非対応クライアント、複数署名方式、期限直前の資格情報、各配備コホートを含める。フォールバックの成功は可用性として評価しても、委任配備成功へ数えない。

受信側の暗号化秘密鍵漏えいが疑われるなら、受信鍵と関連資格情報を更新し、過去に捕捉された JWE の範囲も調べる。短寿命は自動的な無害化ではない。

狭い仕様を狭く使うことが強さになる

RFC 9677 は認証局でも失効機構でもなく、ルーティング制御やエッジ証明、コンテンツ配信確認も行わない。二つの CDN が難しい秘密交換を相互運用可能にする。その役割だけで十分に価値がある。

Heng Lu の現実層と running-code primacy の考え方を当てはめると、設定された意図、実行ノードの状態、利用者の結果は別の事実である。共通仕様は最小限にし、導入順序、退避、証拠保全、事故時の権限はローカルに明示する。

MI の受領を「完了」と呼ぶのではなく、「受領」と正確に呼ぶ。その上で、エッジとクライアントが発する次の証拠を待つべきだ。

出典