要約

  • 現行の RIPE NCC RPKI Management API は、LIR が API アクセス鍵を用いて自らの認証局と ROA を管理する仕組みを説明している。
  • 2026 年第 3 四半期の計画では、RIPE NCC Access と統合した OpenID Connect ベースの鍵への置換は「Planned」であり、導入済みとはされていない。
  • 同じ計画は、提案された RPKI ビーコン用 API が RIPE NCC の全アドレス空間の ROA を編集できることになるため受け入れられなかったと述べる。これは現在の通常 API の機能を示すものではない。
  • アカウントの本人性、鍵の有効・無効と、ある ROA 変更に対するリソース単位の権限は、別々に検証すべき証拠である。

鍵があることと、変更の権限が分かることは違う

RPKI Management API の文書は、現在の対象範囲を限定している。LIR は API アクセス鍵で認証局と ROA を体系的に管理でき、リソース情報の取得、ROA の作成、アラートの設定などが説明されている。新しい鍵の値は作成時に一度だけ表示され、保存されるのはハッシュ値であり、不要になった鍵は失効させられる。

これはアクセス制御として重要だが、一件の変更の権限履歴ではない。鍵がアカウントに結び付いていても、その一事実から、どの証明書リソースが対象だったか、どの操作が求められたか、変更前後にどの ROA 状態があったか、実行結果は何だったかまでは導けない。「認証済みの呼び出しだった」を「限定された権限と状態遷移が立証された」と読み替えるのは危険である。

RIPE-843 も、この区別を支える。API 鍵は特定の RIPE NCC Access アカウントに関連付けられ、アカウントが無効化された場合、または利用者が関連アプリケーションのアカウント管理者でなくなった場合には無効化され得る。これはアカウントのライフサイクル規則であって、各リクエストのリソース権限を公開する台帳ではない。

計画中の本人性と、受け入れられなかった広い範囲

RPKI Quarterly Planning は、現在の RPKI API 鍵を RIPE NCC Access と統合した OpenID Connect ベースの鍵に置き換え、RPKI ダッシュボードで管理できるようにすることを計画している。公開状態は「Planned」である。配備日、最終的なトークン設計、変更イベントの公開形式は示されていない。

一方、同ページには明確な設計上の制約がある。提案された RPKI ビーコンは、その API が RIPE NCC の全アドレス空間の ROA を編集できることになり、受け入れられなかったため、まだ追加できていないという。この記述は、却下されたビーコン経路に限られる。通常の RPKI Management API に全空間書き込み機能があること、鍵の事故、不正な ROA、経路上の出来事を示すものではない。

だからこそ、OpenID Connect への移行を単なる認証方式の更新として完結させてはならない。アカウント連携と鍵管理の改善は価値がある。しかし、ある状態変更リクエストがどのリソースにどの操作を許されたかという別の問いには、それだけでは答えない。

公開するなら、範囲を絞った受領記録でよい

秘密鍵、プレフィックス、ASN、生の API リクエスト、設定を公開する必要はない。そうした開示はネットワークを露出させても、判断を十分に説明しない。必要なのは、限定的で検証可能な範囲の記録である。

重要な ROA 変更ごとに、アクセス方針と実装の版、秘密を含まない利用者またはクライアントの区分、アカウント文脈、限定された許可リソース集合または保護されたダイジェスト、要求操作、保護された変更前後の状態、認可と実行の時刻、結果、必要なら後続の公開観測、訂正・置換履歴を残すことが考えられる。これなら保有リソースを公開せずに、認可の形を保全できる。

これは記事上の設計提案であり、RIPE NCC の要件ではない。公開資料の記載が薄いことから内部統制がないと推論することもできない。ただし、将来の本人性方式、アカウントの存続状態、個別変更のリソース範囲は同じ事実ではない、という点は確認できる。

情報源