概況

  • RPKI 証明書や署名付きオブジェクトはパケットをルーティングするわけではないが、ネットワークがルーティングポリシーを適用するバリデーション状態を変更できる。レジストリがホスト鍵、証明書発行・失効・公開を管理する場合、その行動は通常の記録管理を超えた運用上の影響を生み出す可能性がある。
  • 広範な免責事項には正当な目的がある。レジストリは、ホルダーの ROA 選択、すべてのバリデータ、すべてのネットワークのフィルタリングポリシー、すべての BGP 経路、または顧客の事業継続を管理できない。無料または会員資金によるサービスは、インターネット全体を無制限の結果的損害に対して保険でカバーすることも現実的ではない。
  • しかし現状の配分は非常に非対称的である可能性がある。ARIN が公開する RPKI 利用規約は、中断、不正確さ、エラーを免責し、損害賠償を広く除外し、低い総額上限を定めている。現在の RIPE NCC の規約は、サービスをベストエフォートで提供し、故意または重大な過失を除きほとんどの損害を除外する。APNIC の公開証明書ステートメントも、加入者および依拠当事者に実質的なリスクを負わせている。
  • これらの条項は異なる法律、契約、サービス契約のもとで運用される。その表現は制度的なリスク配分の証拠であり、すべての条項がすべてのホルダー、オペレーター、または下流顧客に対して執行可能であるという結論ではない。
  • 証明書サービスの免責事項監査では、ホルダーによるミス、レジストリの処理エラー、許可されていない証明書操作、公開の失敗、バリデータの欠陥、オペレーターのポリシーを区別すべきである。責任は、管理されたステップと立証された過失に従うべきである。
  • 誤った証明書に対する最初の救済手段は金銭ではなく、高速で認証された修正、インシデント前の状態の保存、公開オブジェクトレベルの通知、独立したバリデータ間の検証された収束である。財務的責任は、これらの管理が失敗した場合、または文書化された損失が残る場合に関連する。
  • NRS は、正確な RIR の規約、緊急権利、責任例外、実用的な救済手段をリソースホルダーに比較可能にするという形で積極的に貢献できる。集合的な精査は、レジストリがすべてのルーティングを保険でカバーしなければならない、または証明書の権限には責任が伴わないと主張するよりも有用である。

証明書はトラフィックを動かさないが、誰がそれを受信するかを変更できる

RPKI の法的議論は、技術的に正しい一文で始まり、あまりにも早く終わることが多い。地域レジストリは、その証明書に依存するすべてのルーターを運用しているわけではない。ROA は許可であり、経路通知ではない。依拠当事者はオブジェクトを検証し、ルーターはローカルポリシーを適用し、BGP は経路を選択する。したがって、レジストリは直接顧客のトラフィックをオン/オフにするわけではない。

しかし、証明書サービスは因果的に無関係ではない。ホスト型認証局が証明書を発行または失効させたり、ホルダーの許可された指示と異なる ROA を公開したりした場合、依拠当事者は異なる検証済みペイロードセットを生成する可能性がある。正当な BGP アナウンスが無効になる可能性がある。無効なアナウンスを拒否するように設定されたネットワークは、それを受け入れなくなる可能性がある。制度的な行動は最後のステップではないが、追跡可能なチェーンにおける最初の誤ったステップになり得る。

その区別は責任にとって重要である。権限が物理的に即時的である必要はなく、その範囲内で注意義務を生み出すことができる。証券登録機関はすべての投資家の資金を動かすわけではなく、航空航法データ提供者は航空機を飛行させるわけではない。彼らの正確な法的義務は異なるが、証明されたデータエラーに対して、最終ユーザーの決定だけを指摘して答えることはできない。

RPKI も同じ精度で分析されるべきである。ホルダーは宣言されたルーティング意図を管理する。レジストリまたは別の認証局は、発行と公開の一部を管理する。依拠当事者のメンテナーは検証ロジックを管理する。オペレーターはフィルタリングポリシーとネットワークの回復力を管理する。顧客はいくつかの事業継続の選択肢を管理する。責任はデフォルトで一つの参加者に割り当てられるべきではないが、複数の参加者が関与しているからといって消滅するべきでもない。

重要な契約上の問題は、各当事者が合理的に防止、検出、修復できるリスクの結果を負うかどうかである。広範な証明書管理を留保しながら、関連するすべてのリスクを外部に転嫁する条項は、制度的にそのテストに失敗する。特定の紛争で特定の文言が裁判所によって執行される可能性があってもである。

ホスト型 RPKI は通常の記録管理にはない権限を集中させる

ホスト型サービスでは、レジストリは通常、リソースホルダーに代わって認証局を運営する。会員システムを介してアクセスを認証し、関連する鍵素材を生成または保持し、リソース証明書を発行し、ホルダーの指示に従って署名付きオブジェクトを作成および失効させ、結果として得られる素材を公開する。ホルダーは利便性を得て、継続的に利用可能な認証および公開サービスを運用する必要がなくなる。

この取り決めは、真の導入問題を解決する。多くのネットワークには、鍵と公開を24時間管理するためのセキュリティスタッフ、ハードウェア、監視、運用成熟度がない。中央提供は、一貫性、パッチ適用、サポートを向上させることができる。また、RPKI を小規模組織にもアクセス可能にする。

集中化には代償がある。レジストリの欠陥、アカウント侵害、誤ったリソース更新、障害のある転送プロセス、公開エラーは、一度に多くのホルダーに影響を与える可能性がある。ホルダーは、レジストリがホスト鍵とユーザーインターフェースを管理しているため、オブジェクトを独立して修正できない場合がある。ホルダーが変更を要求できる場合でも、サービスはその要求がいつ有効な外部オブジェクトになるかを管理する。

RIPE NCC の現在の規約は、この分割を明確に述べている。ホスト型認証では、RIPE NCC は暗号化操作を担当し、証明書ホルダーの公開鍵と秘密鍵のペアをホストする。そのサービスは証明書を発行または失効させ、署名付きオブジェクトを作成、修正、削除できる。ARIN も同様に、公開されたサービス規約のもとでホスト型 RPKI を提供している。これらは受動的な掲示板ではない。

制度的な権限は、この運用レベルで定義されるべきである。レジストリは下流の経路ポリシーを管理しないが、ホルダーの許可がそのブランチのもとで暗号的に検証可能かどうかを管理する。公正な免責事項は、前者に対する責任を拒否しながら、後者に対して適切な基準を受け入れることができる。

責任の制限の一部は合理的かつ必要である

