概要

  • 委任型 RPKI では、リソース保持者が子認証局を運用し、その秘密鍵を管理する。親 RIR は依然として保持者のリソース範囲を認証し、適用可能なルールに基づいて子証明書を交換または失効させることができる。鍵の管理は職務分離であり、割り当て階層からの独立ではない。
  • 標準はシステムを管理可能な関係に分割する。RFC 6492 は親子間のプロビジョニングをサポートし、RFC 8181 は署名 CA とは別のサービスによる公開をサポートする。証明書および鍵ロールオーバーの標準は継続性を支える。相互運用性は不可欠である。なぜなら、単一のプロプライエタリクライアントに依存する自律性は脆弱だからだ。
  • 正式なサービスオプションが必ずしも利用可能な権利とは限らない。適格性、契約、アカウント権限、ソフトウェア適合性、公開アクセス、テスト設備、サポート、コスト、ドキュメントが、実際に委任を行使できるかどうかを左右する。
  • 移行こそが決定的なテストである。現在の地域的取り決めは異なる：一部の文書化された移行ではホスト型と自己運用サービスを並行して運用できるが、他方では委任 CA を作成する前にホスト型 CA を失効させる必要がある。回避可能な中断によってのみ行使できる選択肢は、弱い選択肢である。
  • 鍵を保持することは義務を伴う。委任された運用者は署名素材を保護し、最新のマニフェストと失効リストを発行し、公開を維持し、外部検証を監視し、承継アクセスを確保し、侵害に対応しなければならない。委任は、利用可能なツールとサポートを提供せずに責任だけを転嫁すべきではない。
  • ハイブリッド公開は鍵管理とリポジトリ可用性を分離できる。多くの場合、運用者にグローバルリポジトリの公開を要求せずに、意味のある署名制御を提供するが、親または公開プロバイダへの依存は残るため、明確なサービスと離脱条件が必要である。
  • ペナルティのない選択は、単なる価格の同一性以上のものを意味する。委任ユーザーは同等の適格性、情報、インシデント対応、レビュー、移行支援、会員資格を保持すべきである。プロバイダは透明性のあるコストベースの料金を請求したり、中立的な安全ルールを課したりできるが、自己管理を下位の制度的地位にしてはならない。
  • 番号資源協会は権利義務マトリクス、適合性演習、移行リハーサル、証拠に基づく会員提唱で支援できる。秘密鍵の所持をリソースの所有権または正当な親の措置からの免除と宣伝すべきではない。

鍵を保持する者を証明するが、全ての権限を保持する者を証明するわけではない

ネットワークセキュリティチームが、自ら管理するインフラストラクチャに認証局ソフトウェアをインストールする。ソフトウェアはローカルで鍵ペアを生成する。秘密鍵は組織外に出ない。チームは子リクエストをエクスポートし、地域インターネットレジストリに送信し、親レスポンスを受け取り、関係を完了する。子 CA はリソース証明書を要求し、経路起点認証（ROA）を作成し、署名付きオブジェクトを公開する。

これが最も明確な形での委任型 RPKI である。RIR のホスト型サービスではなく、運用者がその子鍵が署名するタイミングを決定する。親がその秘密鍵を使って子の署名を持つオブジェクトを作成することはできない。運用者は独自のハードウェア制御、承認ルール、監査記録、自動化、承継の取り決めを適用できる。

しかし、証明書は親から効力を得ている。RIR はどの番号資源が子証明書の範囲に含まれるかを認証する。正当な手続きの後にリソースが移転、返却、または削除された場合、親はより狭い範囲の証明書を発行するか、子証明書を失効させることができる。検証者は、受け入れられた地域トラストアンカーから有効なチェーンが届くために運用者の ROA を受け入れるのであって、秘密鍵の所持が独立した権限を生み出すからではない。

この違いは政治的な言葉の中では見失われやすい。提唱者は委任型 RPKI を「主権」と呼ぶかもしれない。ホスト型プロバイダは、親が依然として範囲を制御するため、ローカル鍵管理はほとんど変わらないと示唆するかもしれない。どちらの立場も実際の職務分離を平坦化している。

鍵管理が重要なのは、ホスト型プロバイダだけが保持者の経路意図を表明できる唯一の当事者になることを防ぐからである。運用者は認証を自身のネットワーク制御と統合し、何に署名したかの独立した記録を保持できる。緊急の経路変更時に地域のウェブインターフェースへの依存を減らすことができる。複数の親関係の下での子の委任や統合管理をサポートできる。

親の権限が重要なのは、RPKI がリソース証明書の階層であるからだ。以前の保持者が古い秘密鍵を保持するだけで、移転されたプレフィックスを認証し続けることはできない。侵害されたり、持続的に機能不全の子が、結果にかかわらず無期限の認証を要求することはできない。委任には発行、範囲変更、失効、回復のルールが必要である。

したがって、制度的な問いは「誰が鍵を持っているか？」だけではない。保持者が信頼でき、相互運用可能で公正な条件の下で署名の役割を選択し行使できる一方、親が宣言された手続きを通じてより狭い権限を行使できるかどうかである。利用可能な権利は、鍵ファイルの内部だけではなく、その関係の中に存在する。

ホスト型の利便性と委任型の制御は異なるニーズに応える

ホスト型 RPKI は経路認証をアクセス可能にした。メンバーは RIR サービスに認証し、プレフィックスと起点 AS を入力すれば、プロバイダが鍵生成、オブジェクト署名、更新、マニフェスト、CRL、リポジトリ公開を処理する。多くの小規模ネットワークにとって、これが RPKI を導入するかどうかの分かれ目である。

委任型運用は重要な義務を保持者に移す。運用者は子 CA を実行し、鍵を保護し、親と通信し、署名付きオブジェクトを作成し、自身で公開サービスを実行するか選択する。マニフェストと失効情報を最新に保ち、ソフトウェアやインフラの障害から回復しなければならない。

どちらのモデルも本質的に優れているわけではない。安定した経路を2つ持つ小規模な自治体ネットワークは、よく運用されたホスト型サービスを合理的に選ぶかもしれない。自動経路変更、下流顧客、成熟した鍵管理を持つ大規模なマルチ RIR キャリアは、当然委任を必要とするだろう。大学や公共サービスコンソーシアムは、機関の管理とリポジトリの回復力のバランスとして、ローカル鍵と親公開を選択するかもしれない。

選択が政治的に重要になるのは、ホスト型の利便性を提供するプロバイダが、同時に親権限者でもあるからだ。これは、不満を持つ顧客が地域リソースの認証を無関係なベンダーに移せるような競争市場ではない。サードパーティは CA ソフトウェアや管理運用を提供できるが、証明書パスは依然として適切な親に接続しなければならない。

