要約

  • RPKIのマニフェスト番号は、一つのCAが公開するファイル一覧のローカルな順序証拠である。世界共通の時計でも、ネットワークの実動を示す記録でもない。符号化には上限があり、発行不具合によって後続番号が過去の受理値を超えられなくなる。
  • RFC 9981では、別のマニフェストファイル名が新しい番号比較の時代を成立させる。relying partyは運用者へ警告し、発行者は日常的な番号管理にこの変更を使うべきではない。
  • 切り替わるのは記憶された番号の基準だけである。署名と証明書、より新しいthisUpdate、ファイルとハッシュの一覧、署名オブジェクトURIとRRDPまたはrsyncの取得位置との厳密な一致は、引き続き検証される。

新しいのに、決して大きくなれないマニフェスト

ある認証局の発行ソフトウェアが、番号7914を作る代わりに、フィールドが表現できる最大値2^159 - 1を書いたとする。正しい鍵で署名され、時刻は現在で、ファイル名とハッシュも公開点を正しく説明している。複数のrelying partyが受理し、その番号を保存した。

運用者は誤りを見つけ、カウンターを直して、新しいマニフェストを発行する。現実の時間では後であり、署名も内容も正しい。それでも従来の比較では受理できない。すでに保存した最大値より大きい合法な値は存在しないからだ。

ここで衝突するのは二種類の証拠である。暗号学的証拠は、発行者が新しい声明を作ったことを示す。順序証拠は、その声明が受理済みの履歴に続くことはできないと示す。順序を無視すれば再生の余地が生まれ、厳格に拒絶し続ければ公開点が永久に凍る。どちらも守ろうとしている安全性は本物である。

RFC 9981は、双方が独立に観測できる最小の切れ目として、新しいファイル名を選んだ。発行者が都合の悪い履歴を消す一般権限を得たのではない。ファイル名が新しい比較時代を宣言し、その他の証拠は持ち越される。

マニフェストが数えるもの

RPKIマニフェストは、一つのCAが一つの公開点について発行する署名済み一覧である。そこに置く予定のファイル名と各ファイルのハッシュを結び、欠落、置換、不完全なリポジトリ表示を検出しやすくする。

マニフェスト自体もRPKI署名オブジェクトであり、一回限りのEE証明書を使う。内容にはmanifestNumber、thisUpdate、nextUpdate、ハッシュアルゴリズム、ファイル名とハッシュの組が含まれる。CA証明書はid-ad-rpkiManifest SIAによってマニフェストを指す。

しかし、その証拠範囲は限定されている。ROAファイルが一覧にあることは、その経路がBGPで観測されていることを意味しない。CRLが一覧にあることは、すべての検証者が取得したことを意味しない。VRPが生成されたことは、ルーターが取り込んだことを意味しない。マニフェストは公開層の主張であり、検証結果と転送結果は後段にある。

復旧でも層を混ぜてはならない。「RPKIの信頼が壊れた」と大きく捉えると、組織は全体リセットを選びやすい。実際に継続不能になったのは、一発行者の一ファイル名に結び付いた番号履歴である。修復もその範囲に閉じ込められる。

連続性を守る有限のカウンター

RFC 9286は、新しいマニフェストを発行するたびに番号を一つ増やすよう求める。relying partyは以前受理した値と比較し、新しい値が大きいことを確認する。番号の飛びは中間状態の欠落を、後退は古いオブジェクトや再生を示す手掛かりになる。

これは世界共通の時刻ではない。異なるCAの番号を比較しても意味はない。同じCAでも、番号はthisUpdateとnextUpdateを置き換えず、証明書の有効性、失効、署名オブジェクト検証も残る。

RFC 9981が明示した上限は20オクテットの正整数、2^159 - 1である。一秒に一枚という正常発行でも、使い切るまでおよそ23,171,956,451,847,141,650,870クインティリオン年を要する。運用容量の不足ではない。

危険はソフトウェアにある。誤った加算、待ち時間のない無限発行、壊れた状態復元、最大値の誤代入なら、一度で天文学的距離を飛べる。最大値が受理された後、ある実装は状態期限後に回復し、別の実装は無期限に小さい値を拒み得る。同じ公開点から異なる検証出力が生まれる。

従って監視対象は発行ファイルだけではない。relying partyが保持する比較状態と、その状態が製品・版ごとにどう更新されるかまで含めなければならない。

ファイル名が作る明示的な時代境界

RFC 9981では、CAに以前関連付けられたマニフェストと異なるファイル名を観測した場合、relying partyは番号が以前より大きくないという理由だけで拒絶してはならない。その他の検証を通過すれば、新しい名前の下で番号を保存し、比較を再開する。

ここでいうファイル名は、リポジトリ画面の表示ラベルではない。CA証明書のid-ad-rpkiManifest SIA URIにある最後のパス部分である。CAは新しい位置を示す証明書状態を発行し、その場所にマニフェストを置き、署名オブジェクトのURIと実際の取得位置を一致させる。

移行は三つの観測可能な行為になる。CAが新しいパスを命名し、リポジトリがそこから同じオブジェクトを提供し、relying partyが比較キーの変更を認識する。中央機関による全体リセットも、「小さいがたぶん新しい」という推測もいらない。

ファイル名変更を見たrelying partyは運用者へ警告する。正当な復旧、計画的CA移行、設定事故、秘密鍵や公開面の問題はビットだけでは区別できない。署名は誰が声明を作ったかを示すが、なぜ過去を切り替えたかは人の説明を要する。