RPKI 認証局は、たまたま IP プレフィックスに依存するすべての商業活動の保険者になることはできない。短い経路中断が、広告の損失、逃した金融取引、違反したクラウドコミットメント、風評被害、複数の契約層にわたる顧客離脱を引き起こしたと主張される可能性がある。結果として生じるエクスポージャーは、会員資金による非営利組織のリソースを桁違いに超える可能性がある。

因果関係も複雑である。誤った ROA はホルダーに起因する可能性がある。オペレーターは無効状態を無視するか拒否する可能性がある。トランジットプロバイダーは別の経路漏洩を持っている可能性がある。バリデータは時代遅れである可能性がある。顧客はマルチホーミングや他の継続性手段を欠いている可能性がある。同じ証明書イベントは、あるネットワークでは到達可能性の変化を生み出さず、別のネットワークでは深刻な障害を引き起こす可能性がある。

免責事項は、共有された機関を不確定な請求から保護し、手頃なサービスを維持する。遠隔の、投機的な、または懲罰的な損害を除外することは防御可能である。ユーザーに現在のオブジェクトを検証し、適切なソフトウェアを運用することを要求することは賢明である。使用をリソース証明書が設計された目的に制限することは、証明書がアイデンティティ、財産権、経路パフォーマンス、または商業的価値の意図しない保証になるのを防ぐ。

RPKI 標準自体が法的配分を予期している。RFC 3647は、加入者および依拠当事者契約を権利と義務のための重要な手段として扱い、そのフレームワークには保証の免責、回復可能な損害の制限、責任上限が含まれている。すべての認証局に同じ答えを規定しているわけではない。RFC 6484は、各局のプラクティスが関連する管理を説明することを要求しているが、依拠は状況に応じて合理的でなければならないことを認めている。

したがって、ガバナンス上の異議はすべての除外に対するものではない。それは、機関が発行を管理し、防止可能なエラーを犯し、修正を遅らせ、それでも実質的にすべての意味のある結果を免責できるほど広範な配分に対するものである。制限はサービスを維持すべきであり、サービスを有能に実行するインセンティブを除去すべきではない。

監査はすべての governing 文書から始まり、一枚の免責ページからではない

オペレーターは、見出しの規約ページだけを読んで RPKI の立場を理解することはできない。権利と義務は、認証サービス契約、リポジトリ規約、認証実践ステートメント、登録契約、会員契約、利用規定、サービスレベル公開、ポリシー文書、および後の修正に分散している可能性がある。

関係も異なる。ホスト型 RPKI を使用するリソースホルダーは、レジストリと直接契約を結んでいる場合がある。委任された認証局は、別のプロビジョニングまたは公開条件を受け入れる場合がある。公開素材をダウンロードする依拠当事者は、アクセスを通じて主張されるリポジトリ条件の対象となる場合がある。別の組織によって生成されたペイロードを使用するダウンストリームオペレーター。サービスが中断された小売顧客は、レジストリと全く契約を結んでいない場合がある。

監査は、インシデント日に適用される正確な文書バージョンを特定すべきである。RPKI の規約は変更される可能性がある。同意の方法が重要である：署名、クリック受諾、会員参加、継続使用、単なるダウンロード。準拠法、裁判地、時効、紛争経路は、実質的な上限と同じくらい重要である。

運用上のコミットメントは契約の外にある場合がある。公開ステータスページは、執行可能な保証を作成せずにサービスレベルやインシデント通知を公開できる。認証実践ステートメントは、セキュリティと失効管理を説明しながら、正式な規約が優先されると宣言する場合がある。公開実践と契約上の約束の違いは明確にされるべきである。

最後に、監査は文書を権限にマッピングする。どのテキストが証明書失効を許可するか？どのテキストが ROA コンテンツに対するホルダーの責任を割り当てるか？どのテキストがリポジトリの古いビューをカバーするか？どの条項がレジストリスタッフまたはソフトウェアによる過失に対処するか？どの救済手段が会員ではなく依拠当事者に利用可能か？

この文書マップは、選択的な読み取りを防ぐ。プロバイダーは、自社の運用コミットメントなしにホルダーの責任条項を引用すべきではない。請求者は、セキュリティプラクティスがあたかもすべての経路を保証したかのように引用すべきではない。責任は完全な関係と立証された失敗から生じる。

ARIN の公開規約は非対称性を特に顕著にしている

ARIN の RPKI 利用規約（バージョン1.1、2019年4月17日）は、制度的リスク移転の明確な例を示している。この契約は、RPKI を新興セキュリティフレームワークとして説明し、鍵漏洩を含むリスクを列挙し、ユーザーが許可されたおよび許可されていないアクセスまたは使用に関連するリスクを負うと述べている。

その免責条項は、サービスとリソース認証は関連するリスクと欠陥を伴って現状のまま提供されると述べている。サービスが中断がなく、欠陥、不正確さ、エラーがなく、ユーザーの要件を満たし、ユーザーの選択した設定で動作するという約束を否認する。その後、RPKI サービスに関連する責任と損害を広く除外し、顧客またはクライアントを含む請求を含む。

記載された総責任上限は、RPKI サービスに対して過去6ヶ月間に支払われた金額または100米ドルのいずれか大きい方である。この契約には、ARPIN を有利にするための広範な補償義務も含まれており、ユーザーおよび関連当事者による使用またはアクセスに関連する請求を対象とし、全文に従う。

これらの規定は、ARIN が同時にホストサービスの認証役割を占めているため、商業的に厳しい。防止可能な ARIN の欠陥が誤った証明書を生成したり、許可された修正の公開に失敗したりした場合、ルーティングの結果が予見可能であったとしても、実質的な回復が困難になるようにテキストが設計されているように見える。すべての規定が書かれた通りに適用されるかどうかは、事実、準拠法、および請求者の関係に依存するが、制度的配分は明らかである。

ARIN には、非営利レジストリを無制限のインターネット損失から保護する合理的な理由がある。監査の質問はより狭い：名目上の上限と広範な除外は、主張される失敗がホルダーの意図、サードパーティソフトウェア、またはオペレーターポリシーではなく、ARIN 自身の証明書管理内に完全にある場合に比例するか？

成熟した答えはそれらのケースを区別するだろう。現在の文言は、その管理に基づく区別よりもはるかに広範である。

ARIN のアクセス変更により、同意と範囲がより重要になり、より重要でなくなるわけではない

2024年6月、ARIN は、RSA または LRSA の下で直接保有リソースを持つ顧客が、ARIN Online 内で個別の RPKI 規約を明示的に承諾することなく RPKI を使用できると発表した。この変更は導入の障壁を減らした。また、リスクレビューのために文書マップをより重要にしている。