したがって、ホスト型サービスの存在は委任オプションを強化すべきであり、排除すべきではない。負荷の少ないデフォルトは広範な採用に寄与する。実用的な委任の離脱は集中を抑制し、異なるリスクを持つ運用者に応える。移動が可能で責任が明確であるとき、モデルは相互補完的となる。

利便性だけが現実的にサポートされる唯一の道になるときに問題が生じる。委任がサービスページに記載されていても、不明瞭な手動交換、サポート外のソフトウェア、事前告知のない中断、専門家の連絡先、契約上の不確実性を伴うことがある。形式的な選択肢は存続するが、例外的な関係を持つ運用者だけが安全に使用できる。

逆の問題も存在する。自己運用だけが尊重すべきモデルであるかのように扱うと、それを遂行できない組織に複雑なセキュリティ義務を転嫁する。弱いアクセス制御の下で保持された鍵と期限切れのリポジトリは、いかなる意味でも自律的ではない。それは当該保持者の経路証拠を劣化させ、他者の検証作業を増やす。

正当な目標は、情報に基づくペナルティのない選択である。ホスト型ユーザーはプロバイダが何を制御するかを知るべきだ。委任型ユーザーは自分が何を制御し、何が親に残るかを知るべきだ。それぞれが、能力とリスクの進展に応じてモデルを変更する安全な経路を持つべきである。

オープンプロトコルは約束を相互運用可能な選択肢に変える

もし全ての RIR がプロプライエタリな子を要求したら、委任は脆弱だろう。IETF 標準は共通の運用文法を提供する。

RFC 6492 は親と子 CA の間のプロビジョニングプロトコルを定義する。子は自己の資格を列挙し、認証された交換を通じて証明書を要求し、失効を要求できる。親は定義されたプロトコルの中で応答し、全ての実装が地域のウェブセッションを再現することを強制しない。標準は、親がなぜリソースを割り当てるか、いつ契約上の紛争が措置を正当化するかは決定しない。標準は、権限が確立された後の証明書関係を相互運用可能にする。

RFC 8181 は公開を署名から分離する。委任された CA は認証された公開プロトコルを通じて、署名付き素材をリポジトリサーバーに送信できる。これによりハイブリッドな配置が可能になる：運用者は署名鍵を保持し、RIR または別のプロバイダがグローバルに利用可能なリポジトリを運用する。役割を分離することで、鍵を明け渡すか、単独ですべての公開サービスを運用するかの偽りの二者択一を減らす。

他の RPKI 標準は、証明書プロファイル、マニフェスト、失効リスト、ロールオーバー手順を定義する。それらは独立系ソフトウェアプロジェクトに安定したターゲットを提供する。運用者は、親だけが提供するバイナリをインストールするのではなく、メンテナンスされた CA 実装を評価できる。

標準はユーザビリティを保証しない。二つの製品がサポートを主張しながら、プロファイル、タイミング、アイデンティティ交換、子処理、障害復旧で異なる場合がある。地域の親はコアな交換には準拠しながら、オンボーディングを手動チケットに依存させることがある。公開サーバーは標準メッセージを受け付けながら、明確な能力やインシデント条件を示さないことがある。

したがって、利用可能な自律性には適合性の証拠が必要である。RIR はサポートするプロトコルバージョン、プロファイル、アルゴリズム、エンドポイントの動作、サイズ制限、更新の期待、廃止スケジュールを公開すべきだ。エコシステムが許す限り、複数のメンテナンスされた子実装に対してテストを行い、再現可能な結果を公開すべきだ。ソフトウェアプロジェクトは複数の親に対してテストすべきだ。

変更はペースを守らなければならない。親は、委任運用者がアップグレードしリハーサルするのに十分な時間をもって、プロトコルやプロファイルの廃止を告知すべきだ。緊急セキュリティ変更にはより迅速な対応が必要かもしれないが、互換性計画、直接通知、事後レビューを含めるべきだ。運用者は、証明書更新時に、以前は準拠していた自分の子がもはや受け入れられないと発見すべきではない。

オープン標準はまた、制度の記憶を保護する。スタッフは変わり、ベンダーは姿を消し、コミュニティソフトウェアは引退しうる。要求、応答、オブジェクトが文書化された形式を使用していれば、後継チームは関係を再構築し、ツールを移行できる。自律性は、一人の管理者の私的な記録に依存しにくくなる。

したがって、鍵を保持する権利は、標準適合の子を使用する権利と不可分である。相互運用性がなければ、私的な管理権は異なる錠前のついたプロプライエタリな囲い込みになりかねない。

ウェブページ上の掲載は平等な利用可能性ではない

地域サービスの説明は委任型 RPKI が存在することを示しているが、アクセス条件は異なる。ARIN はホスト型・委任型の展開とリポジトリ公開オプションを説明している。RIPE NCC は適格メンバーと特定のエンドユーザーに委任 CA を許可し、自己公開と公開サービスの両方を文書化している。APNIC は長く自己運用の子と親公開をサポートしてきた。LACNIC は、委任サービスが 2019 年 12 月からメンバーに利用可能であると述べ、関心のある組織は hostmaster に連絡するよう求めている。

これらは意味のあるコミットメントである。これらは、複数の地域で自己管理が単に理論上のものではないことを立証する。しかし、全ての契約カテゴリの全ての保持者が同等の条件でそれを取得できることを証明するものではない。

適格性が最初のテストである。直接メンバーには明確な道があるかもしれないが、スポンサー付き、プロバイダ非依存、レガシー、国別レジストリのユーザーは別の機関に依存する。RIPE サービス地域では、プロバイダ非依存およびレガシーエンドユーザー向けの文書が、直接またはスポンサー付きのアクセスを特定の契約およびアカウント維持者の関係に結びつけている。APNIC 地域では、国別レジストリが追加の親レイヤーを形成できる。正しい権限パスは実際のリソースと合意に従う。

第二のテストは発見可能性である。メールを必要とするサービスでもうまく機能しうるが、ユーザーには公開された適格性、期待される応答、技術的前提条件、条件、エスカレーションが必要である。説明のない手動の門は、拒否がポリシー、能力、または誤解を反映したものかを知ることを難しくする。

第三のテストは同等性である。委任ユーザーはホスト型ユーザーと同じ適格リソースの証明書を取得できるか？リソース変更の同じ通知を受け取るか？親公開を利用できるか？テストサービスはあるか？インシデントは同じ運用チームによって処理されるか？メンバーポータルは失敗した交換を診断するのに十分な状態を示すか？

