要約

  • RFC 9323は、リソース保有者がデジタルオブジェクトのチェックサム一覧に署名する仕組みを定める。
  • RIPE NCCは2024年にAPI対応を計画し、年次報告では保留と記載。2026年第4四半期の計画でも条件付きのままだ。

RSCの標準はほぼ4年前にできた。RIPE NCCのAPIは、まだ予定表の空席を待っている。

RPKI Signed Checklist（RSC）は、デジタルオブジェクトのチェックサムを並べ、特定のインターネット番号資源で署名する。署名を検証すれば、その資源の保有者が一覧を作ったと確認できる。RFC 9323は、Bring Your Own IPの受け入れやネットワーク間の物理接続で、資源保有の確認に使う例を挙げている。

RSCが答えるのは、特定のインターネット番号資源を持つ主体がこのチェックサム一覧を作ったか、という問いだ。BYOIPの受け入れやネットワーク間の物理接続では、受け取る側が自らの確認手順に組み込める検証可能な証拠になる。

RFCは運搬方法も決めていない。RSCはグローバルなRPKIリポジトリに置かれず、伝送方法は実装者に委ねられている。ウェブ画面、署名付きメール、別の経路で渡すこともできる。APIなら作成や管理の手間を減らせるが、APIはサービスの入口であって規格そのものではない。

RIPE NCCの予定表をたどると、話はかなり具体的だ。2024年の活動計画は、RSCとBGPSecをまずAPIで実装し、その後RPKIダッシュボードに統合する案を示した。同年の年次報告書では、この約束は「保留」。RSC、BGPSec、ASPAは2025年の計画に置かれた。

2026年第4四半期のRPKI計画でも、RSC APIは「予定」だ。実装はチームの余力と、二つの別作業の進み具合に左右される。一つはAPIキーとOpenID Connect、もう一つは組織全体のISO 27001監査と新たなSOC 2 Type II監査を含むコンプライアンス対応だ。ダッシュボードの画面は需要を見て後から作る可能性がある。計画には公開時期も、遅れの単独原因も記されていない。

差があるのは、規格の完成と、運用担当者が日々使えるサービスの間だ。公開資料は、他のツールや経路でRSCが何件使われているかを示していない。分かるのは、RFCとホスト型サービスの時計が同じ速さでは進んでいないことだ。

BYOIPや相互接続を準備するチームは、APIを利用可能な前提にせず、証拠の受け渡しと確認手順を今の計画に残しておきたい。将来APIが出ても、署名が何を示すか、相手先が誰なのかは別々に確かめる。

RFCはできた。残るのは日付と画面、そして実装に充てるチームの時間だ。

出典