オペレーターは現在、自分の登録契約を通じてどの RPKI 規定が適用されるか、どれが別個に関連し続けるか、どの行為が承諾を構成するかを尋ねなければならない。この発表自体は、将来の紛争におけるすべての条項の執行可能性や範囲に答えるものではない。また、追加のクリックを削除しても、他の場所で組み込まれた実質的な制限が必ずしも削除されるわけではない。

これは、より簡単なアクセスに対する批判ではない。セキュリティサービスは、回避可能な法的摩擦が導入を妨げない場合に利益を得る。リスクは、より簡単な登録が責任を見えにくくすることである。リソースホルダーは、実際の救済手段を形作る責任上限、緊急修正ルート、倒産条項、アカウント義務を比較せずに ROA を作成する可能性がある。

ARIN は、アクティベーション前に表示され、バージョンによって保持される簡潔なサービス固有のステートメントを通じて、この多くを解決できる。管理契約、ホルダー入力データの正確な責任、ARIN 生成証明書と公開、修正ルート、上限、例外を特定すべきである。ユーザーは、どの文書が適用されたかを発見するために訴訟を必要とすべきではない。

同じ明確さは ARIN にも利益をもたらす。重要な除外が隠されていたという申し立てを減らし、組織がホルダーが知識を持って保持したリスクを示すことを可能にする。透明性は無制限の義務の承認ではない。情報を得た期待をもって重要な共有サービスが開始された証拠である。

RIPE NCC の規約は狭い過失例外を受け入れるが、広範な保護を保持する

2026年6月に発効する RIPE NCC 認証サービス規約は、ホスト型認証局を、RIPE NCC が暗号化操作を担当し、ホルダーの鍵ペアをホストするものと定義する。サービスは証明書を発行または失効させ、署名付きオブジェクトを作成、修正、削除する。この規約はまた、ルーティング意図と矛盾する ROA がアナウンスの拒否をもたらす可能性があるとホルダーに警告する。

サービスはベストエフォートベースで利用可能であると述べられており、RIPE NCC は技術的、法的、不正利用防止およびその他の理由で運用停止権限を留保する。その責任条項は、使用をホルダー自身のリスクとみなし、ホルダーをサービスの使用および証明書の使用について責任を負わせる。

RIPE NCC は、その後、事業損失、逸失利益、第三者損害、人身傷害、物的損害を含む損害を除外する。ただし、自らの故意または重大な過失が関与する場合を除く。特定の不可抗力状況を除外し、ホルダーに自らの使用に関連する第三者請求に対して補償することを要求し、証明書の生成、交換、使用に関連する権利について認識から1年の期間を定める。

別のリポジトリ規約は、ホスト型素材をダウンロードするユーザーにリスク配分を適用する。アクセスと使用をユーザーのリスクとし、古いデータに基づく決定の責任をユーザーに割り当て、同様に故意または重大な過失の例外を保持する。

このモデルは ARIN のものと同一ではない。明示的な過失例外は重要であり、法的設定も異なる。しかし、同じ構造的緊張が残る：ホスト型当局は鍵と公開を管理する一方、閾値が重大な過失である場合、ほとんどの通常の過失の結果を回復するのは難しいかもしれない。

したがって、監査は、適用される法律の下でどのような行為が例外を満たすか、ユーザーがどのような証拠を入手できるか、緊急修正救済が財務訴訟が関連する前に機能するかを尋ねるべきである。

APNIC も同様に加入者と依拠当事者に実質的なリスクを負わせる

APNIC の公開された RPKI 認証実践ステートメントは、ホスト型およびセルフホスト型認証の取り決め、証明書ライフサイクル管理、信頼された役割、鍵保護、公開、依拠当事者の使用を説明する。また、責任に関する実用的な法的文言を含む。

このステートメントは、リポジトリのダウンロード、データアクセス、サービスの使用を依拠当事者のリスクとする。証明書の使用および署名付きオブジェクトの作成について加入者に責任を負わせる。APNIC は、自らの故意の過失が関与する場合を除き、直接的および間接的な損害（事業損失および第三者損失を含む）を除外する。最新公開インスタンス以外の素材に基づく決定の責任を依拠当事者に割り当て、不可抗力保護および1年の請求期間を含む。

文書はまた、依拠当事者は失効情報を確認し、最新のリポジトリバージョンを使用すべきであると述べているが、リポジトリの可用性はベストエフォートベースである。これらは合理的な運用上の義務である。より難しいケースは、最新公開インスタンス自体が APNIC 管理のエラーによって誤っている場合、またはサービスがホルダーにタイムリーな修正の公開を妨げる場合である。

繰り返すが、文言は結果ではない。クイーンズランド州法、正確な参加者関係、インシデントの事実が法的分析を形成する。それでも、APNIC のステートメントは、リスクがどのように配分されるかの貴重な証拠である：加入者と依拠当事者は広範な責任を負い、APNIC は自らの故意の過失に対して狭い例外を保持する。

RIPE NCC との比較は、類似の構造がテキスト的に同一ではなく繰り返されることを示している。これにより、すべての地域に一つの契約があるという主張ではなく、共通の監査質問が提起されるべきである。また、オペレーターがレジストリが自らの証明書サービスの経済的結果に対して責任を負うという一般的な仮定に頼れない理由も示している。

単一の RIR 責任体制は存在しない

地域レジストリは異なる法律の下で設立され、異なる会員構造にサービスを提供し、異なる契約と認証ステートメントの組み合わせを公開する。国別レジストリと委任された当局はさらなる層を追加する。類似の条項でも、同意、交渉状況、法定管理、および請求される損失の種類に応じて異なる運用が可能である。

この記事による ARIN、RIPE NCC、APNIC の調査は、すべての当局または過去のバージョンの完全な調査を提供するものではない。現在の公開資料における繰り返し発生するリスク配分機能を特定する：ベストエフォートサービス、ユーザー責任、広範な損害除外、短い請求期間、補償、狭い過失例外。

特定の RPKI 条項を適用した公開判決がないことは、免責または責任を証明するものではない。多くのインシデントは損失を生み出さず、迅速に修正され、機密のままであるか、商業的に解決される。経済的損失の法理、重大な過失の除外の制限、第三者に対する義務、および集合的会員救済は異なる。

したがって、政策は二つの全体的な主張に抵抗すべきである。第一は、オペレーターが最終的なルーティング決定を行うため、レジストリは責任を負えないというもの。第二は、誤った証明書が自動的にレジストリをすべての下流損失に対して責任を負わせるというもの。両方とも、管理、過失、因果関係、契約、法律を飛ばしている。