第四のテストは実際のコストである。運用者はローカル CA のセキュリティと人員を適切に負担する。追加のプロバイダ料金は、特に管理公開やサポートのような異なるサービスを反映する場合には正当化されうる。しかし、コストは公開され、予測可能で、サービスと結びついているべきだ。単にメンバーがホスト型鍵管理を断ったために課される不透明な上乗せ料金は、平等な選択の主張を弱めるだろう。

現在、全ての地域にわたって、どれだけの適格保持者が委任を要求し、受け入れられ、セットアップを断念し、移行に失敗し、ホスト型サービスに戻ったかを示す共通の分母は存在しない。したがって、利用可能性は公開された権利と再現可能なユーザージャーニーから評価されるべきであり、作り出されたグローバル導入率からではない。

普通の適格な運用者が、それを発見し、理解し、適合するツールで完了でき、阻止された場合に合理的な回答を得られるとき、サービスオプションは平等になる。それ未満は依然として有用かもしれないが、まだ強固な権利ではない。

移行こそが名目上の選択と運用上の結果が出会う場である

既にホスト型 RPKI を使用している運用者は、単に委任のサインアップページを指し示すだけでは、その自由を証明できない。意図した経路が有効な認証を失う回避可能な期間なしに、経路認証をホスト型鍵からローカルの子に移動できなければならない。

移行には複数の状態がある。運用者は現在の ROA と意図する経路を棚卸しする。ローカル CA を確立し、その鍵を保護する。親と子がアイデンティティを交換する。公開関係が設定される。親が証明書を発行する。子が置き換えのオブジェクトを公開する。独立したバリデータがそれらを観測する。ホスト型オブジェクトが廃止される。監視が期待される結果を確認する。

順序付けは難しい。なぜなら、移行中、二つの CA が重複するリソース範囲を主張しうるからだ。RPKI 証明書ポリシーは不正な重複を防止しなければならず、親のシステムは一度に一つのメンバー CA モードだけをサポートするように設計されているかもしれない。しかし、厳格な break-before-make シーケンスはギャップを生みうる。委任された子が公開できる前にホスト型 CA を失効させることは、検証者が一時的に空の認証を見るか、キャッシュがリフレッシュされるにつれて不整合な状態を見ることを意味する。

現在の文書は地域差を示している。RIPE NCC の委任セットアップページは、既存のホスト型ユーザーに対し、委任 CA を追加する前にホスト型 CA を失効させ、最初にテスト環境を使用するよう推奨している。APNIC はヘルプデスク支援によるホスト型と自己運用の並行サービスを移行プロセスとして説明してきた。ARIN は展開オプションを変更するユーザーに対し、Registration Services と協力するよう指示している。これらは同等の経験ではない。

並行運用は自動的に安全ではない。親は、重複が意図的で、短期間で、監視され、移転後に権限を保持できないことを保証しなければならない。置き換え ROA は同じ検証された経路意図を反映すべきだ。make-before-break の機能は制御された移行状態であるべきで、恒久的な重複資格ではない。

並行認証が提供できない場合、プロバイダは事前検証を通じてギャップを最小化すべきだ。ホスト型 CA を失効させる前に、子のアイデンティティ、鍵、ソフトウェア交換、公開関係を検証できる。承認された経路意図データを準備し、運用スタッフが立ち会う中で切り替えをスケジュールできる。子が失敗した場合のホスト型サービスへの緊急復帰を定義できる。

移行記録は、期待される有効性の遷移と実際の観測を述べるべきだ。「新しい CA が作成された」は完了ではない。完了は、現在の署名付きオブジェクトが新しいパスを通じて検証され、意図する経路が期待されるステータスを持ち、古い権限が安全に廃止され、保持者が永続的な記録を保持することを意味する。

移行サポートは単なる礼儀の追加ではない。それは、回避可能な到達性リスクで代償を払うことなく権利を行使できるかどうかを決定する。新規ユーザーに対してのみ自己管理をサポートする機関は、将来のための選択肢を作った一方で、現在のホスト型ユーザーを事実上閉じ込めている。

テスト環境は危険な境界を再現しなければならない

委任運用は、本番の経路意図を運ぶ前にリハーサルされるべきである。テスト用の親は、運用者がライブ認証に影響を与えることなく、アイデンティティ交換、プロビジョニング、証明書発行、公開、オブジェクト検証、ロールオーバー、回復を学ぶことを可能にする。

環境は、その差異が明示されている場合にのみ価値がある。テストサービスは親公開を省略したり、異なるトラストアンカーを使用したり、アカウント適格性を簡略化したり、本番のインシデントパスを欠いたりするかもしれない。例えば、RIPE NCC のテスト文書は、その委任テスト親が現在サービスとしての公開をサポートしていないと警告している。これは有用な正直さである；それはまた、テストが本番のハイブリッド構成全体を検証できないことを意味する。

プロバイダは、テストと本番を比較する機能マトリクスを公開すべきだ。運用者は、どのプロトコルバージョン、リソース構造、レート制限、公開モード、失効アクション、アラートが同等であるかを知る必要がある。テスト結果がグリーンだからといって、欠けていたコンポーネントについての保証を含意すべきではない。

テストは登録だけでなく障害もカバーすべきだ。子鍵が利用不能になり、承認されたメカニズムから回復させる。鍵をローテーションする。マニフェストの期限が迫るのを許す。公開を中断する。認証された範囲を変更する。不正な形式のリクエストを拒否する。子を失効させ再確立する。スタッフの承継をシミュレートする。各演習は、別の管理者が理解できる証拠を残すべきだ。

移行リハーサルは特に重要である。本番が委任作成前にホスト型失効を要求するなら、テストはギャップへの運用者の準備とプロバイダの応答を測定すべきだ。本番が重複を許すなら、テストは重複範囲がどのように制限され終了されるかを示すべきだ。

適合性スイートはこれらの演習を再現可能にできる。それらは本番の資格情報を露出することなく、期待されるメッセージと結果を公開すべきだ。独立した CA プロジェクト、RIR、運用者は同じケースを実行できる。失敗は、どちらかが他方を非難する噂話ではなく、対応可能な相互運用性レポートとなる。

テストにはガバナンス効果がある。それは親や専門ベンダーの情報優位を減らす。メンバーは、委任義務を受け入れるための人員、ツール、手順を持っているかどうかを判断できる。また、拒否や失敗が自社のソフトウェア内部ではなく、サービス境界で生じていることを実証できる。

いかなるテストも、全てのリポジトリ、バリデータ、ネットワークポリシーを再現することはできない。結果は準備の証拠であり、経路受け入れの保証ではない。しかし、本番前にリハーサルできない権利は、不必要に危険であり、特に初めてそれを行使する小規模事業者にとってはそうである。

