要約

  • RFC 6916 は RPKI のアルゴリズム移行を、認証局、公開リポジトリ、依存側の検証者が連携する順序として定め、単独のソフトウェア更新とは扱わない。
  • 親から子へ進む方式では、移行期間中に旧・新両方のアルゴリズムスイートで署名済みデータを公開し、検証者の準備を確認してから旧方式を終える。
  • 数年単位の計画を想定する一方、RFC は緊急移行を規定しない。計画的な変更には道筋を与えるが、突然の暗号学的破綻への対応は別に必要だ。

暗号方式の変更は信頼の連鎖を動かす

リソース公開鍵基盤（RPKI）では、署名付きの宣言が階層をたどる。認証局（CA）が下位の CA を認証し、その CA がさらに下の資源に証明書や署名付きオブジェクトを発行する。依存側の検証者（RP）は公開されたデータを取得し、証明書の連鎖と署名を検証する。ネットワーク運用者はその結果を自らのルーティングポリシーに反映できる。

各段階は別の状態だ。証明書が発行されたからといって、全リポジトリに対応するオブジェクトが公開されたとは限らない。公開済みでも、すべての RP が検証できるとは限らない。検証結果だけでルーターの受け入れ方が決まるわけでもなく、その後の判断は運用者のポリシーに委ねられる。RFC 6916 が扱うのは、単なる署名アルゴリズムの置き換えではなく、変更中も各段階を結ぶ信頼経路を保てるかという問題だ。

「Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)」は、2013 年 4 月に RFC 6916、BCP 182 として公開された。著者には Roque Gagliano、Stephen Kent、Sean Turner の三人が記されている。これは IETF の合意による文書であり、いずれか一人の個人的な指示ではない。RFC 6916

置き換えるアルゴリズムより先に日程を決める

RFC 6916 は次のアルゴリズムを選んでいない。2013 年時点では、まず RFC 6485 が定めていた RPKI のアルゴリズムプロファイルを更新し、別途移行日程を設けるよう求めた。その後 RFC 7935 が RFC 6485 を置き換え、今回確認した現行プロファイルを定めている。将来の移行では、新しいラベルを証明書に加えるだけでなく、適用されるプロファイル自体を更新する必要がある。RFC 7935

日程には五つの時点が要る。CA が新スイートで発行できる準備日、署名済みデータを再発行し終える日、RP の準備完了日、旧スイートが任意になる日、そして旧スイートの終了日だ。RFC は各節目を該当日の UTC 午前 0 時 1 分に置き、CA と RP の準備指標を求める。時間は単なるプロジェクト管理ではない。リポジトリ、検証ソフトウェア、証明書がどの時点でどの方式を支えるかを示す運用条件となる。

アルゴリズムの移行と鍵の交換も区別しなければならない。RFC 6489 はスイートを変えない CA 鍵のロールオーバーを扱う。RFC 6916 が対象とするのはスイートそのものの変更で、証明書、失効リスト、マニフェスト、署名オブジェクトに及ぶ。鍵を交換できる仕組みが、そのままアルゴリズム移行を解決するとは限らない。RFC 6489

なぜ親から移行するのか

移行は階層を上から下へ進む。親 CA が新スイートで発行できなければ、子 CA はその方式の証明書を求められない。CA 証明書の署名アルゴリズムと主体鍵が異なるスイートに属する構成も避ける。順序を崩せば、混在スイートの証明書と複雑なリポジトリ構成を扱うことになり、RFC は公開データが指数的に増える可能性を警告している。

この階層は制御面の一部だ。親の準備は子の依存条件であり、子が単独で飛び越えることはできない。RFC は準備、発行、検証者の対応、旧スイートの廃止という順を見える形にするが、中央機関がすべてのシステムに一斉移行を命じられるとは主張していない。

並行公開で検証の時間を確保する