比較監査は依然として標準化できる。プロバイダーの証明書権限、表明されたサービス基準、ユーザー義務、保証除外、損害除外、上限、過失例外、補償、請求期間、準拠法、緊急救済、第三者立場を報告できる。法的効果が異なっても、フィールドは共通である。

それが制度的分析の適切な役割である：配分を見えるようにし、非対称性を特定し、最終的な法的結論を実際の事実を持つ管轄フォーラムに委ねる。

「誤った証明書」は異なる責任を持ついくつかの失敗を説明する

リソース証明書は、信頼できる登録状態と矛盾するリソースをリストするために誤っている可能性がある。子証明書は、親が変更した後に一時的に過剰請求する可能性がある。証明書は適切な権限なしに失効される可能性がある。更新に失敗し、利用できなくなるか、個々には有効であるが公開セットと矛盾する可能性がある。ROA は、ホルダーの誤った指示を正確に反映するか、正しい指示を不正確に反映する可能性がある。

これらのケースは、一つの責任ルールを共有すべきではない。ホルダー作成コンテンツは、署名される内容が明確に表示され、許可された要求が忠実に実行された場合、主にホルダーに属する。レジストリは、安全な認証と正確な実行に対して責任を負うが、ホルダーのルーティング計画を保証すべきではない。

レジストリ生成の矛盾は異なる。転送プロセスが親証明書と子証明書を安全でない順序で更新する場合、ホルダーは誤った指示を提供していない可能性がある。認証局はシーケンシングとアトミック性を管理する。ホルダーが証明書の使用に対して責任を負うという広範な条項は、その技術的管理を曖昧にすべきではない。

許可されていない行動もまた異なる。アカウント侵害には、ホルダーの認証情報プラクティス、レジストリの認証管理、またはその両方が関与する可能性がある。配分は、どの保護が失敗したか、各当事者が公開された基準に従ったかを検討すべきである。

公開遅延には独自の構造がある。正しいオブジェクトが存在するが、依拠当事者に利用可能でない場合がある。公開者は外部配信を管理し、バリデータはフェッチ動作を管理し、オペレーターはキャッシュとルートポリシーを管理する。失効と修正までの時間は損失に影響する。

免責事項監査は、これらの障害モードをリストし、それぞれに責任ルールを添付すべきである。「自己責任で使用」のような単一のフレーズは、異なる管理を一つの外部移転に圧縮する。それは法的防御を単純化するかもしれないが、運用上の説明責任を弱める。

因果関係は最初の誤った逸脱に従うべきである

RPKI 請求は、期待状態と観測状態の時間順比較として分析できる。期待状態は、ホルダーの認証された指示と適用可能なリソース登録から始まる。観測状態は、証明書生成、署名付きオブジェクト作成、リポジトリ公開、依拠当事者検証、RTR 配信、ルーターポリシー、BGP 結果を経て進行する。

観測状態が誤って逸脱する最初の点が、主要な技術的原因である。ホルダーが AS64500 を要求したが AS64501 を意図していた場合、逸脱はホルダーの指示から始まる。要求が正しかったがサービスが異なるオブジェクトを作成した場合、逸脱は認証から始まる。オブジェクトが正しかったが外部で利用可能にならなかった場合、逸脱は公開から始まる。すべての公開素材が有効であったが、バリデータが誤って破棄した場合、逸脱は依拠当事者ソフトウェアから始まる。

この方法は寄与原因を排除しない。オペレーターは無効状態を監視しなかったり、冗長性なしに一つのバリデータを実行したりする可能性がある。トランジットプロバイダーは予想よりも厳格にルートポリシーを執行する可能性がある。レジストリはホルダーのミスの後で緊急修正を遅らせる可能性がある。責任は共有され得る。

この方法は循環的な非難を防ぐ。各参加者は、署名された要求、オブジェクトダイジェスト、公開観測、検証ログ、RTR シリアル、ルートポリシーバージョン、BGP 記録など、自らのステップの証拠を生成できる。時間は管理されたクロックを使用すべきであり、証拠は修理が状態を変更する前に保持されるべきである。

法的因果関係は、予見可能性、遠隔性、契約範囲など、この技術的シーケンスを超えた質問を含む。しかし、裁判所、保険会社、または会員レビューは、システムが許可された状態からどこで逸脱したかを最初に知らなければ、それらに賢明に答えることはできない。

サービス契約は、適切な機密性の下でこの証拠へのアクセスを約束すべきである。重大な過失の証明を必要とする責任例外は、何が起こったかを示す唯一の記録をプロバイダーが管理している場合、空疎である。

RIPE NCC の2021年のインシデントは具体的な管理ケースであり、普遍的な損失の証明ではない

RIPE NCC の2021年1月の事後分析は、地域間転送の流出により、システムが関連する子証明書の前に更新された親証明書を公開したと報告した。子は一時的にリソースを過剰請求した。一部の古い依拠当事者実装は、マニフェスト内の一つが無効であればすべての証明書を拒否することで応答した。

組織は、327の依拠当事者インスタンスが影響を受けたと推定し、イベントが停止をもたらした可能性があると述べた。より厳格なシーケンシング、より迅速な再発行、最終的にアトミック公開を提案した。この説明は、レジストリ管理の生産障害とバリデーター固有の増幅を特定する。

これはまさに免責事項監査がテストすべきケースである。リソースホルダーは必ずしも誤った ROA を作成したわけではない。認証プロセスは一時的な矛盾を生み出した。古いバリデータが影響範囲を拡大した。ネットワークポリシーがペイロード損失が到達可能性を変更するかどうかを決定した。いくつかの管理が重要であったが、最初の逸脱は証明書公開シーケンスにあった。

公開証拠は、顧客損失の額、影響を受けたネットワークのアイデンティティ、またはいずれかの条項の執行可能性を確定しない。損害賠償を発明するために使用されるべきではない。それは予見可能性を確立する：証明書順序の欠陥は公開リポジトリに漏洩し、バリデータは異なる反応を示し、ルーティングの結果が可能である。

このようなイベントの後、ベストエフォート条項はなぜ絶対的な継続性が約束されなかったかを説明するかもしれない。プロバイダーがホスト型当局に適切な注意を払ったか、監視が矛盾したチェーンを検出すべきであったか、影響を受けた当事者が十分に迅速な救済を受けたかには答えない。

適切な制度的対応は、スローガンではなく管理に基づくレビューである。RIPE NCC のアトミック性への移行は、原因を減らしたため価値があった。契約設計はそのエンジニアリングインセンティブを強化すべきである。

ARIN の2025年のインシデントは、狭い範囲でも結果的な欠陥を露出できることを示している