公開機能は分離可能であり、それが自律性の計算を変える

CA の運用とリポジトリの運用は異なる機能である。CA は秘密鍵を保護し、証明書、マニフェスト、失効リスト、経路認証に署名する。公開サービスは、グローバルに到達可能なメカニズムを通じて、現在の署名済み素材を依拠当事者が利用できるようにする。

運用者は鍵管理はできても、可用性の高い公開リポジトリを運用する意欲がないかもしれない。リポジトリはネットワーク停止、DDoS 攻撃、ストレージ不整合、古くなったオブジェクト、プロトコル互換性の要求に直面する。小さなローカル CA は、その公開配布ポイントが脆弱な一方で、安全であり得る。

RFC 8181 が分離を可能にする。子はローカルで署名し、認証されたプロトコルを介してオブジェクトを公開サーバーに提出する。ARIN は委任ユーザー向けに Repository Publication Service を提供している。APNIC は自己運用 CA 向けに親公開をサポートしている。RIPE NCC は委任 CA 向けに公開をサービスとして提供している。このハイブリッドは、多くの能力ある保持者にとって強力なデフォルトになり得る。

この構成は意味のある自律性を保持する。RIR は、オブジェクトを公開するというだけでは、子の署名鍵を所有することにはならない。宣言されたプロトコルと認証チェックに従って公開メッセージを受け入れるか拒否すべきであり、署名付きコンテンツを書き換えるべきではない。運用者は自身のオブジェクトと要求履歴を保持できる。

依存は残る。親公開サービスが利用不能になったり、子の素材を削除したりすれば、依拠当事者は最終的に有効な現在のオブジェクトへのアクセスを失う可能性がある。公開プロバイダは、子の署名を偽造することなく害を引き起こすことができる。したがって、サービス条件、可用性設計、インシデント通知、証拠、離脱は重要である。

自己公開は、その能力と理由を持つ運用者にとって依然として正当な選択肢である。親は、委任管理を単に便利に保つためだけに、そのリポジトリを要求すべきではない。自律性のレトリックが、全ての子にグローバルな検索サーフェスへ別の脆弱な公開ポイントを追加するよう圧力をかけるべきでもない。

公開サービス間の移行は、CA 間の移行と同様の注意を必要とする。リポジトリ URI は証明書に埋め込まれており、依拠当事者はキャッシュされた状態を観測する。運用者と親は、標準とソフトウェアの動作に従って、新しい公開を準備し、検索を検証し、古い場所を退役させるべきだ。公開の離脱が署名鍵の放棄を要求するべきではない。

有用なポリシーはモジュール選択である：ホスト型署名とホスト型公開；委任署名と親公開；または委任署名と独自運用公開、技術的に正当化されるルールに従う。各モジュールは、その運用者、義務、条件、証拠、回復を特定すべきだ。

鍵の自律性は、鍵保持者に無関係な運用負担を強制しないとき、より強力になる。分離は、機関が責任を最もよく担える当事者に割り当てることを可能にする。

鍵を保持することは積極的な義務を生む

義務なき権利は、それが改善しようとするエコシステムそのものを危険にさらすだろう。委任運用者は、そのままでは古くなったか不正な形式の出力が依拠当事者のリソースを浪費し、自身のオブジェクトを無効にし、診断を複雑にする認証機能を制御する。

第一の義務は鍵のセキュリティである。アクセスは制限され、認証され、記録されるべきだ。高いインパクトの署名には複数の承認役割が必要かもしれない。バックアップは暗号化され、テストされ、一人の管理者が組織を離れることから保護されるべきだ。運用者は、侵害された鍵を、侵害された環境に依存せずに失効させ、置き換える方法を知らなければならない。

第二の義務は、オブジェクトの新鮮さと内部一貫性である。マニフェストと失効リストは期限切れになる。証明書は更新が必要である。公開されたオブジェクトは現在の証明書範囲に対応しなければならない。自動化は助けになるが、CA の外部から監視されるべきだ。「公開済み」と表示するダッシュボードは、リポジトリ結果の独立検証よりも弱い。

第三の義務は公開の可用性である。運用者が自己公開する場合、グローバルに取得可能な現在の素材と回復力のあるプロトコルサービスの負担を受け入れる。親公開を使用する場合、認証された公開関係を維持し、受信確認を監視しなければならない。配信をアウトソーシングしても、それを検証する必要性は取り除かれない。

第四の義務は経路意図との整合である。ローカルな鍵管理は自動化を可能にするが、自動化は失敗をより速く署名しうる。CA は意図された BGP 経路と予定される認証を比較し、可能な限り完全一致を使用し、広範な変更にはレビューを要求し、履歴を保持すべきだ。

第五の義務は連絡先と承継である。親の通知は活動的なチームに届かなければならない。緊急連絡先は人事異動を生き残るべきだ。合併、倒産、アウトソーシングされたネットワーク移行には制御された引き継ぎが必要である。合法的にも技術的にも誰も操作できない鍵は、保護された自律性ではない。

地域ポリシーは、ルールが予見可能で比例している限り、最低限の衛生を強制できる。2025年に公開された RIPE-847 は、その一つの境界づけられた例を提供する：RIPE NCC が委任 CA の現在のマニフェストと失効リストを 3 か月以上発見・検証できない場合、合理的な発見と通知努力の後にリソース証明書を失効させることになっている。このポリシーは、短い不完全性ではなく、持続的に機能しない CA を対象としている。

そのルールは相互的義務を示している。運用者は機能する子を維持しなければならない。親は公開された閾値を使用し、現在の素材を探し、通知を提供しなければならない。失効は、委任を選択したことへの罰としてではなく、検証に負担をかける持続的失敗への応答として位置づけられる。

委任された権利は、その義務が等しく明確であるとき、より正当性を増す。そうすれば保持者はインフォームドコンセントをもって選択でき、親は自己管理を推定上有罪と扱うことなく、真のエコシステムの害に対処できる。

ペナルティのない選択は価格よりも広範な概念である

ある RIR がホスト型と委任型で同じ会費を請求しても、委任を罰則的なものにしうる。平等な扱いには幾つかの次元がある。

適格性は、単に保持者が自身の鍵を選んだという理由だけで縮小されるべきではない。ただし、技術的または契約上の関係が真に異なる場合を除く。親は、同じ登録ルールを適用した後、同じ現在のリソース範囲を認証すべきだ。無関係なサービスを、署名管理権の放棄を条件にしてはならない。

