要約

  • RFC 9691 の30日受入タイマーは、各 Relying Party が同じ後継関係を初めて正常に検証した時点で始まる。公開開始日から数えた一つの全体時計ではない。
  • 移行証拠は、相互 TAK、連続観測、二重リポジトリの等価性、実際に選ばれた鍵、旧 TAL 利用者、旧鍵破棄を別々に結び付ける必要がある。

RFC 8630 の TAL は、信頼アンカーの公開鍵と証明書取得先を検証者へ与える。証明書を再発行しても鍵が同じなら TAL は維持できる。しかし鍵そのものを A から B に変えるには、ローカル信頼状態をどう更新するかが問題になる。

RFC 9691 は署名付き TAK を定義した。A の TAK は B を successor とし、B の TAK は A を predecessor とする。検証者は B を起点に B 側 TAK まで検証し、B の current が A の successor と一致し、B の predecessor が A の current と一致することを確かめる。

この相互参照は意図した移行辺を機械的に検証可能にする。ただし、その辺を何台が見たか、連続して見たか、実運用で B を選んだかまでは語らない。

タイマーは各検証者の内部状態

前回の正常な検証で見ていなかった B を今回初めて正常に確認すると、その検証者は30日タイマーを開始する。期限までは A で通常検証を続け、B は動作確認にだけ使う。期限を過ぎた後、同じ後継関係を正常に見続けていれば、現在鍵を B に更新して再検証する。

B の検証が失敗する、または TAK から B が消えるとタイマーは取り消される。鍵や URI 集合が変われば、新しい移行として再開する。したがって常時稼働、停止中、季節運用、新規導入の検証者は別々の日に始まる。TAK を自動適用しない実装は人に通知するだけであり、未対応実装は TAL の A を使い続ける。

必要な記録は、検証者 ID、実装と版、ローカル TAL、A/B の指紋と URI、前回正常実行、初回観測、取消・再開、期限、実運用で選んだ根である。「公開から30日」は主語を欠いた事実だ。

同じ B を一度撤回してそのまま戻すことも危険である。撤回期間を取得しなかった検証者は古いタイマーを保持し、他より早く切り替わり得る。SubjectPublicKeyInfo を変えたくない場合でも URI 集合を変えれば、それを観測した側はタイマーを再設定する。最新オブジェクトだけではこの履歴を復元できない。

等価性は二つの公開面で維持する

移行期間、TA は A と B を別ディレクトリで運用する。TAK 以外の CA 証明書、IP/AS 資源、子 CA への委任は、どちらを起点にしても同じ検証結果を出さなければならない。

単一の公開サーバーなら RFC 8181 の両側操作を一つの要求に含める。複数サーバーなら短いずれは残る。資源縮小や失効は全公開点への反映まで完了せず、資源拡張は全側が準備できる前に子へ通知してはならない。

有効な TAK は、この同期を代行しない。A/B それぞれの検証済み資源集合、委任、manifest、CRL、公開世代と取得時刻を比較する必要がある。URI や発行者は違ってよいので、求めるのはバイト一致ではなく意味上の等価性である。

古い根を消す日は別の承認事項

標準の四段階は、A 単独 TAK、B と相互 TAK、新 TAL の配布と A の並行維持、最後の A リポジトリ削除と秘密鍵破棄である。新経路の試験、ブートストラップ更新、旧権限の撤去は別の決定だ。

B の TAL と TAK で異なる URI を使えば、TAK 経路を使うクライアントの割合を推定できる。しかし沈黙は、移行済み、停止、キャッシュ、廃止、パッケージ更新のどれでもあり得る。2025年の APNIC 解説は RIR が NRO RPKI Program で実装作業を調査中と述べたが、これは計画状況であり普遍的対応の証拠ではない。

A を削除した後、A しか知らない冷たい検証者は、B を学ぶための検証自体ができない。ローカル TAL の修復が必要になる。複数世代を飛ばした場合、各移行に30日を要し得る。一方で A を永久に残せば、古い秘密鍵と公開点の権限も残る。

TAK は根鍵侵害への治療でもない。A を奪った主体はすでに A 配下を支配できる。外部配布された TAK を TAL に変換する場合、既存の信頼根で検証できなければ、信頼は配布元へ移る。

RFC 6487、RFC 6488、RFC 9286、RFC 6481 は証明書、署名オブジェクト、manifest、リポジトリを定める。RFC 9319 の経路起点検証状態はさらに下流であり、根移行はルーター適用やパケット到達を証明しない。

Lu Heng の最小初期仕様は共通機構とローカル責任を両立させる。現実層の区別は署名、実行状態、検証出力、経路判断を混同させない。Running-Code Primacy が優先するのは、暦ではなく実際の検証者の観測である。

情報源