ARIN の2025年10月の公開インシデントレポートは、転送中の ROA サポートの展開に続いた。ARIN は、顧客レポートがホスト型 RPKI に影響を与える問題を明らかにしたと述べ、進行中の転送を一時停止し、サービスをレビューし、特定の ROA 構成条件の下で一人の顧客が影響を受けたことを発見した。修正を展開し、検証ステップを追加した。

通知は適切に限定されている。一人の影響を受けた顧客は、地域的な失敗の証拠ではない。レポートはルーティング損失を定量化したり、すべての関連アナウンスが到達不能になったとは述べていない。レジストリ管理の転送機能におけるコード欠陥がホスト型顧客の ROA 状態に影響を与えることができることを示している。

このインシデントは実用的な契約上の質問を提起する。顧客は、転送処理が一時停止されている間に問題を認証できる緊急ルートを持っていたか？転送前の ROA 状態は保持されたか？顧客は、ホスト型出力が期待される構成からいつ逸脱したかを証明できたか？責任配分は、ホルダーのミスと ARIN が後で修正した展開された欠陥を区別したか？

ARIN は、ソース組織に転送前後で ROA 有効性を確認し、可能であれば事前に関連 ROA を修正するよう助言した。それは慎重なホルダープラクティスである。ソフトウェア欠陥の著作権をホルダーに移転するものではない。両方のステートメントが真であり得る：ユーザーは重要な変更を検証すべきであり、サービスオペレーターは自らが管理する機能における合理的な注意に対して責任を負うべきである。

バランスの取れた条項はまさにそれを言うだろう。タイムリーなホルダー検証に特定の救済を条件付けながら、立証されたサービス欠陥に対する責任を保持する。包括的除外はより単純であるが、インセンティブをうまく調整しない。

顧客はしばしば証明書当局に対する直接の救済なしに結果を負う

ルーティング中断によって最も目に見えて害を受ける当事者は、RPKI 規約を受け入れたリソースホルダーではなく、影響を受けたネットワークの企業顧客である可能性がある。その顧客は、クラウドサービス、通信、または公開システムへのアクセスを失う一方で、レジストリと直接契約を結んでいない可能性がある。

ARIN の規約は、広範な除外と補償文言の中で、顧客およびクライアントを含む請求に明示的に対処している。RIPE NCC および APNIC の資料も第三者リスクを外部に配分する。レジストリの観点からは、これは無制限のクラスの見知らぬ人が公開証明書への依拠を請求に変換するのを防ぐ。

顧客の観点からは、結果は救済ギャップである。その請求は通常、そのサービス契約の下で接続プロバイダーに対して存在する。プロバイダーは、上流で低い上限または広範な除外に直面する可能性がある。最初のエラーが独立して修正できない証明書サービスで発生したとしても、リスクはオペレーターに蓄積する。

これは、顧客がレジストリに対して無制限の直接権利を受け取るべきであるという意味ではない。実行可能な設計は契約チェーンを使用できる。オペレーターは接続契約に従って顧客を補償する。リソースホルダーまたはオペレーターは、レジストリ管理の障害を証明した場合に比例した上流救済を受ける。保険は残存する結果的損失をカバーする。代位と通知ルールは重複回復を防ぐことができる。

重要な公共サービスの場合、直接的な運用権限が損害賠償よりも重要である場合がある。認証された下流オペレーターは、明らかな証明書エラーを報告し、範囲指定されたインシデント確認を受け取り、ホルダー関係が検証されている間にルーティングを保護するために必要な証拠を取得できるべきである。レジストリは、顧客からのルーティング指示を受け入れる必要はないが、技術的に信頼できる証拠に耳を傾けるべきである。

したがって、免責事項監査は、誰が回復できないかだけでなく、下流の害が修正可能な当事者にどのように到達するかを述べるべきである。

合理的な免責事項は管理と救済のテストを通過すべきである

最初の質問は管理である。除外されたリスクは、プロバイダーが排他的または主に管理する行動から生じるか？ホスト型鍵運用、証明書シーケンス、リポジトリ公開、サービス認証は、強いプロバイダー管理領域である。ホルダーのルーティング意図、ルーター設定、顧客の事業継続はそうではない。

第二は防止可能性である。有能なプロバイダーは、アトミック更新、検証、職務分離、期限切れ監視、またはテスト済みロールバックを通じて、合理的に障害を防止できたか？絶対的な保護は不可能であるが、通常の管理は回避不可能な失敗と不十分な運用を区別できる。

第三は検出可能性である。プロバイダーは、外部で有効な結果を監視したか、それとも自身のコンポーネントのみを監視したか？矛盾した証明書チェーンを見ることができなかったプロバイダーは、それを直ちに検出して封じ込めたプロバイダーよりも強いガバナンス問題を持つ可能性がある。

第四は救済である。影響を受けたホルダーは、独立した緊急チャネルを通じて認証し、重要な期限やルートフィルタリングの前に修正を確保し、検証可能な通知を取得できるか？運用上の修正が迅速で信頼できる場合、広範な財務除外はより防御可能である。

第五は証拠である。請求者は、最初の逸脱と他の当事者による貢献を確立するために十分に保持された情報を受け取るか？証拠アクセスなしの過失例外は実用的な保護をほとんど提供しない。

第六は比例性である。上限は、予見可能な直接損失、サービス料金、保険、またはプロバイダーの過失の程度と何らかの関係があるか？名目上の上限は、通常のベストエフォート中断には許容されるかもしれないが、意図的または重大な過失による証明書誤用には不十分である。適用される法律がすでに除外を制限している可能性がある；契約は後の訴訟に境界を発見させるべきではない。

これらの質問は、請求者の成功を約束するものではない。免責事項が制度的権力と制度的責任の間の公正な関係を保持するかどうかをテストする。

責任は失敗クラスによって配分されるべきである

ホルダー作成の ROA コンテンツの場合、認証、プレビュー、実行が正確であったとき、ホルダーが主要な責任を負うべきである。プロバイダーは、署名前にプレフィックス、発信元、最大長さの明確な表現を提供し、許可された要求を保持し、迅速な修正を提供すべきである。

証明書に流れ込むレジストリ記録エラーの場合、レジストリは、証明書が自ら管理する登録状態と一致することを検証する責任を負うべきである。基礎となる登録自体が争われている場合、契約はルーティング結果を通常のユーザーリスクとして扱うのではなく、別のレビュールートを提供すべきである。

認証ソフトウェアの欠陥の場合、サービスオペレーターは、開発、テスト、変更管理、および応答に関連する適切な基準を負うべきである。通常の過失に対しては責任を上限付きにすることができ、重大な不正行為、既知の欠陥の繰り返し、または許可されていない行動に対してはより強力な救済を保持する。