サポートは同一ではなく公平であるべきだ。ホスト型ユーザーはポータル操作の助けを必要とし、委任型ユーザーは親との交換、証明書の状態、公開に関する助けを必要とする。RIR は全てのサードパーティインストールをデバッグする必要はないが、エラーが自社のエンドポイントで発生したかどうかを特定し、診断情報を公開し、エスカレーション経路を維持すべきだ。争点となっているコンポーネントが親自身のサービスである場合、「自己ホスト型のためサポート対象外」では不十分である。

情報は同時に届くべきだ。委任運用者は、証明書に影響する登録変更、プロトコル廃止、トラストアンカー作業、サービスインシデント、ポリシー提案の通知を必要とする。親のアクションが自らの範囲を変更したことを、依拠当事者のアラームから学ぶべきではない。

インシデントアクセスも平等であるべきだ。委任ユーザーは緊急の再発行や親のレスポンス確認の助けを必要とするかもしれない。プロバイダは強力な本人確認を要求できるが、単にホスト型チームの方が馴染みのツールを持っているという理由で、自己管理を低優先度のキューに置くべきではない。

レビューと救済は管理に従うべきだ。保持者はその鍵と子の出力に責任がある。親は正確な資格、プロトコル運用、および子証明書に対して取る行動に責任がある。契約は、委任を用いて親が管理する全ての障害を免責すべきではない。逆に、委任運用者は、メンテナンスされていない自身のリポジトリに起因する損失を RIR が保証することを期待すべきではない。

価格設定はコストを反映できる。専門的な公開や支援付き移行サービスはリソースを消費しうる。料金は公開され、関連するガバナンスプロセスを通じて承認され、ユーザーをホスト型管理に誘導するために設計されたものではなく、サービスに合理的に関連づけられるべきだ。公共の利益に資するネットワークに能力が不足している場合、料金免除や共有支援が適切かもしれないが、補助金の決定は透明であるべきだ。

会員としての地位は手つかずのままにしておかねばならない。委任 CA を選択しても、議決権、ポリシー参加、登録サービスへのアクセス、またはその保持者が責任ある会員であるという推定を減じてはならない。セキュリティインシデントは、中央の運用だけが安全だという文化的信念ではなく、証拠に基づいて判断されるべきだ。

ペナルティのない選択は、失敗の結果がないことを意味しない。中立的な安全ルール、コストベースの料金、比例的な失効は適用できる。試金石は、同じ正当な目的が、必要以上に鍵の自律性に負担をかけることなく達成できるかどうかである。

失効権限には理由と回復経路が必要である

委任は、親が子証明書を失効させる能力を取り除かない。その権限は、鍵が侵害されたとき、リソースが保持者を離れるとき、証明書が正式な登録と不整合になったとき、または持続的に失敗した子が運用上の害を課すときに必要である。

その権限はまた、秘密鍵の自律性の限界を定義する。保持者は子鍵と全てのバックアップを保有しているかもしれないが、親のパスが失効すれば、その署名は検証されなくなる。したがって、この境界における手続き上の保護は不可欠である。

親は有限の失効クラスを公開すべきだ。セキュリティ侵害、認証された保持者要求、完了したリソース移転、適格なサービス関係の期限切れ、拘束力のある法的要件、および持続的な技術的失敗は、理解可能なクラスである。広範な「運用上の理由」は、閾値、承認者、レビューによって裏付けられるべきだ。

通知は緊急性に合わせるべきだ。確認された鍵侵害は即時の行動を必要とするかもしれず、資格が残っている場合にはクリーンな鍵の下での迅速な再登録が続く。計画された移転はスケジュールされた切り替えを用いることができる。技術的失敗ルールは、観察期間、連絡試行、治癒期間、最終通知を提供できる。経路セキュリティと無関係な管理上の紛争は、証明書行動の前に慎重さを要する。

理由は、運用者が応答できる十分な詳細さで与えられるべきだ。プロトコルエラーは失敗した交換を特定すべきだ。リソース範囲の変更は登録イベントを特定すべきだ。機密の法的資料は開示制限を必要とするかもしれないが、秘密がデフォルトになってはならない。

レビューは救済策を生み出せるものでなければならない。経路が有効な認証を失ってから数ヶ月後に審理される上訴では不十分である。システムは、誤った親の行動を正すことができる緊急技術レビューを必要とし、その後に事実や権限がなお争われている場合には、より完全な制度的レビューが必要である。

また、戻る道がなければならない。子鍵が安全で、親が誤って行動した場合、復旧は正しい証明書を再発行し、既存のオブジェクトを検証できる。子鍵が侵害された場合、プロセスはクリーンな子を確立すべきだ。運用者が失敗した場合、治療は現在のマニフェスト、修正された公開、またはホスト型サービスへの移行を必要とするかもしれない。救済策は原因に適合すべきだ。

監査記録は、要求、理由、証拠クラス、承認、通知、証明書行動、公開効果、復旧を保存すべきだ。公開報告は、私的なトポロジーを開示することなく、日常的なイベントを集計し、深刻なプロバイダの失敗を記述できる。

親の権限の正当性は、その効果を否定することから来るのではない。それは、予測可能で、レビュー可能で、修復可能なルールを通じてその効果を用いることから来る。委任は、親が子鍵で署名できず、かつ恣意的に子を失効させることができないときに、意味を持ち続ける。

自動化は囲い込みではなく移植可能であるべきだ

大規模な運用者はしばしば委任を選ぶ。なぜなら、経路認証がローカル自動化を通じてネットワーク意図に従うことを望むからだ。トラフィックエンジニアリングシステムは経路を準備し、承認を得て、対応する ROA を、複数の地域ポータルを人間がナビゲートするのを待たずに作成できる。

この利益は、自動化が移植可能である場合にのみ真実である。運用者は、その意図された経路セット、CA 関係、証明書履歴、公開状態を文書化された形式でエクスポートできるべきだ。CA 実装間を移動する前に、プロプライエタリなプロバイダモデルを再現しなければならないべきではない。

オープンなプロビジョニングプロトコルと公開プロトコルは、親とリポジトリの境界を確立するが、ローカル CA データもまた重要である。鍵は適切にハードウェアからエクスポート不能のままかもしれない。設定、認証意図、子関係、連絡先、監査証拠、回復指示は、それでも転送可能または再構築可能であるべきだ。

ソフトウェアの多様性は一つのプロジェクトへの依存を減らすが、実装間の移行は容易ではない。新しい CA は新しい鍵を用い、親の調整を必要とするかもしれない。子証明書と公開 URI が変わるかもしれない。運用者は移行をテストし、不透明な内部状態をコピーするのではなく、継続性を保持すべきだ。

RIR は、一つの必須クライアントを推奨するのではなく、中立的なプロトコル要件を文書化することで移植性をサポートできる。広く使用されるソフトウェアの例を提供しながら、あらゆる適合実装を受け入れることができる。適合性テストは、サポートされていないブランドではなく、失敗した標準の動作を報告すべきだ。

