要約

  • 2026年９月17日更新のRIPE NCCのRPKI四半期計画では、OpenID ConnectとAPIキーの見直しが第１項目、監査・適合性が第２項目である。Resource Signed Checklist（RSC）のAPI対応は、両項目の進捗に応じて人員に余裕があれば実施する計画にとどまる。利用画面はさらに後の需要を見て判断する。
  • 2024年５月のRouting WG向け報告は、ASPAの後、またはその標準化が遅れた場合には先に、RSCをAPIと画面で署名できるようにする構想を示した。過去の計画にはRPKI-2024#01として調査対象の要望が残る。いずれも確定納期ではない。
  • RFC 9323は、番号資源に制約された署名で複数ファイルのハッシュを束ねるRSCを定める。ただし、そのオブジェクトを世界共通のRPKIリポジトリに流してはならない。将来APIが署名しても、ファイルの受け渡し、相手方による検証、取引上の承認は別に残る。
  • 確認した公開資料から、RIPE NCCの一般利用可能なRSC署名API、開始日、障害や被害を認定することはできない。ソフトウェア部品が関連拡張を認識できる事実も、本番サービスの提供証拠ではない。

先に出来上がったのは規格だ

RSCは、実在しない技術への要望ではない。2022年に公開されたRFC 9323は、特定のIPアドレスやAS番号の範囲と、送付する文書のハッシュを一つの署名オブジェクトに結び付ける。たとえば自分のアドレスをクラウドに持ち込む際、事業者が受け取ったファイルと署名対象のファイルが一致するかを確かめられる。単なる転送可能な承諾書より、限定された事実を強く確認できる。

しかし、規格はRIRの製品一覧ではない。RIPE NCCの現行計画が示すのはむしろ順序の制約である。RPKI Dashboardの認証をRIPE NCC AccessのOpenID Connectへ移し、現在のRPKI APIキーをSSOに統合したキーへ置き換える作業が進む。組織全体のISO 27001監査と、５月に始まった新たなSOC 2 Type II監査も進行中だ。その後の項目に置かれたRSCは、開発余力が生じた場合のAPI対応であり、画面は需要が確認されれば検討するという書き方になっている。

先行作業に理由はある。新しい署名機能には、誰がどの認証情報で、どの番号資源について要求できるかという境界が要る。署名を扱うサービスへの監査も、単なる飾りではない。だからといって、理由のある優先順位を、すでに使えるエンドポイントと取り違えてよいわけではない。顧客への提供日を決める側は、今の資料に公開されたRSC API仕様や開始日がないことを前提に設計すべきだ。

昔の構想を今日の約束にしない

期待がどこから生まれたかは追える。2024年のRouting WG向けメールでRIPE NCCは、資源保有者が提供事業者からのチャレンジを署名するような用途を説明した。ASPA対応を先に進めた後、RSCのAPIとDashboardに着手する案も示した。ASPAのIETFにおける最終審査が進まなければ、順番が早まる可能性まで述べている。後のアーカイブでは、RSCは調査と回答を要するコミュニティ提案として記録された。

2026年の計画は、その構想をより狭い形で記している。先行する認証・監査の進捗、チームの余力、APIからの実装、需要を見た画面という順番だ。これは「２年遅れた製品」の証明ではない。2024年の提案に納期はなく、過去の項目は納品完了を示していない。比較から言えるのは、利用を検討する側が依拠できる計画の範囲が変わったということだけである。

現在のRPKI Management API文書は、LIRがAPIキーを使って認証局とROAを管理する方法を示す。一般公開されたRSC作成操作の仕様ではない。内部試験の有無を断言する材料にもならない。rpki-commonsの変更履歴には2024年にRSC関連の拡張を認識する初期対応があるが、オブジェクトを読めるライブラリと、会員に発行する運用サービスも同じではない。

公開リポジトリに載らない署名

RSCがRPKIの証明書を用いるため、ROAと同じ公開経路を想像しやすい。2024年のメールにも、チェックリストがRPKIに「公開」されるように読める広い説明が一度出てくる。ところが同じ文書は後段で、RSCは世界のRPKIリポジトリに置かず、署名者と検証者の間で交換すると明記する。RFC 9323もその方式を規定し、署名に用いる一回限りの証明書からリポジトリの所在を示す拡張を除く。

この違いは、APIの完了条件を変える。ROAは経路起点の検証に使われるよう配布される。一方RSCは、特定の相手に渡すファイル群を署名した証拠だ。要求者は署名済みの.sigを取得し、対象ファイルとともに渡さなければならない。受け手は証明書の経路、資源の範囲、ハッシュの一致を確かめ、さらに自分の契約や審査手続に照らして採否を決める。APIが正常応答を返しただけでは、そのどれも自動的には終わらない。

将来APIを画面より先に提供するなら、開発者には要求形式だけでなく、権限の単位、成果物の取得方法、期限や失効に関する扱い、検証可能な試験例が必要になる。現行の計画にそれらがないのは、未完成の公開計画から勝手に仕様を補えないという意味であり、欠陥が発見されたという意味ではない。

暗号学的な合格と業務の合格

RFC 9323は、チェックリスト中の情報が署名者自身の主張であり、検証者は発行元の認証局を操作できた以上の人物像を推定してはならないと注意する。ファイルが一致しても、会社の法的な代表権、アドレスの所有権、内容の真実や移転の承認まで検証できるわけではない。RIPE NCCの古い計画に「ASNの所有権の証明」という例があっても、それは法的権原の判定をRSCに移す文言として読めない。

BTWには、この証明の限界を扱う既存記事がある。本稿が問うのは、RIPE NCCのサービスとしてどこまでが準備段階にあり、いつ実際に利用可能と言えるかだ。現在確認できるのは、二つの先行作業が進行中で、RSCのAPIは人員に余裕がある場合の計画、画面は需要次第、という範囲である。署名の生成や取引の結果を報告する段階にはまだない。

出典