リポジトリ転送障害の場合、公開者は、合理的な可用性、意味論的整合性、鮮度監視、プロトコル多様性に対して責任を負うべきである。オペレーターは、キャッシュ、更新、サポートされたバリデータの実行の義務を保持する。

依拠当事者欠陥の場合、ソフトウェアメンテナーと展開オペレーターは、契約、サポート状況、更新プラクティスに従って責任を負う。リポジトリは、標準に準拠した公開と予見可能な互換性通信に対して責任を負い続ける。

ルーターポリシーの場合、ネットワークオペレーターは最終決定を所有する。レジストリは、すべての経路が受け入れられることを保証すべきではない。しかし、誤った証明書がポリシーが消費した無効分類を予測可能に引き起こした場合、ローカルポリシーは因果関係を断ち切らない。

下流の事業損失の場合、顧客契約、緩和、直接効果の証明が最初の救済を決定する。オペレーターが他方当事者の管理された障害を証明する場合、上流配分は可能であるべきである。

これらのルールを含むテーブルは、差別化されていない大文字の除外のページよりも正当性のために多くを行うだろう。

修正の最初の数時間は、数年の訴訟よりも価値がある

ルーティング被害は、契約紛争よりもはるかに速く発生する可能性がある。したがって、サービスは財務責任から独立した緊急修正コミットメントを必要とする。

ホルダーは、継続的に監視されるチャネルを通じて、疑わしい証明書、ROA、失効、または欠落した公開を報告できるべきである。認証は、その経路が侵害されたり利用できなくなった場合に備えて、通常のアカウント経路以上のものを使用すべきである。プロバイダーは報告を確認し、影響を受けるブランチを特定し、さらなる害を防ぐために必要な行動のみを凍結する。

次のステップは、期待状態と公開状態の安全な比較である。プロバイダーが自らのエラーを確認した場合、文書化された緊急手順を通じて正しいオブジェクトを発行または復元すべきである。ホルダーの指示が誤っていた場合、サービスは履歴を変更せずに認証された交換を促進すべきである。権限が争われている場合、範囲指定された抑制は、レビューされていない管理移転よりも安全である可能性がある。

外部収束は検証されなければならない。発信元で修正を公開しても、独立したバリデータがそれをフェッチしたことや RTR クライアントが更新したことを証明しない。インシデントは、定義されたプローブセットが修復されたブランチを検証するまで運用上オープンのままであるべきである。

署名された通知は、オブジェクトダイジェスト、影響を受けるプレフィックス、時刻を、プライベートアカウント素材を露出せずに特定すべきである。トランジットプロバイダーと顧客は、その後、実際の修正を不正なメッセージから区別できる。通知は、テストされたバリデータの下でイベントが無効、未検出、または別の条件を生成したかどうかを述べるべきである。

これらの義務は、結果的損害が除外されたままでも約束できる。それらは、機関の独自の証明書権限と、それだけが提供できる救済を整合させる。緊急コミットメントを満たさないことは、その後、責任のための別個のより防御可能な根拠になることができる。

証拠アクセスは過失例外が本物かどうかを決定する

ARIN、RIPE NCC、APNIC はそれぞれ広範な技術的または法的素材を公開しているが、個々のインシデントは非公開の証拠に依存する可能性がある：アカウント認証、許可された要求内容、証明書生成イベント、鍵操作、公開時間、セキュリティアラート、スタッフ行動。

プロバイダーにはこの素材を保護する正当な理由がある。個人情報、セキュリティ詳細、他のホルダーに関するデータを含む可能性がある。完全な公開開示は新たなリスクを生み出す。答えは制御されたアクセスであり、不在ではない。

規約は、一定期間の保持を要求し、影響を受けたホルダー、独立レビューアー、保険会社、または権限のある機関が機密性の下で関連する抽出物を取得できるようにすべきである。暗号ダイジェストと時刻証明は、すべてのシステム詳細を露出せずにオブジェクト状態を証明できる。セキュリティに敏感な記録は、限定された調査結果を公開する中立の専門家によってレビューされることができる。

証拠には否定的な事実を含めるべきである。許可された失効要求が存在しない場合、プロバイダーはそれを確立できるべきである。正しいオブジェクトが特定の時間にリポジトリに到達した場合、外部観測がそれを裏付けるべきである。ホルダーが矛盾した ROA について繰り返し警告を無視した場合、それらの通知は重要である。

請求期間は発見を考慮すべきである。請求者が権利を知っていたか合理的に知り得た後1年の期間は、目に見える停止には管理可能かもしれないが、隠された証明書効果は後で発見される可能性がある。正確な法的結果は異なる；運用上、証拠はもっともらしい請求が調査される前に破壊されるべきではない。

機関は、重大な過失に対する責任が存在すると信じられながら、重大な過失を回避不可能なイベントから区別するために必要な記録を差し控えることはできない。監査は、例外の文言とともに証拠権限をスコアリングすべきである。

上限は、モラルハザードではなく、保険と注意深いサービス設計を奨励すべきである

無制限の RPKI 責任は、レジストリがホスト型サービスの提供を思いとどまらせたり、小規模ネットワークの手の届かない価格にする可能性がある。したがって、上限は本質的に違法ではない。設計の質問は、上限がどのような行動を奨励するかである。

無料またはバンドルされたサービス料金にのみ結びついた上限は、プロバイダーが実質的な管理を行使する場合でもゼロに近づく可能性がある。これはモラルハザードを生み出す可能性がある：機関は集中化の効率とガバナンスの利益を享受しながら、運用上の欠点のほぼすべてを外部化する。固定名目額も、直接的な対応コストや予見可能な損失に関係がない場合、同じ問題を抱えている。

階層化された上限はより一貫している。プロバイダーの過失のない通常の中断は、サービス復旧を超える損害賠償を伴わないかもしれない。プロバイダー管理機能における通常の過失は、会費、保険、または公開された金額にリンクされた意味のあるが境界のある直接損失上限を伴う可能性がある。重大な過失、故意の不正行為、許可されていない証明書行動、隠蔽は、法律が許す範囲でより高い上限または契約保護なしを受ける可能性がある。

結果的損失は制限されたままである一方、合理的なインシデント対応コストは回収可能であるべきである。ネットワークは、逸失利益請求が遠すぎる場合でも、緊急エンジニアリング、顧客通知、一時的なトランジット変更を必要とする可能性がある。これらの直接的な緩和コストは立証が容易であり、迅速な封じ込めを奨励する。