管理された委任サービスには追加の明確さが必要である。サードパーティが保持者に代わって子 CA を運用しながら、保持者が契約上の権限またはハードウェア鍵を保持する場合がある。RIR は、適格な保持者を認証し、認定された代理人を承認するべきであり、ベンダーとリソース保持者を混同してはならない。離脱条件は、親関係を失うことなく、保持者が代理人を交代できるようにすべきだ。

自動化はまた、エラーの影響範囲を拡大する。不正な形式の意図フィードは多くの認証を置き換えうる。委任ソフトウェアは、ドライラン、トランザクション制限、承認ポリシー、緊急凍結を提供すべきだ。ローカル制御はより弱い保護の議論ではなく、実際の経路とより密接に統合する機会である。

移植可能な自動化は、自律性と説明責任の両方を強化する。保持者はツールを変更し、証拠を保持し、どのシステムが誤ったオブジェクトを発行したかを特定できる。親は、全ての内部設計をサポートする代わりに、安定した標準境界を維持できる。

一つのアプリケーションバージョンやコンサルタントに結びついた権利は脆い。相互運用可能なプロトコル、回復可能な設定、交代可能な代理人を通じて表現される権利は、制度的变化を生き残ることができる。

小規模事業者には主権の講義ではなく、支援された道筋が必要だ

委任型 RPKI はしばしばグローバルキャリアや国別レジストリのニーズを通じて議論される。より小規模な事業者も、ローカル管理の正当な理由を持ちうる：公共部門の要件、内部セキュリティポリシー、マルチプロバイダ経路、過去のアカウント紛争に起因する不信、またはローカル制御との統合の必要性である。

彼らは相対的に急峻な負担に直面する。同じ CA の概念、鍵管理、公開、監視が、3 人のエンジニアの組織にも 300 人の組織にも適用される。深い公開鍵の専門知識を前提とするドキュメントは、形式的な選択肢をアクセス不能にしうる。

支援は鍵を取り戻すことを意味すべきではない。RIR やコミュニティ機関は、ステップバイステップの標準説明、テスト用親、検証済み設定例、適合性チェック、オフィスアワー、移行スケジューリングを提供できる。ハイブリッド公開サービスは、ローカル署名を保持しながら、最大の公開可用性の負担を取り除ける。

協同運用も別の可能性である。複数の組織が、異なる子鍵と権限を保持しながら、適格な管理プロバイダを利用できる。契約は、誰が署名できるか、誰が回復素材を保持するか、インシデントがどのように報告されるか、各メンバーがどのように離脱するかを定義すべきだ。共有インフラは、別々の認証を一つの文書化されていない管理者に崩壊させてはならない。

金銭的支援は、安全な導入が公共的価値を持つコミュニティネットワーク、大学、重要な地方サービスにとって正当化されうる。それは透明な基準を通じて分配されるべきであり、政治的支持を購入すべきではない。支援とレジストリ選挙は別の領域である。

トレーニングには、委任しない理由を含めるべきだ。組織が連絡を維持できず、資格情報を保護できず、公開を監視できず、回復を実行できない場合、今日はホスト型サービスの方が安全かもしれない。決定は再検討できる。情報に基づく選択は、ローカル鍵がまだ責任を持てないと判断する自由を含む。

プロバイダは二つの調子を避けるべきだ。一つは軽蔑的だ：「専門家だけがこれを必要とする。」もう一つはロマンチックだ：「真の管理はすべてを自分で行うことを意味する。」両方とも、モジュール選択と支援のスペクトラムを曖昧にする。

実用的な権利は、最初に XML 交換を成功裏に完了した大規模事業者だけではなく、正当なユースケースを持つ最もリソースの乏しい適格メンバーを念頭に設計される。そのメンバーがテストし、助けを得て、親公開を使用し、安全に移行できるなら、制度的選択肢は成熟している。

証拠は拒否・困難・責任ある却下を区別すべきである

RIR が鍵の自律性を認めていないという主張は、異なることを意味しうる。サービスがその保持者カテゴリに正式に利用できないのかもしれない。利用可能だが文書化されていないのかもしれない。要求が遅延しているのかもしれない。特定のクライアントが適合しないのかもしれない。保持者が認証に必要な契約関係を欠いているのかもしれない。運用者が無効な要求を提供したのかもしれない。親が述べられた安全上の理由で拒否したのかもしれない。

これらのケースは異なる救済策を必要とする。権利レビューは、要求日、保持者カテゴリ、リソース関係、公開された適格性、ソフトウェアとバージョン、プロトコル交換、エラー応答、サポート連絡先、理由、遅延、最終結果を保存すべきだ。マシンメッセージが存在する場合、スクリーンショットだけでは弱い。

困難にも分母が必要である。移行試行数が不明であれば、10 件の不満が大多数の移行が失敗していることを立証しない。地域の主張をグローバルなものにしてはならない。プロバイダは、カテゴリとプライバシー保護付きで要求と結果の数を公開することで証拠を改善できる。

責任ある却下はありうる。認証されたリソース外の要求は認められてはならない。禁止されたアルゴリズムや無効な証明書要求を使用する子は修正が必要かもしれない。持続的に機能しない CA は公開されたルールの下での行動を正当化しうる。許可されていないベンダーは単にメンバーの資格を主張することはできない。

プロバイダは、ルールと治療法にマッピングされる理由を発行すべきだ。「サポート外」は、問題がプロトコルなのか、プロファイルなのか、適格性なのか、セキュリティなのか、能力なのかを特定すべきだ。保持者は、標準やポリシーが誤って適用されたと考える場合、レビューを求めることができるべきだ。

研究者はまた、イベント時点での公開文書を検証すべきだ。サービス機能は変わる。LACNIC の現在のページは 2019 年からの委任の利用可能性を記録しているが、以前の欠如は今日のフォームから推論できない。APNIC と RIPE の公開サービスは進化した。公正な歴史的分析は、現在の能力を過去に遡及させるのではなく、主張に日付を付ける。

運用上の証拠がレトリックよりも重視される。憲章は保持者の管理を約束するかもしれないが、成功した標準交換はその一側面を示す。サービスページは委任を約束するかもしれないが、再現可能な移行ギャップは限界を示す。どちらの単一項目も制度全体を決定しない。

この規律は会員と RIR の双方を保護する。それは真の排除を見えるようにし、不適格な範囲や壊れた子ソフトウェアによって引き起こされた失敗をフィルタリングする。鍵の自律性は、あらゆる不満に適合するほど広いスローガンではなく、修復を支援するのに十分に強い証拠に値する。