段階的な手順では、新方式を導入・試験している間も旧方式を本番で使い続けられる。フェーズ 0 は現行スイートだけの状態だ。フェーズ 1 は CA Ready 日に始まる。リーフ以外の CA は新方式の要求を処理できる必要があるが、RP は本番では旧方式を使い続ける。新方式のデータは試験用に公開でき、可能なら別の公開ポイントを使う。

フェーズ 2 は CA Go 日から始まる。署名済みデータの各セットに、両方のスイートによる版が必要となる。RP は旧版を維持しながら新版を試せる。RFC はタイミング差を考慮しつつ、ROA の経路起点認可データなど対応する出力が一致することを期待する。多くの CA が準備できていなければ日程を改訂する。RP の完全対応はまだ必須ではないが、検証の問題は次の節目を延期する理由になる。

フェーズ 3 の RP Ready 日には、すべての RP が新スイートを検証できる状態でなければならず、新版を優先するよう促される。両方の版は引き続き利用できる。フェーズ 4 は Twilight 日に始まり、RP と CA に新スイートが必須となる。旧版が残る場合でも完全性は保証されない。終了日には旧スイートを廃止し、信頼アンカーロケーターを公開ポイントから取り除く。RFC 6916、第 4 節・第 10 節

旧方式に戻れる期間には終わりがある。新製品をまだ検証できない RP も、旧製品が必須のまま利用可能な間はそれを使える。しかし、二つの版を永久に併存させる約束ではない。撤去前に比較と試験を行い、準備の遅れを見つけるための期限付きの重なりだ。RFC 6481

失敗の影響は発行側と検証側に及ぶ

RFC 6916 は両側の失敗を挙げている。旧スイートの終了後も移行を終えていない CA の署名済みデータは有効でなくなる。移行しなかった RP は新スイートの製品を検証できなくなる。結果として、RPKI から得られるルーティング情報の見え方が不完全になる可能性がある。

これはすべての経路が消えるという意味ではない。RP は検証結果を出し、その後にルーターや運用者が扱いを決める。オブジェクトの欠落や無効判定は経路起点検証に影響し得るが、実際のルーティング結果は各地のポリシー、ソフトウェア、対象資源に左右される。RFC は検証情報が欠けるリスクを述べており、障害規模を予測したり、一律の経路拒否を命じたりしていない。

数年を見込む慎重な日程には適用範囲の限界もある。RFC の要約は移行に数年を要すると想定し、緊急移行を定めていない。広い実装と公開の対応が必要な計画的変更には筋が通る一方、完了前に現在のアルゴリズムや鍵が危険になったらどうするかは別問題だ。RFC 6916 は危機対応の手順を示していない。

公式記録に残る Gagliano の役割

Cisco の公開プロフィールは Gagliano を Principal Solutions Engineer と記し、LACNIC、ANTEL、Sprint での過去のエンジニアリングおよびアーキテクチャ業務を紹介している。運用者、地域レジストリ、ベンダーにまたがる経歴ではあるが、特定の条項を支持した理由までは示さない。RFC から確実に言えるのは、Gagliano が合意文書を共同執筆し、RPKI 全体の準備を移行条件として扱ったことだ。Cisco の著者プロフィール

今回確認した RFC 7935 の現行アルゴリズムプロファイルは、2048 ビット RSA 鍵と SHA-256 を定める。2026 年には、後量子暗号の候補と並行公開や混合ツリーなどの移行方式を検討する情報提供用 Internet-Draft がある。著者は、RFC 7935 や RFC 6916 を更新するものではなく、本番プロファイルを選ぶものでも、評価対象を実運用に認可するものでもないと明記している。研究が始まったことは、本番移行の承認や日程を意味しない。RFC 7935；draft-yoshikawa-sidrops-pqc-rpki-02

RFC 6916 の長期的な価値は手順にある。「より強い方式を採用する」という目標を、CA の発行、公開ポイントの対応製品、RP の検証、準備が確認されるまでの旧経路維持という依存関係に分解した。同時に、準備度をどう測るのか、遅れた参加者をどう支えるのか、緊急事態を計画移行からどう切り分けるのかも残されている。次の判断は運用者と標準化に関わる人々に委ねられる。