レジストリは、機密のポリシー詳細を露出せずに、関連するサイバーまたは専門職責任保険を維持しているかどうか、およびカバーされるリスクの大まかなクラスを開示すべきである。リソースホルダーは、その後、独自の継続性保険を購入するかどうかを決定できる。会員を通じた集団保険は、リスクが存在しないふりをするよりも効率的である可能性がある。

目標は、すべての ROA の周りに損害賠償市場を作ることではない。障害を防ぐ最適な立場にある当事者が、予防に投資するために十分なマイナス面を保持することを確実にすることである。

委任型 RPKI は管理を変更するが、親関係を消去しない

リソースホルダーは、委任された認証局を運用することにより、ホスト鍵依存を減らすことができる。証明書と署名付きオブジェクトを管理し、親認証関係に従う。また、独自のリポジトリを実行するか、公開サービスを使用できる。これは、運用管理を洗練されたネットワークの責任と整合させることができる。

委任は普遍的な答えではない。安全な鍵管理、サポートされたソフトウェア、監視、公開継続性、インシデント対応、スタッフ能力を必要とする。不十分に運用された委任当局は、ホスト型サービスよりも多くのリスクを生み出す可能性がある。小規模ホルダーは合理的にレジストリのインフラを好むかもしれない。

親は依然として重要な機能を管理する。リソース関係に基づいて子証明書を発行し、定義された状況下でその証明書を更新または失効させる可能性がある。親と子の間のプロビジョニングは失敗する可能性がある。リソース転送は認証されたセットを変更する可能性がある。委任当局が親運用リポジトリの下で公開する場合、公開管理は共有されたままである。

規約は、委任ユーザーが単にすべてのリスクを受け入れると述べるのではなく、この分割をマッピングすべきである。ホルダーは自身の鍵セキュリティとオブジェクト内容を所有する。親は、自身の管理内で正確でタイムリーな親認証とプロビジョニングを所有する。公開プロバイダーは自身が運用するサービスを所有する。それぞれが互換性のある証拠と緊急連絡先を必要とする。

選択肢はまた実用的な移植性を必要とする。ホルダーは、重複または欠落した権限を避けるテスト済みシーケンスを通じて、ホスト型と委任型の取り決めの間を移動できるべきである。責任解決策が「自分で実行する」であるが、ホスト型サービスからの終了が安全でない移行を生み出す場合、選択肢は不完全である。

成熟したレジストリは両方のモデルを提供し、それらの異なる責任マップを公開できる。それは、委任をすべての親義務の放棄として使用せずに、オペレーターの自律性をサポートする。

一方的な規約変更には継続性の保護が必要である

RPKI サービスの規約は、多くの場合、通知、公開、または継続使用を通じて修正を許可する。標準、法律、セキュリティ脅威が進化するため、プロバイダーはその柔軟性を必要とする。認証局は時代遅れの手順に永遠に拘束されることはできない。

同じ柔軟性は、オペレーターがサービスを重要なルーティングに統合した後にリスクを変更する可能性がある。新しい上限、より狭い過失例外、より短い請求期間、より広範な失効権限は、依拠の価値を実質的に変更する可能性がある。ホルダーは、鍵、リポジトリ、運用手順を移動せずに直ちに離脱できない場合がある。

したがって、重要な修正は、明確な事前通知、新旧条項の比較、合理的な移行期間を受けるべきである。緊急セキュリティ変更はより迅速に発効できるが、狭く範囲指定され、後でレビューされるべきである。過去のバージョンはアクセス可能なままで、インシデント日の権利を特定できるようにすべきである。

ホルダーには終了経路があるべきである。委任認証、別のサポートされた公開取り決めに移動するか、秩序あるプロセスを通じて署名付きオブジェクトを廃止することができる。終了は、ホルダーが新しい責任条項を辞退したためだけに、有効な認証にギャップを生み出すべきではない。

会員ガバナンスは正当性を追加できる。レジストリが会員組織である場合、証明書管理と責任の主要な変更は、通常のウェブサイトテキストとして扱われるのではなく、会員の精査を受けるべきである。技術コミュニティは運用上の結果をレビューすべきであり；法的レビューだけでは、誤ったオブジェクトがどれだけ速く伝播するかを見逃す可能性がある。

プロバイダーも利益を得る。透明な修正は驚きを減らし、広範な裁量が安定した制度的プロセス内で行使されることを示す。インターネットセキュリティ依存を管理する条項は、日常の消費者機能よりも注意深く管理されるべきである。

裁判所はインターネット全体の理論ではなく、境界のある技術的記録を必要とする

紛争が裁判所または仲裁に達した場合、請求者は地球上のすべてのネットワークが証明書をどのように扱ったかを証明する必要はない。主張された損失に関連する経路を証明すべきである：許可された状態、誤ったオブジェクトまたは公開、バリデータ出力、オペレーターポリシー、BGP 結果、顧客効果。

プロバイダーは各リンクに挑戦できる。ホルダーの要求は正確だったか？別の有効な ROA が経路を保持したか？オペレーターはサポートされたソフトウェアを使用したか？経路は別の理由ですでに利用できなかったか？合理的な緩和が損失を減らした可能性があるか？これらは保持された証拠に適した事実上の質問である。

フォーラムはまた、直接損失と遠隔損失を区別すべきである。緊急エンジニアリングと文書化されたトラフィック損失は、顧客の予測された将来収益よりもイベントに近い可能性がある。契約文言と適用される法律が回復可能性を決定するが、技術的近接性は分析を整理するのに役立つ。

規制当局または裁判所は、すべての RPKI に一つの運用モデルを課すことに慎重であるべきである。厳格責任は有用なホスト型サービスを抑制する可能性がある。完全な免責は重要な信頼機能の周りのインセンティブを弱める可能性がある。過失と管理に基づく基準はより適応可能である。

独立した専門知識が多くの場合必要となる。RPKI 証明書パス、マニフェスト、キャッシュ、ルートポリシーは専門的である。専門家のリプレイは、仮想的なスクリーンショットではなく、保存されたオブジェクトと名前付きソフトウェアを使用すべきである。利益相反は開示されるべきであり、特に専門家がレビュー中の同じソフトウェアや機関に貢献している場合。

事実記録が狭ければ狭いほど、ルーティングインシデントを通じてインターネット番号リソースの政治的地位を決定することが魅力的でなくなる。証明書責任ケースは、障害のあるサービスステップを誰が管理したか、それがどのような損失を引き起こしたかに答えるべきであり、RPKI を普遍的な財産判断に変換すべきではない。

NRS は集合的な懸念を実用的な免責事項監査に変えることができる

NRS の公開憲章は、正確な番号登録、運用安定性、レジストリ権限の制限を提唱している。その NRS Shield 資料はすでにリソースホルダーに、責任、停止、終了、実用的な救済を管理する正確な契約を特定するよう指示している。これは RPKI 精査の具体的な出発点であり、NRS が認証サービスを運営するという主張ではない。

