要約

  • RFC 8360の新しいv2ポリシーと資源拡張OIDを使う証明書では、対応する検証者がVerified Resource Set（VRS）を計算し、CAの過剰申告部分だけを除外して正当なサブツリーの検証を継続できる。
  • 過剰分が有効になるわけではない。ROAの全プレフィックスとルーター証明書の全ASNはVRS内になければならず、旧RFC 6487プロファイルの証明書は従来どおり過剰申告で拒否される。

一つの余分な資源が持っていた重さ

RPKIの資源証明書は、IPアドレスブロックや自律システム番号を公開鍵に結び付ける。子CAが主張できる範囲は、発行者からトラストアンカーまでの経路が支える範囲に限られる。RFC 3779が資源拡張を定義し、RFC 6487がRPKI向けの証明書プロファイルと検証手順を整えた。

従来手順は明快だが、故障の単位が大きかった。CA証明書が発行者の有効な保有範囲にない資源を一つでも申告すると、その証明書全体が無効になる。その下の証明書や署名オブジェクトは、内容が正当でも検証経路を失う。階層の上部ほど、わずかな不整合が多くの利用者へ伝わる。

原因は攻撃に限られない。資源移転で親の範囲が縮小した後、子が証明書を更新するまで時間差が生じることがある。管理データベースと発行系の同期不良もあり得る。RFC 8360は2018年当時、この事象の確率を低いとしながら、発生時の影響は大きいと評価した。そこで問われたのは、誤りを許すかどうかではなく、誤りと無関係な正当部分まで失う必要があるかどうかだった。

RFC 8360の著者はGeoff Huston、George Michaelson、Carlos Martinez、Tim Bruijnzeels、Andrew Newton、Donald Shawの6人である。共同で設計した代替検証アルゴリズムは、Verified Resource Set、略してVRSを中心に置く。証明書に記載された集合をそのまま権限とせず、検証済みの証明書経路を通じて残る交差部分だけを権限の上限とする。

IPとASを別々に切り分ける

VRS-IPはIP資源、VRS-ASはAS番号について計算される。過剰申告がなければ、RFC 6487の手順と結果は変わらない。差が出るのは、子の申告集合が経路の裏付けをはみ出す場合だけである。その差分は警告対象となり、利用可能な集合から除かれる。

ただし、この挙動は旧証明書へ自動的に適用されない。RFC 8360はv2の証明書ポリシーOIDと新しい資源拡張OIDを導入した。証明書が新プロファイルを示し、検証ソフトが対応していれば、検証者は過剰分を報告してVRSで先へ進む。旧RFC 6487ポリシーを使う証明書なら、過剰申告は証明書全体の拒否を要求する。OIDは互換性と意味を結ぶ境界である。

VRSが空になった場合も、権限は拡大しない。状態が一時的かもしれないため、CA証明書自体を直ちに拒否しなくてもよいが、空集合では配下の資源オブジェクトを一つも正当化できない。階層上にノードが残ることと、使える資源が残ることは別だ。

仕様の例では、子CAが正当に委任された192.0.2.0/24と、裏付けのない198.51.100.0/24を同時に申告する。VRSに残るのは前者だけである。前者のROAは有効になり得るが、後者のROAはならない。過剰申告を含むCAが存続しても、余分なプレフィックスは検証境界を越えない。

オブジェクト単位の検査は残る

CA証明書の処理が細粒度になっても、配下の署名オブジェクトが一括承認されるわけではない。RFC 6482が定義するROAについて、RFC 8360は、列挙された全プレフィックスがエンドエンティティ証明書のVRS-IPに含まれることを求める。一つでも外に出れば、そのROAは検証に失敗する。

このため、RFCは必要に応じてプレフィックスごとにROAを分ける運用を示す。無関係な資源を一つのROAにまとめれば、片方の喪失がもう片方の認可にも波及する。BGPsecルーター証明書では、全ASNがVRS-ASに含まれなければならない。ASNごとに証明書を分ければ、同様に影響を隔離できる。

適用範囲にも線が引かれている。アルゴリズムが扱うのは単一トラストアンカー内の経路であり、複数のアンカーが重複資源を主張する問題は対象外だ。また、検証者のローカルな判断を資源保有の証明へ変える仕組みでもない。変わるのは、一つの経路内で誤りをどこまで伝播させるかである。

発行側より先に検証側を準備する

新OIDは移行の入口であると同時に互換性の壁でもある。代替プロファイルを知らない検証ツールは、新OIDを持つ証明書を拒否する。RFC 8360が検証者の更新をCAの新プロファイル発行より先に置くのはこのためだ。発行できることと、利用環境が受け入れられることは一致しない。

一斉切替は必要ない。プロファイルは証明書ごとに選べる。ルートが旧ポリシーを維持し、その配下のCAだけが新プロファイルを採用する構成も可能である。検証者が対応していれば、影響の大きい場所から段階的に封じ込めを導入できる。

RFC 8488は2018年時点の実装例を残している。当時のRIPE NCC Validatorは、運用者が選ぶstrict validationの設定を持ち、非strict時には設定に基づいて代替経路検証を用いた。これは移行期の一実装を説明する史料であり、現在の製品動作を保証するものでも、RFC 8360の証明書別OID規則を書き換えるものでもない。

Bruijnzeelsらの設計が守ったのは、厳格さよりも厳密さである。誤りは警告として残す。保有していない資源は一切通さない。そのうえで、経路が確かに支える資源だけは救う。信頼の範囲を広げず、故障の範囲を狭めた点に価値がある。

情報源