番号資源協会は相互的な協定を定義できる

NRS の、保持者参加、正確な登録、レジストリの恣意的権力の制限への明示された焦点は、委任型 RPKI を自然な試金石にする。この組織は、具体的な権利と相互的義務を定義することによって最も貢献できる。

その第一の成果物は、地域委任アクセスマトリクスでありうる。各 RIR および関連する保持者カテゴリについて、適格性、準拠条件、親プロトコル、サポートされる証明書プロファイル、公開オプション、テスト能力、移行シーケンス、サポート経路、料金、失効ルール、レビューを記録する。各エントリは現在の一次資料にリンクし、検証日を付与する。

第二は、適合性・移行クリニックでありうる。メンバーはメンテナンスされた CA ソフトウェアを用いて認可されたテストケースを実行し、結果を保存し、公開前にプロバイダの修正を求める。クリニックは、子の欠陥と親の欠陥を区別し、鍵やリソースの詳細を露出させることなく修正を共有できる。

第三は、委任を選択するメンバーのための継続的協約でありうる。参加者は、指名された連絡先、鍵回復の証拠、現在のオブジェクト監視、公開テスト、承継計画を維持する。NRS は、独自に保証できないセキュリティを認証するのではなく、テンプレートと演習を提供できる。

第四は、地域ガバナンスにおける代表でありうる。移行に回避可能な break-before-make が必要な場合、サポート条件が不明瞭な場合、または委任ユーザーが弱いインシデントアクセスを受ける場合、NRS は証拠に基づいた提案を提出できる。理事会に対し、コスト、セキュリティ制約、実装計画の説明を求めることができる。

NRS は自身の提唱に制限を適用すべきだ。秘密鍵は財産権、永続的な登録資格、または裁判所命令からの免除の証明ではない。地域の親は証明書チェーンの一部であり続ける。会員運用の CA は失敗する可能性があり、比例的な措置に適切に直面するかもしれない。NRS の一次資料は、全ての RIR がその分析を受け入れることや、提案された協約が既に強制されていることを証明するものではない。

相互的フレーミングは重要である。メンバーは責任なしに鍵を保持することを求めない。彼らは責任を適切に遂行するために必要なツール、標準、移行、公正な扱いを求める。RIR は権威あるリソース範囲を放棄しない。彼らは、メンバーが委任を選ぶとき、子の署名行為の管理は子に属することを受け入れる。

その協約は経路セキュリティを強化する。それはより能力ある運用者を生み出し、負担の少ないホスト型経路を保持し、階層を不安定化させることなく、集中された機能を議論可能にする。

反論は隠れたコストを露呈するとき最も強力である

第一の反論は、委任 CA が失敗しうるシステムの数を増やすというものである。真実だ。ホスト型の集中化は専門的な鍵管理とリポジトリの回復力を提供できる。委任は、中央の運用効率の一部を、署名権限の分離とローカル統合と交換する。答えは、情報に基づく選択、ハイブリッド公開、強制可能な最低限の衛生であり、強制的な委任ではない。

第二の反論は、親は二重認証なしに移行中の重複を許可できないというものである。重複は確かにリスクを生む。しかしプロバイダは、子を事前検証し、公開を準備し、あらゆる移行中の重複範囲を制約できる。プロトコルやポリシーが重複を防ぐ場合、その制限を公開し、迅速な復帰を伴う協調的な切り替えを提供できる。「重複なし」が「移行エンジニアリングなし」を意味すべきではない。

第三の反論は、オープン標準が既に平等性を解決するというものである。標準は重要な技術的部分を解決する。それらは適格性、料金、サポート、通知、テストの同等性、移行順序、救済策を確立しない。適合するエンドポイントでも、実際にはアクセス不能でありうる。

第四の反論は、ペナルティのないルールが RIR に高コストのユーザーを補助することを強いるというものである。強いる必要はない。透明なコストベースの価格設定と合理的なサポート境界は、平等な地位と両立する。ペナルティは、合法的なコストやリスクと無関係または不釣り合いな負担を意味し、サービスにおけるあらゆる差異ではない。

第五の反論は、ローカル鍵の所持が所有権の誤った主張を助長するというものである。その修辞的リスクは存在する。文書化は境界を平易に述べるべきだ：鍵は、現在の認証範囲内で子の署名されたオブジェクトを認証する。それは法的所有権を生み出したり、有効な親の行動を覆したりしない。

第六の反論は、委任ユーザーは失敗した場合、単にホスト型サービスに戻ればよいというものである。戻ることは有用だが、それもまた、現在の権限、安全なオブジェクト置き換え、鍵の退役を必要とする移行である。それは設計され、テストされ、汚名のないものであるべきだ。失敗は、保持者が依然として適格である場合、永続的な排除ではなく学習を生むべきだ。

最後の反論は、ごく少数派だけが委任を望むかもしれないということである。信頼できるグローバルな分母は正確なシェアを支持せず、少数派の権利は依然として集中されたサービスを律することができる。コストは需要に比例したままでなければならないが、その選択肢がトラストモデルの一部として提示されている場合、名目上のサポートだけでは十分ではない。

これらの反論は、主張を防衛可能なものに狭める。その権利は、無制限の自己認証、無料のオーダーメイドサポート、または安全からの免除ではない。それは、義務を受け入れる用意のある適格な保持者のための、利用可能で、標準に基づき、公正に管理された選択肢である。

委任権利憲章は短く執行可能であり得る

認証を提供する各 RIR は、技術文書やサービス条件と並んで委任権利憲章を公開すべきだ。それは壮大な憲法の言葉である必要はない。それは運用者が下さなければならない決定に答えるべきだ。

適格性：どの直接メンバー、スポンサー付きユーザー、レガシー保持者、国別レジストリ、認可された代理人が子証明書を要求できるか、どの合意の下でかを特定する。要求される証拠と期待される応答時間を述べる。

相互運用性：サポートされる標準、プロファイル、アルゴリズム、プロトコルバージョンを列挙する。エンドポイント、テストケース、廃止通知、理由付き適合応答を提供する。単一の推奨ブランドではなく、公開された要件を満たすあらゆる実装を受け入れる。

選択：ホスト型、委任型、利用可能なハイブリッド公開モデルを、会員サービスの無関係な喪失なしに提供する。料金とサポート境界を公開する。保持者の権限を保持しながら、認可された管理代理人を許可する。

移行：棚卸しから旧 CA 退役までのあらゆる状態を記述する。重複が可能かどうか、事前検証がどのように機能するか、どのスタッフが立ち会うか、どの監視が完了を証明するか、緊急復旧がどのように行われるかを含む。

