要約

  • CRL Number は RPKI CRL に必須のままだが、RP が確認するのは非クリティカルであることと、上限内の非負整数であることだけで、順序付けには使わない。
  • 適用される現行 CRL は、証明書の CRLDP が指し、かつ発行 CA の現行マニフェストに一致する内容ハッシュ付きで載る一つのオブジェクトである。
  • そのオブジェクトを正しく選んでも、証明書の非失効、署名オブジェクトの有効性、経路起源、ルータのポリシー適用、通信結果はまだ証明されない。

先に見るべきなのは番号ではなく参照関係だ

ある検証テストで二つの CRL を同時に渡す。マニフェストにない方の CRL Number を大きくし、もう一方だけを現行マニフェストの fileList に正しいハッシュで載せ、証明書の CRLDP も後者に向ける。ここで大きい番号を選ぶ実装は、形式的に正しい値を読みながら RPKI の選択規則を破る。

これは構成した試験であり、実在製品の挙動ではない。RFC 9829 はこの境界を標準化した。RFC Editor の情報ページと Datatrackerによれば、2025 年 7 月公開の Standards Track RFC で RFC 6487 を更新する。履歴、参照文献、被参照文書、正誤表検索は文書の来歴を示す。資料凍結時に該当正誤表はなかったが、実装適合性の証明ではない。

RFC 5280の一般 PKI では、CRL Number は単調増加し、複数の利用可能な CRL の新旧を区別する助けになる。一方、RFC 6481が定める RPKI リポジトリ構造と、RFC 9286の署名付きマニフェストは、各現行オブジェクトのファイル名とハッシュを列挙する。そこに含まれる現行 CRL は一つである。

つまり、比較対象の集合そのものが消えた。CRL Number は嘘ではないが、選択者ではなくなった。

必須フィールドでも決定権を持たない

RPKI CRL に許される拡張は AKI と CRL Number の二つだけで、どちらも必須である。RP は AKI を処理する。CRL Number については、非クリティカルであり、値が 2^159-1 以下の非負整数であることを確認する。それ以上の意味、とくに現行 CRL の順序付けには使ってはならない。

ここでは「存在する」「正しく符号化されている」「意思決定に使える」が分離される。監視画面が三つを一つの合格表示にまとめると、構文チェックが権限の証拠に化ける。

RFC は CRL Number と、それを収録するマニフェストの manifestNumber を同じ値にすることを推奨する。運用上の照合には役立つが、等値は必須ではなく、不一致時に最大値選択へ戻る根拠にもならない。

CRLDP とマニフェストが一点で交わる

RFC 6487はリソース証明書と CRL Distribution Points を定義する。RFC 9829 による更新後、証明書の失効判定に使う CRL は、発行者の現行マニフェストと証明書の CRLDP の双方で特定される。

CRLDP だけでは、取得したバイト列が現行発行物か分からない。マニフェストだけでは、特定証明書がその CRL を参照しているか分からない。ファイル名だけなら内容差し替えを防げず、無効なマニフェスト内の正しいハッシュにも検証済み権限はない。参照先、fileList、ハッシュが同じオブジェクトに収束して初めて候補が決まる。

マニフェスト自体には順序がある。manifestNumber の増加、thisUpdate と nextUpdate、署名、EE 証明書、過去に検証したマニフェストとの比較によって「現行」が成立する。RFC 9981 の既存記事は番号上限と新しいファイル名による比較エポック回復を扱う。本稿はその回復ではなく、現行エポック内の CRL 選択権限を扱う。

ハッシュは発行意思を固定する

RFC 9286 のマニフェストは、古いオブジェクトへの差し替え、削除、転送中の改変を検出する材料になる。RFC 9829 は、fileList のハッシュが CA の「最新 CRL はこの内容である」という意思を暗号学的に固定し、競合する選択規則が生むリプレイ経路を減らすと説明する。

しかしハッシュ一致は万能な有効証明ではない。マニフェストの時刻と署名、CRL の署名と発行鍵、AKI、許可された拡張、対象シリアル番号を別々に検査する。CRL の署名を検証する公開鍵は証明書を検証する鍵と同じでなければならない。対象シリアルがこの適用可能な CRL に載るとき、初めて失効が成立する。

RFC 3779の IP/AS リソース拡張も、実際の BGP 経路や転送結果そのものではない。証明書層の判断をネットワーク結果へ短絡してはならない。

取得経路と検証権限を混ぜない

RFC 8182は RRDP による取得を定める。rsync 経路もあり、RP はキャッシュを持つ。取得成功はバイト列の到着を示すだけで、現行マニフェストを選ばない。RP 間で結果が割れたときは、CRL Number より、検証済みマニフェストのエポック、ハッシュ、キャッシュ判断を比較する。

RFC 9589 の既存記事は CMS signing-time、mod-time、RRDP から rsync への切替確認を所有し、RFC 9829 を補助的に引用した。本稿の固有領域は、その引用の中心にあった CRL Number の権限剥奪と二重参照の選択アルゴリズムである。

さらに下流では、RFC 6811が検証済み起源データと BGP 経路からローカル状態を求め、RFC 8210がキャッシュからルータへデータを届ける。ルータ受信、ローカルポリシー、RIB/FIB、パケット結果は別の記録である。

必要な監査列は、CA 発行、リポジトリ取得、マニフェスト選択、CRLDP/名前/ハッシュ一致、CRL 検証、シリアル検索、署名オブジェクト検証、起源状態、ルータ受領、ポリシー、観測結果となる。

標準が強くなったのは、判断材料を一つ減らしたからだ

RFC 9829 は共通仕様を厚くせず、重複するオラクルを外した。Heng Lu の最小初期仕様は、共有すべき最小不変条件を守る意味を示す。Reality Layersは番号、発行意思、検証結果、実行結果を分ける。Running-Code Primacyは、最終的に RP とルータがどの規則を実行したかを問う。

適合試験では、未掲載 CRL に最大番号を持たせる。さらにハッシュ、鮮度、署名、鍵、シリアル所属を一要素ずつ変え、原因別の結果を要求する。「CRL OK」という一つの表示では、選択権限が正しく一元化されたことを証明できない。

出典