日常的なローテーションにしてはいけない。再起動や更新のたびに名前を変えると、番号が後退を検知する価値を失い、有効な古い履歴を新しい始まりに見せる機会を増やす。例外は、稀で、記録され、説明されるからこそ安全に使える。

新しい時代にも残る検証

「新しい名前なら受理する」は誤りである。名前が決めるのは、どの保存済みmanifestNumberと比較するかだけだ。

新しいマニフェストには有効な署名と、CAへ連なる有効なEE証明書が必要である。証明書期限、失効、RPKIプロファイル、マニフェスト構造、ハッシュアルゴリズム、ファイル一覧、欠落やハッシュ不一致の扱いは変わらない。

鮮度も残る。新しいファイル名のthisUpdateは、以前受理したマニフェストのthisUpdateより後でなければならない。古い署名済み一覧を別名の場所へ移し、時刻検証を逃れることはできない。nextUpdateも発行者が示す有効期間を制限し続ける。

所在の証拠も残る。マニフェストEE証明書のsigned-object SIA URIは、RRDPで得るならpublish URIと、rsyncならURIとパスに厳密に対応しなければならない。署名上の参照を変えずにファイルだけコピーしても、仕様上の時代変更にはならない。

そしてマニフェストは、一覧内の各オブジェクトを書き換えない。新しい一覧を検証対象に戻すことはできても、証明書の資源、ROAのプレフィックス、CRLの状態、ルーター入力を変える権限は持たない。それぞれの主張は独自に検証される。

複数SIAが生む分岐

CA証明書に複数のマニフェストSIAがあると、単純な「旧名から新名へ」という説明は崩れる。relying partyによって対応・優先する位置が異なるからだ。置換証明書が一つの旧名を消しても、別の旧名を残せば、一方は新時代を観測し、他方は旧時代が継続すると判断する。

両者が選んだURIに従って正しく動いても、結果は逆になる。新名を選ぶ側は小さい番号を受理し、旧名を選ぶ側は保存済み最大値と比較して拒む。この分裂はキャッシュ、RRDP同期、製品障害と誤診されやすい。

そのためRFC 9981は、名前変更で復旧するなら、新しいCA証明書に旧マニフェストファイル名を一つも残さないよう求める。すべてのSIA値、プロトコル経路、検証者の選択規則を棚卸しする必要がある。「主系」だけの変更では足りない。

RRDPとrsyncは配送手段であって別の真実ではない。snapshot、delta、rsyncの各表示が、署名URIとバイトの双方で同じオブジェクトへ収束する必要がある。HTTP成功は配送の証明にすぎず、証明書がそのオブジェクトを承認した証明ではない。

トラストアンカーの復旧が難しい理由

従属CAなら、親の認証関係の下でCA鍵ロールを行い、新しいCA識別とマニフェスト履歴を作れる場合が多い。重複公開、証明書更新、子への連続性は必要だが、上位CAが移行を結び付けられる。

トラストアンカーには上位CAがない。公開鍵と証明書位置は通常TALによってrelying partyへ導入される。鍵を替え、新しいTALを配布すると、更新時期の差、古い導入の残存、急な切替によるツリー全体の到達不能が問題になる。

RFC 9691のTAKオブジェクトは計画的移行を改善する。現行トラストアンカーが後継公開鍵と証明書位置を示し、relying partyは現行・前任・後継の相互関係を検証し、受入れタイマーの後に移る。現在信頼される鍵から試験可能な帯域内の橋を作る仕組みである。

ただし、TAKは壊れた公開点を飛び越える万能の裏口ではない。検証は現行の信頼鍵から始まり、CA証明書、マニフェスト、CRLを処理してからTAKへ進む。連続性を前もって準備していないトラストアンカーには、緊急時の導入問題が残る。鍵移行とファイル名時代の復旧は別々に訓練すべきである。

異なる検証実装が収束して初めて復旧になる

新しいファイルへの署名は復旧完了ではない。独立した実装のrelying partyが正確なオブジェクトを取得し、RFC 9981に従って時代変更を受け入れ、一覧を検証し、期待する出力へ収束した時に完了する。

試験には取得済みまたは合成したリポジトリ材料を使い、本番の番号を最大値へ近づけてはならない。正常増加、異常な飛び、最大値、同名での小さい番号、新名での小さい番号、新名だが古いthisUpdate、不一致のsigned-object URI、旧SIA名を一つ残す証明書を用意する。

製品と版ごとに、取得URI、旧名、新名、保存番号、時刻比較、警告、検証結果、受理オブジェクト集合、VRP差分を記録する。差は雑音ではなく、実際の事故前に仕様対応と状態保持の不一致を見つける証拠である。

本番復旧でも、旧証明書、旧マニフェスト、全URI、番号、時刻、出力指紋を保存する。変更理由、承認者、新しいSIA、期待影響を記録し、RRDPのsnapshotとdelta、rsyncを別々に観測する。旧材料を除く前に検証結果とルーター入力を比較する。

新しいマニフェストが署名、時刻、URI、一覧のいずれかで失敗した場合、さらに別名を作ることはロールバックではない。発行を止め、証拠を保持し、規則が許す最後の実証済み状態へ戻す。連続したリセットは、限定された例外を説明不能な履歴へ変える。

情報源