運用：鍵のセキュリティ、マニフェスト、失効情報、公開、連絡先、経路意図、承継に関する保持者の義務を述べる。資格の正確さ、プロトコルの可用性、通知、インシデント証拠、その境界でのサポートに関する親の義務を述べる。

不利な措置：失効クラス、緊急性、通知、治療、承認者、証拠、レビュー、復旧を定義する。持続的な技術的失敗を短い停止から、セキュリティ緊急事態を管理上の紛争から分離する。

移植性：保持者が CA ソフトウェア、公開プロバイダ、管理代理人、または展開モデルをどのように変更するかを説明する。鍵のセキュリティと互換性がある場合にエクスポート可能な状態を提供し、履歴記録を保存する。

説明責任：誠実な分母を持つサービス測定を公開し、プロバイダに起因する深刻なインシデントを報告し、独立したレビュー経路を提供する。RIR の確立されたガバナンスを通じたコミュニティ修正を招請する。

憲章はテスト可能であるべきだ。メンバーは、応答の未達、サポートされない適合交換、文書化されていない移行ステップを指摘できる。組織は失敗した保持者義務を指摘できる。不一致はより狭く、より解決可能になる。

そのような憲章は、RIR を全ての委任リポジトリの保証人にするわけではなく、保持者をリソース登録から独立させるわけでもない。それは魅力的なサービス説明を相互的コミットメントに変換するだろう。それが鍵の所持を技術的特徴から強制可能な制度的選択へと変えるものである。

理論上の利用可能性ではなく、行使された選択を測定せよ

RIR はしばしば RPKI カバレッジやオブジェクト数を報告する。それらの測定は、委任の選択が利用可能かどうかを明らかにしない。

地域サービスは、適格要求数、完了したオンボーディング、親関係成立までの時間の中央値と範囲、理由別の適合失敗、モデル別の移行、緊急復旧、ホスト型サービスへの自発的復帰、非自発的失効を報告できる。カウントには、プライバシーが許す限り、明確な報告期間と保持者カテゴリが必要である。

移行測定は、準備と本番切り替えを分離すべきだ。運用者が選んだ長い準備期間は、親の遅延と同じではない。期待される認証ギャップと実際のそれ、外部検証の成功、未解決のインシデントを報告する。意図したオブジェクトが利用不能のままなら、証明書発行を完了とは呼ばない。

サポート測定は、どちらの側が障害を支配していたかを特定すべきだ。親のエンドポイント、公開サービス、子のソフトウェア、ローカル鍵、アカウント適格性、登録状態は異なるカテゴリである。これにより、投資が繰り返し発生する問題を追うことができる。

運用者は自身の準備スコアを維持できる：現在の鍵回復、有効なマニフェストと失効情報、外部リポジトリ検証、アクティブな連絡先、テストされた親交換、文書化された意図、ソフトウェアサポート状況、承継。スコアは行動を促すべきであり、セキュリティを過大評価する公的なバッジになるべきではない。

NRS と研究者は、公開された権利と認可されたテストを地域間で比較できる。彼らは単純なランキングを避けるべきだ。委任ユーザーが少ない地域は非常に利用しやすいサービスを持っているかもしれない；より多くのユーザーを持つ別の地域は市場構造を反映しているかもしれない。採用は公正の証明ではなく、低い採用は妨害の証明ではない。

最も明らかな指標は、有効な認証の意図しない喪失なしに成功したモデル変更である。それは、文書化、アイデンティティ、標準、親の運用、子の準備、公開、監視、救済を一緒にテストする。

現在、グローバルな委任要求受諾率、移行失敗率、コスト比較、経路影響確率をサポートする完全な公開データは存在しない。その制限はあらゆる真面目な分析に属する。それはまた、機関が制限付きのサービス証拠を公開する理由でもある。

目的は委任を最大化することではない。適格メンバーが正当化されるときにそれを行使でき、ホスト型にとどまる者が実用的な監禁ではなく情報に基づく選好によってそうすることを示すことである。

自律性とは責任を選択する能力である

委任型 RPKI は、運用上の RPKI の歴史の多くにわたって地域的な形態で存在してきた。オープン標準は親子プロビジョニングと分離公開を可能にする。複数の地域が現在、自己運用認証を説明しており、RIR の管理外にソフトウェアが存在する。これらは実質的な成果である。

残るガバナンスの問いは、その選択肢が例外としてではなく権利として機能するかどうかである。適格保持者は、条件を発見し、適合する子を使用し、失敗をテストし、公開を選択し、安全に移行し、サポートを得て、親のエラーに異議を唱え、無関係なペナルティなしにツールを変更できるか？

秘密鍵の所持は、一部にしか答えない。それはホスト型プロバイダが子として署名することを防ぎ、ローカルセキュリティと自動化を可能にする。それは親証明書を取り除いたり、リポジトリの可用性を保証したり、リソースの所有権を証明したり、子を運用義務から免除したりしない。

標準、移行サポート、ペナルティのない選択は共存しなければならない。移行のない標準は、インストールされたホスト型ユーザーを閉じ込める。相互運用性のない移行は、それらを一つのツールに縛り付けることができる。平等な情報、サポート、レビューのない技術的選択は、二級会員を作り出す可能性がある。保持者の義務のない平等な扱いは、依拠当事者すべてに負担をかける可能性がある。

RIR は強力なホスト型サービスを保持すべきだ。それは多くのメンバーにとって責任ある選択であり、実際の採用への主要な貢献者である。また、委任型およびハイブリッドモデルを実証的に利用可能にすべきだ。なぜなら、運用者のニーズに応じて、親権限から鍵管理を分離できる方が、信頼はより強固になるからだ。

委任を選択するメンバーは、完全な積極的協約を受け入れるべきだ：安全な鍵、最新のオブジェクト、回復力のある公開、監視された意図、アクティブな連絡先、テストされた承継。彼らはローカル管理を正当な登録や証明書範囲からの脱出と表現すべきではない。

NRS は、証拠、適合性演習、移行支援、地域提案を通じてこのバランスを見えるようにできる。その提唱は、権利と同様に義務を明確に主張し、技術的・契約的記録を超える主張を避けるときに信頼できる。

自ら鍵を保持する権利は、究極的には責任を選択する権利である。それは、親が単に管理上の都合のために子の署名行為の放棄を要求できず、子は無能な運用なしに信頼を要求できないことを意味する。これらの立場の間に成熟した制度的解決が存在する：オープンで、移植可能で、レビュー可能で、参加または離脱が安全なもの。

その解決が存在するとき、委任型 RPKI は主権についてのスローガンではない。それは、経路セキュリティとその上位機関の正当性の両方を強化する実用的な職務分離である。

情報源