NRS は、各地域および参加国別当局をカバーするバージョン管理された証明書サービス免責事項登録を公開できる。サービスモデルごとに、証明書権限、ホルダー義務、ベストエフォート文言、過失例外、損害除外、上限、補償、請求期間、準拠法、緊急修正経路、証拠アクセス、移行権限をリストする。

登録は控えめに引用し、管理文書にリンクすべきである。各法域の法律レビューアーは、普遍的な評決を発するのではなく、不確実性を説明すべきである。オペレーターは、記載された緊急経路が機能するかテストすべきである。レジストリスタッフは、エラーを修正し、特定の保護がなぜ必要なのか説明するよう招待されるべきである。

NRS はその後、公開精査のためのアドボカシーベンチマークを公開できる。責任ある証明書サービスは無制限の損害賠償を提供する必要はない。排他的に管理する行動に対して適切な基準を受け入れ、重大な過失の例外を保持し、迅速な修正を提供し、証拠を保持し、インシデントを公開し、サービスモデル間の安全な移行を可能にすべきである。そのベンチマークの採用と実行は、RIR、許可されたオペレーター、および管轄のレビューまたは法フォーラムに残る。

集団的会員資格はまた交渉力を改善できる。小規模ネットワークは単独で地域条件を交渉できないかもしれない。グループは、レジストリの継続性を脅かすことなく、標準の明確化、保険オプション、または独立したレビューメカニズムを求めることができる。

NRS は、自らが実際に提供する会員資格およびアドボカシーサービスに同じ透明性原則を適用しなければならない。自らの会員規約における責任上限を含む。それは RPKI 認証局、リポジトリオペレーター、または証明書保護サービスではなく、この監査はそれになることを提案しない。証明書発行、公開、緊急修正、技術的証拠の保管は、関連する RIR、許可された認証または公開オペレーター、および管轄の独立レビューアーまたは裁判所に残る。NRS の役割は、それらの取り決めを研究し比較し、より明確な条件を提唱し、適切な運用および法的チャネルを通じて証拠を提示するメンバーを支援することである。制度的説明責任は、各機関が実際に保持する権限に対して判断される場合にのみ信頼できる。

バランスの取れた証明書サービス契約は平易な運用言語で書かれることができる

プロバイダーは、要求を認証し、表明された管理の下でホスト鍵を運用し、信頼できるリソース状態と一致する証明書を発行し、許可されたオブジェクト変更を正確に実行し、意味的に有効な素材を公開し、外部有効性を監視し、証拠を保持し、緊急修正サービスを維持することを約束する。

ホルダーは、認証情報を保護し、リソースおよびルーティング情報を検証し、承認前に正確なオブジェクトをレビューし、外部ルート有効性を監視し、最新の連絡先を維持し、エラーを迅速に報告し、合理的な継続性対策を運用することを約束する。

依拠当事者およびネットワークオペレーターは、サポートされた検証ソフトウェアを使用し、現在の素材を取得し、慎重なキャッシュおよびバリデータ冗長性を維持し、ローカルルートポリシーを理解し、ペイロード変更を監視し、関連するルーティング証拠を保持することを約束する。

プロバイダーは、普遍的なルート受入れ、すべての中断の不在、市場価値、顧客パフォーマンス、証明書範囲を超えたアイデンティティ、またはホルダーによって管理される事実を保証しない。結果的および投機的損失は除外または上限付きとすることができる。

プロバイダー管理のエラーが発生した場合、即時の修正とレビューを約束する。直接的な緩和コストおよびその他の損害は、過失に基づく表明された階層の下で扱われる。重大な不正行為、許可されていない証明書行動、隠蔽は、適用される法律に従い、通常の保護に対する明確な例外を受ける。

契約は、誰が緊急事態を提起できるか、アイデンティティがどのように検証されるか、応答がいつ期限切れか、どの証拠が利用可能か、独立レビューがどのように開始されるか、どの過去バージョンが適用されるかを特定する。下流当事者は、ホルダーのオブジェクトを変更する権限を取得せずに技術的通知経路を受け取る。

これらのどれも、レジストリに不可能を約束することを要求しない。契約が実際のサービスを反映することを要求する。証明書管理が集中している場合、有能な証明書管理の責任も集中する。ルーティングポリシーがローカルに留まる場合、ルーティングポリシーの責任もローカルに留まる。

制度的正当性は、権限より広くも狭くもない責任を受け入れることに依存する

RPKI は、署名された許可がネットワークが発信元を受け入れる信頼を変えることができるため価値がある。その価値は、証明書が誤っている場合は重要でなく、正しい場合は権威があると扱われると消える。機関は管理のセキュリティ利益を主張しながら、同じ管理が害を引き起こす可能性があることを否定することはできない。

オペレーターもすべての間違いを外部委託することはできない。レジストリはホルダーのルーティング設計を選択せず、バリデータをアップグレードせず、ルーターを設定せず、顧客継続性を保証しない。広範なインターネット依存は、レジストリをすべての経済活動の保険者にはしない。

防御可能な中間は最初の誤った逸脱から始まる。誰がそのステップを管理したか、どの基準が適用されたか、エラーは防止可能であったか、どれだけ迅速に検出され修正されたか、どのような結果が立証されたかを尋ねる。契約保護は、絶対的ではなく比例的であることができる。

ここで検討された公開規約は、繰り返し発生する不均衡を明らかにする。ユーザーと依拠当事者は広範なリスクを負う一方、プロバイダーはホスト型サービスが鍵、証明書ライフサイクル、公開を管理するにもかかわらず、広範な保護を保持する。一部の地域での過失例外は不均衡を狭めるが、実用的な救済と証拠アクセスをテストする必要性を除去しない。

改革は運用上から始めるべきである：正確なプレビュー、アトミック公開、外部検証、緊急修正、保存された証拠、バージョン管理されたインシデント通知。責任条件は、プロバイダー管理の過失に対する意味のある責任を通じてそれらの管理を強化し、遠隔で無制限の請求を引き続き拒否すべきである。

NRS は、このコンパクトを地域間で可視化し、リソースホルダーの集合的な立場を強化するのに役立ち、必要なレジストリを弱めることなく。成功の尺度は損害賠償額の大きさではない。それは、証明書権限を持つ機関がそれを正確に使用し、迅速に修正し、正直に説明するすべてのインセンティブを持つかどうかである。

証明書サービスは、その法的立場がその技術的役割と一致するときに信頼を得る。責任なき権限は安定した信頼のアンカーではない。

出典