要約

  • RFC 9691ではTAKで後継鍵を通知できるが、RPは30日間の受け入れ期間中も現行鍵で本番検証を続ける。
  • RPは現行TAKと後継TAKの相互参照を確認し、鍵と証明書URLが期間中変わらないことを観測する。
  • 一つのRPの切り替えは、そのRPの状態だけを証明し、全RPの移行完了を意味しない。

RFC 8630のTrust Anchor Locator（TAL）は、トラストアンカーCA証明書の取得先と、その自己署名証明書を確認するための公開鍵をRPに与える。これは帯域外で配布される初期の信頼材料であり、そこで固定された鍵の変更は通常のリポジトリ更新とは性質が異なる。

RFC 9691は署名付きTrust Anchor Key（TAK）オブジェクトを定める。TAKは現行鍵と証明書の場所に加え、後継鍵とその証明書の場所を示せる。ただし、後継鍵が見えただけでは採用されない。RPは後継鍵を使って上位から検証し、後継TAKが存在すること、現行TAKが後継鍵を示すこと、後継TAKが現行鍵を前任として示すことを確認する。

この確認が初めて成功すると、RPは30日間の受け入れタイマーを開始する。その間の本番検証には現行鍵を使い、以後の成功した検証でも鍵と証明書URLが変わっていないか確かめる。後継鍵が消えたり検証に失敗したりすれば、タイマーは取り消される。条件を満たしたまま期間が終わって初めて、後継鍵が現行鍵になる。

したがって、運用者による公開、あるRPによる後継鍵の検証、安定した継続観測、そのRPの切り替えは別々の事実である。どれも全体の採用を単独では証明しない。

さらに、TAKを処理できないRPはTALまたは手動設定の鍵を使い続ける。RFC 9691は、旧クライアントの継続性のため、以前の鍵対と別のリポジトリディレクトリを一定期間維持する必要があり得るとする。古いTALに依存するRPと、まだ30日間の途中にいるTAK対応RPは区別しなければならない。

RFC 6489も、CA鍵更新を新CAインスタンスの準備、証明書・CRL・マニフェストの公開、準備期間、下位成果物の再発行、旧インスタンスの退役に分ける。RFC 6916のアルゴリズム移行も、CA準備、成果物更新、RP準備、移行期間、旧方式の終了を個別の節目として扱う。

受け入れ記録には、現行鍵と後継鍵の指紋、証明書URL群、両TAKのハッシュ、最初の成功観測、タイマー開始、継続確認、切り替え時刻、検証器の識別情報と版を結び付ける。TALだけを使う集団については、支援期間と終了判断を別に残す。

これはRFCが義務付ける監査様式ではなく、証拠を適切な範囲で扱うためのガバナンス上の提案である。

出典