要約

  • NRS の役割は、アドボカシー、研究、キャンペーン、会合開催、権限を受けた会員の代表です。運用行為は、RIR トラストアンカー事業者、認可された RPKI サービスプロバイダ、保持者、依拠当事者に属します。NRS の立場を引用することは、NRS がそれらを実行している証拠でも、BTW による承認でもありません。
  • 事業者のデフォルトは、リソース保持者が自身の秘密鍵を生成または生成を許可し、署名権限を管理し、資格のある運用サポートを選択できる委任 CA であるべきです。ホスト型署名はオプションであり、実践的な参加の条件ではありません。
  • 鍵管理は証明書の自由の一部にすぎません。保持者は、適時の親証明書サービス、使用可能な公開インターフェース、エクスポート可能な署名済み状態、独立した監視、およびルートセキュリティのカバレッジを失うことなくプロバイダを移行する文書化された権利も必要とします。
  • ポータブルな公開は、通常のサービス移行としてテストされるべきです。オーバーラップ、リポジトリ同期、マニフェスト、失効マテリアル、依拠当事者の可視性、ロールバックには測定可能な受入基準が必要であり、サービスの移行によって検証ギャップが生じないようにします。
  • 緊急復旧は、日常的な鍵エスクローに依存すべきではありません。オフラインの復旧認証情報、マルチパーティ承認、事前合意された代替鍵手順、範囲限定の継続措置により、通常の署名は保持者が行うままに制御を回復できます。
  • ユーザー制御の下位鍵は親 CA を無力化しません。事業者のルールは、遅延発行、選択的失効、リポジトリ妨害、説明のないリソース削減などの不利な行為を、通知、証拠、迅速なレビュー、救済手段によって抑制しなければなりません。
  • 小規模事業者には、サポートされた委任が必要です。管理されたハードウェア、セレモニー、ヘルスチェック、トレーニング、ユーザーのセキュリティドメインにおける契約運用などが含まれます。重要な違いは、誰が物理的に各コマンドを入力するかではなく、誰が権限と退出を管理するかです。
  • 設計は、観察可能な演習によって評価されるべきです。独立した鍵生成、定期的なロールオーバー、公開プロバイダの移行、妥協からの復旧、親との紛争、依拠当事者の収束などです。これらのテストに耐えられない権利は、記述的な約束にすぎず、運用上の権利ではありません。

役割の境界は証拠の一部

NRS 自身の表明した立場が、この分析の最初の境界を提供します。NRS は、分散化、退出、移植性、冗長性、および裁量的な隘路の削減を求める会員制のアドボカシー組織です。Lu Heng の「NRS が存在する理由」に関するノートは、NRS が製品を販売したり、商用ソリューションを実装したりしないことを直接述べており、その役割はガバナンスの方向性を変えることです。したがって、NRS は研究を発表し、キャンペーンを組織し、影響を受ける事業者を集め、会員を支援し、権限を与えた組織を代表することができます。その代表権を誰かに対するレジストリ権限に変えることはできません。

実装層は別個です。RIR トラストアンカー事業者、認可された RPKI サービスプロバイダ、保持者、依拠当事者は、この記事に関連する権威あるレジストリ記録、割り当て、転送認識、RPKI または RDAP 運用、技術的フェイルオーバー、拘束力のあるレビュー、破産行為、法的に強制された救済措置に対して責任を負います。NRO は5つの RIR を調整しますが、NRS の別名ではありません。IANA 番号サービスは定義された調整役割を果たし、NRS の部門ではありません。裁判所と合法的な公的機関は、それぞれの法制度が実際に与える権限を保持します。

BTW の役割もまた別個です。BTW は観察可能な構造を報告し、一次情報源を確認し、提案を提案としてラベル付けします。NRS のアドボカシーを事実に変換したり、NRS に代わってキャンペーンを行ったり、整合性から権限を推測したりしません。この現実であってアドボカシーではない規律が、この記事の制度名詞が重要である理由です。NRS からの勧告、RIR による行為、裁判所による命令は、三つの異なるものです。

RPKI の権限は、単一のサービスが統一されたように見せかけても分割されている

Resource Public Key Infrastructure は、しばしば単純な製品選択として事業者に提示されます。ホスト型サービスを使用するか、委任 CA を実行するかです。その説明は有用ですが、不完全です。その下にはいくつかの権限が存在します。親 CA は子のリソース保有を証明します。子は秘密鍵を管理し、署名済み製品を発行します。リポジトリは証明書、失効情報、マニフェスト、ルート起点オブジェクトを利用可能にします。依拠当事者はそれらの製品を取得して検証します。運用ポータルはリクエストを認証し、顧客に代わって署名を行う場合があります。

1つの機関がこれらすべての機能を実行する場合、ユーザー体験はスムーズになります。また、権力がどこにあるかが不明瞭になる可能性もあります。ユーザーは起点を承認するためにクリックする一方で、サービスが関連する秘密鍵を生成して保持する場合があります。同じ機関が、リクエストの認証方法、オブジェクトの公開時期、アカウントの復旧方法、エクスポートの可否を決定する場合があります。顧客はサービス関係を持ちますが、必ずしも独立して使用可能な証明機能を持っているわけではありません。

この区別が重要なのは、ルートセキュリティ権限が実際の接続性を形成する可能性があるからです。ルート起点認証は、それ自体ではルーターに指示しません。依拠ネットワークが検証済み状態をどう使用するかを決定します。しかし、広範な検証により、署名済み状態は実際の結果をもたらします。誤った撤退、古い公開、過度に広い認証、妥協された鍵は、ルートがどのように分類されるかに影響を与える可能性があります。したがって、通常の署名と復旧を集中させることは、正式なリソース登録が変わらなくても、ガバナンス上の依存関係を生み出します。

関連する標準は、すべての機能を1つの運用者に制御させることを要求していません。RFC 6480で説明されている RPKI アーキテクチャは、インターネット番号リソースに結び付けられた階層を確立します。RFC 6487の証明書プロファイルは、リソース証明書が権限を表現する方法を制約します。署名オブジェクトとリポジトリの標準は、製品が利用可能にされ検証される方法を定義します。証明書登録と公開プロトコルは、組織境界を越えた対話をサポートします。このモジュール性は単なるエンジニアリング上の便宜ではありません。制度的選択の余地を提供します。

レジストリ事業者は、その余地を意図的に使用すべきです。リソース認識、親証明、子署名、リポジトリ運用、依拠当事者検証は、ポリシー、契約、監査、インシデント対応において区別されたままであるべきです。プロバイダは複数の機能を提供できますが、それらを組み合わせることで、ユーザーが後でそれらを分離する権利を消し去ってはいけません。機関は、行使する各権限を正当化する必要があり、顧客が便利なインターフェースを好むという理由だけで広範な権限を継承すべきではありません。

自己満足に対する最も強い警告は、階層そのものに由来します。秘密鍵を管理する子であっても、主権者ではありません。親は証明書の再発行を拒否し、ポリシーが許す場合には証明されたリソースを削減し、証明書を失効させ、タイムリーなロールオーバーをサポートしない可能性があります。リポジトリ事業者は公開を遅らせたり誤って処理したりする可能性があります。依拠当事者は、リフレッシュと有効期限のルールが解決するまで古いマテリアルを保持する可能性があります。したがって、目標は、鍵の保持が依存関係を排除するというロマンチックな主張ではありません。それは依存関係の立憲的な配分です。各アクターは必要な最小限の権限を受け取り、各権限には証拠、時間制限、レビューがあります。

ユーザー保持鍵が通常の推定であるべき

デフォルトの取り決めは、リソース保持者によって制御されるセキュリティ境界内での鍵生成から始めるべきです。その境界は、保持者の施設にあるハードウェアセキュリティモジュール、保持者のアカウント内の専用クラウドセキュリティサービス、オフラインデバイス、または契約に基づいて運用される管理アプライアンスなどがあります。正確な機器はリスクと規模を反映するべきです。重要なのは、保持者が使用を許可し、プロバイダを交換し、鍵操作の証拠を取得し、レジストリ事業者が一方的に通常の署名権限を行使するのを防げることです。

鍵を生成するだけでは十分ではありません。制御とは、保持者が誰がそれを有効化できるか、どの承認ルールによるか、どの署名済み製品に対してか、どの監査記録で、どの期間かを決定することを意味します。大規模なアドレス保持者には2名ルールが適切かもしれません。小規模な事業者には、1人の責任ある管理者と独立した復旧連絡先で十分かもしれません。リスクの高い操作（広範なルート認証や疑わしい妥協後の交換など）は、定期的な更新よりも強い承認を必要とする場合があります。

レジストリ事業者は、特定の高価なアプライアンスを指定することなく、委任管理のベースラインを公開すべきです。ベースラインは、エントロピー、サポートされるアルゴリズム、安全なバックアップ、アクセスログ、職務分離、失効準備、時刻同期、管理者変更、保護された復旧マテリアル、廃棄に対処するべきです。必須のセキュリティ成果とオプションの実装パターンを区別すべきです。事業者は、好みのベンダーから購入することなく、必要な制御を証明できるべきです。

ユーザー管理の推定は、運用が外部委託される場合にも適用されるべきです。マネージドセキュリティ企業が HSM を管理し、署名をスケジュールし、公開を監視する場合があります。ユーザーがアカウント、承認ポリシー、交換権限を管理している場合、これは委任運用のままです。逆に、「顧客管理」とラベル付けされたデバイスは、プロバイダしか設定をエクスポートできず、新しい管理者を承認できず、公開を切り替えられない場合、ほとんど独立性を提供しません。ガバナンスは、マーケティングの説明ではなく、実効権限を調査すべきです。

一部の組織はホスト型署名を選択するでしょう。スタッフが不足している、小規模なリソースセットしか運用していない、またはシンプルなサービスを重視する場合があります。レジストリ事業者は、強力な認証、可視的な承認、測定されたサービス品質でその選択をサポートすべきです。しかし、ホスト型ユーザーは明示的なアップグレードパスを受け取るべきです。自身の鍵を確立し、必要な下位証明書関係を取得し、公開を移行し、依拠当事者の可視性を確認し、罰則的な料金や裁量的な遅延なしにホスト型署名を終了できるべきです。

デフォルトルールは市場を形成します。委任運用に例外的な承認、長い交渉、専門的な個人連絡先が必要な場合、ポリシーがオプションと称しても、ホスト型制御が実際の標準になります。レジストリ事業者はその負担を逆転させるべきです。適合する委任リクエストは日常的であるべきです。拒否は特定のセキュリティまたは承認の欠陥を特定し、その修正方法を示し、迅速な独立したレビューを可能にするべきです。レジストリ事業者は技術的要件を強制できますが、それらの要件を自社のサービスシェアを保護するために使用すべきではありません。

同じ原則が鍵の証拠にも適用されます。ユーザーは、鍵作成、証明書リクエスト、証明書発行、オブジェクト署名、失効、ロールオーバーの検証可能な記録を受け取るべきです。これらの記録は、秘密鍵を公開することなく、監査や紛争の際に有用であるべきです。プロバイダがセレモニーを実行する場合、ユーザーは何が起こったかを示すのに十分な証明とログを受け取るべきです。証拠はサービス変更時に顧客とともに移動するべきです。

証明書の権利は束であり、単一の管理請求ではない

鍵を「ユーザー制御」と呼ぶことは、関連する権利が特定されなければスローガンになりかねません。最初の権利は、生成または独立して許可された生成です。2番目は排他的な通常使用です。レジストリ事業者もプロバイダも、インフラを運用しているという理由だけで新しい署名済み製品を作成できてはなりません。3番目は信頼できる記録による検査です。4番目は通常のロールオーバーと緊急妥協手順による交換です。5番目はプロバイダ間の移動です。6番目は古い権限の安全な引退による終了です。

束には適時の親サービスが含まれなければなりません。子は、親が証明書リクエストを無視したり、変更を遅らせたり、正当な代替鍵を拒否したりする場合、無期限に有効な証明書を維持できません。レジストリ事業者は、日常的な発行、計画的なロールオーバー、リソース変更、緊急妥協のためのサービス目標を設定すべきです。時間は完全な認証済みリクエストから計測されるべきです。リクエストに欠陥がある場合、応答は欠陥を特定し、不透明なキューを再開しないようにすべきです。

また、公開へのアクセスも含まれなければなりません。正しく署名しても、製品を確実に利用可能にできない子 CA は、有用な独立性を持ちません。保持者は、資格のあるリポジトリプロバイダを選択でき、適切な場合には自身の準拠リポジトリを運用でき、現在の完全なインベントリを取得できるべきです。リポジトリの条件は、無関係な会員紛争や商用サービスに公開の継続を依存させるべきではありません。

データポータビリティも別の権利です。保持者は、公開証明書、署名済みオブジェクト、マニフェスト、失効製品、リポジトリパス、関連するタイミング情報、設定、監査履歴を文書化された形式でエクスポートできるべきです。秘密鍵は設計上エクスポート不可かもしれませんが、それによってユーザーが閉じ込められるべきではありません。代替鍵と調整された移行が可能でなければなりません。エクスポート不可は鍵を保護できますが、証明関係の非移植性を正当化することはできません。

束には独立した観察が含まれます。ユーザーは、アクションを実行したのと同じダッシュボードを信頼する必要はありません。外部モニターは、依拠当事者としてリポジトリを取得し、リソースチェーンを検証し、期待される製品と観測された製品を比較し、消失、不整合、予期しない起点変更、有効期限の接近を警告するべきです。レジストリ事業者は、保持者とサードパーティのモニターが不利な変更を迅速に検出できるように、標準化されたフィードまたは通知をサポートすべきです。

最後に、証明書の権利には救済手段が必要です。サービスが遅延または妨害されたユーザーは、ルーティングの結果を理解する迅速なチャネルを持つべきです。レビューは、公開の復元、一時的な継続措置、修正された発行、保存状態の保持を命じることができるべきです。金銭的補償は後で重要になるかもしれませんが、迅速な技術的修正の代わりにはなりません。関連する証明書が期限切れになって初めて権利が主張できるのであれば、それは効果的な権利ではありません。

公開は契約上だけでなく事実上移植可能でなければならない

リポジトリの移植性は、名目上の自由が失敗する可能性が最も高い場所です。公開には、名前、場所、同期、マニフェスト、証明書と失効状態、取得動作、依拠当事者のキャッシュが含まれます。ユーザーのポータルからは完全に見える移行でも、バリデータ間で一貫性のないビューを生み出す可能性があります。したがって、レジストリ事業者は移行を、準備、オーバーラップ、観察、クロージャを伴う測定可能な技術イベントとして定義すべきです。

移行の前に、退任するプロバイダは完全なインベントリと最近の運用履歴を提供するべきです。就任するプロバイダは、必要な現在の製品をすべて公開し、必要な可用性を維持できることを確認するべきです。子は、適用可能な標準に従って、新しいマニフェストやその他の時間依存のマテリアルを準備するべきです。親と子の参照を確認すべきです。監視は、複数の独立した取得ポイントにわたってベースラインを確立するべきです。

移行は、どちらのリポジトリも使用可能な状態を提供しない瞬間を避けるべきです。正確なシーケンスは証明書とリポジトリの設計に依存しますが、支配的な要件は明確です。古い構成と新しい構成には、参照が変更されている間も検証を維持する、境界のあるオーバーラップまたは別の標準準拠の方法が必要です。事業者は、異なる時間にリフレッシュする依拠当事者をモデル化するべきです。新しいエンドポイントが1つのテストリクエストに応答したからといって、成功を宣言することはできません。

RFC 8181の公開プロトコルと RFC 8182のリポジトリデルタメカニズムは、サービス境界と取得動作がなぜ別途注意を要するかを示しています。公開インターフェースにより、CA は自身が運用しないリポジトリに製品を提出できます。デルタ取得は、依拠当事者の効率的な同期を改善できます。どちらのプロトコルも単独では、制度上の移植性を保証しません。資格情報、リポジトリ参照、サービス条件、履歴状態、監視、調整された変更には、依然としてガバナンスが必要です。

レジストリ事業者は、資格のあるプロバイダが共通の手順を通じて顧客を受け入れ、解放することを要求すべきです。資格は、プロトコル準拠、可用性、一貫性、インシデント対応、エクスポートの完全性、移行協力をテストするべきです。顧客の証明書や署名済み製品に対する所有権を主張する契約条項を禁止すべきです。退出のための料金は合理的な作業を反映すべきであり、ユーザーを閉じ込める戦略的価値を反映すべきではありません。

移行演習は緊急時に行うべきです。保持者は、非実稼働の子環境を作成し、サービス間で移動し、独立した検証を確認する年次テストを実行するかもしれません。大規模保持者は、より長い間隔で制御された実稼働移行を実行するかもしれません。プロバイダは、遅い、到達不能、または財政的に困難な退任事業者を含む、レジストリ事業者全体の演習に参加すべきです。目的は、時間が残っている間に隠れた依存関係を発見することです。

ロールバックも同様に注意が必要です。着任サービスが一貫性のない状態を公開した場合、競合する権限を作成せずに、最後に確認された良好な構成を復元する境界のある方法がなければなりません。ロールバック基準は移行前に決定されるべきです。複数のモニターからの検証失敗、重要なオブジェクトの欠落、定義された間隔を超える乖離、またはリフレッシュ不能などです。1人の責任ある移行リーダーが行動を調整し、独立した観察者が依拠当事者が実際に何を見ているかを記録します。

クロージャは、不要になった資格情報と参照を廃止し、退任事業者が新しい提出を受け入れられないことを確認し、必要な監査証拠を保存し、保持者に残留保持を通知するべきです。退任プロバイダは、移行後に公開するシャドウ機能を保持してはなりません。また、以前の状態を説明するために必要な証拠を削除してはなりません。セキュリティには、時代遅れの権限の削除と説明責任のある履歴の保存の両方が必要です。

移植性のメトリクスは、集計して公開されるべきです。レジストリ事業者は、移行時間の中央値と最悪値、観測された検証ギャップ、ロールバック頻度、不完全なエクスポート、プロバイダ原因の遅延、重要度別のインシデントを報告できます。比較可能な証拠は、会員がサービスを選択するための基礎を提供します。また、形式的に競争的なリポジトリ市場が本当に開かれているのか、それとも顧客が安全に離脱できない1つのプロバイダによって支配されているのかを明らかにします。

緊急復旧は永続的なエスクローを作成せずに権限を回復すべき

鍵の喪失と妥協は、遠い例外ではなく、避けられない設計ケースです。運用者が HSM へのアクセスを失ったり、管理者を解雇したり、災害に見舞われたり、無許可の署名を発見したり、クラウドアカウントからロックアウトされたりする可能性があります。ユーザー保持鍵を主張しながら、信頼できる復旧を提供しないガバナンスモデルは、ユーザーを集中ホスティングに押し戻します。日常的な中央エスクローを通じて復旧を解決するモデルは、別の名前で同じ集中を再現します。

レジストリ事業者は、同じ秘密鍵の復旧よりも交換を優先すべきです。鍵が妥協された疑いがある場合、コピーを復元すると攻撃者の権限も復元されます。安全な目的は、保持者を認証し、新しい鍵を確立し、適切な親証明書を取得し、古い証明書を失効または廃止し、一貫した現在の状態を公開し、依拠当事者の収束を確認することです。古い秘密鍵は、常に回復可能でなければならない宝物として扱われるべきではありません。

計画された復旧資格情報は、この移行をサポートできます。登録時に、保持者は複数の復旧権限（例えば、2人の役員と独立したセキュリティ連絡先）を特定し、それぞれが保護された資格情報を持つことができます。単一の当事者が鍵を交換するのに十分な権限を持つべきではありません。しきい値承認は、身元、役割、リソース証拠が確認された後、交換リクエストを承認できます。しきい値記録は、人事異動時に更新可能であり、定期的にテストされるべきです。

オフラインの復旧マテリアルは、改ざん防止管理の下で分離された場所に保持される場合があります。一部の組織では、これには管理者間で分割された暗号化バックアップが含まれる場合があります。特に鍵が意図的にエクスポート不可である場合、署名鍵のコピーではなく、新しい鍵セレモニーを承認する資格情報で構成される場合もあります。レジストリ事業者は、リスクに応じて両方のパターンを許容しながら、成果と証拠を定義すべきです。

緊急権限は狭くなければなりません。継続受託者またはレジストリ事業者のセキュリティ機能は、認証を容易にし、リポジトリの可用性を維持し、一時的な親アクションを要求することが許可される場合があります。ユーザーのリソースに対して無制限にルート認証を発行する能力を得るべきではありません。一時的な署名済み状態は、事前承認され、最小限の許可で、短命であり、保持者と独立したレビュー担当者に可視化されるべきです。安全な一時状態が存在しない場合、決定は日常的な管理として偽装されるのではなく、明示的であるべきです。

復旧シーケンスはインシデントを分類すべきです。妥協の証拠がない喪失は、オーバーラップ中に通常の認証を維持した制御されたロールオーバーを許可できます。妥協の疑いがある場合は、より迅速な失効分析と、最近署名されたすべての製品の綿密な検査が必要です。組織的支配の紛争には注意が必要です。技術チームは、一方の側がデバイスを所有しているという理由だけで企業の派閥を選択すべきではありません。法的無能力または解散は、認識されたリソース権限に結び付けられた別個の継続ルールを呼び出す場合があります。

時間目標はルーティングリスクに一致すべきです。アクティブルートに影響を与える疑わしい無許可認証には、数時間以内の行動が必要な場合があります。現在の製品が安全な間隔で有効なオフライン鍵の喪失は、より慎重なセレモニーを許容する場合があります。レジストリ事業者は、インシデントクラス別の目標時間を公開し、パフォーマンスを測定すべきです。緊急性は認証を消し去るべきではありませんが、認証は危機の前に設計され、危機の中で発明されるべきではありません。

すべての緊急行動には事後レビューが必要です。記録は、誰が開始したか、どのような証拠が権限をサポートしたか、どの製品が変更されたか、一時的な措置がどのくらい続いたか、いつユーザーが制御を取り戻したか、依拠当事者が何を観測したかを示すべきです。レビューは、偽陰性と偽陽性の両方を検討すべきです。真正な保持者を拒否することはリスクを長引かせる可能性があり、詐称者を受け入れることは実効的なルーティング権限を移転する可能性があります。復旧設計は両方のエラーに立ち向かわなければなりません。

レジストリ事業者は、安全なリハーサルも提供すべきです。参加者は、隔離された環境で喪失、管理者の退任、妥協された署名をシミュレートし、交換と公開チェックを実行できます。通常の運用に合格しても復旧演習をサポートできないプロバイダは、完全に資格があると扱われるべきではありません。復旧はサービスの一部であり、例外的な好意ではありません。

親 CA は依然として強力であり、それに応じてガバナンスされなければならない

委任は通常の署名の場所を変更しますが、親は依然として下位証明書を支えます。この事実は明確に述べられるべきです。親は、適切な根拠なく失効させたり、更新を怠ったり、誤ったリソースセットを証明したり、代替鍵を遅らせたり、一貫性のない失効状態を公開したりすることで、ユーザーに害を及ぼす可能性があります。ユーザー管理を称賛しながら親の力を無視するポリシーは、リスクを誤って説明することになります。

RFC 8211は、CA またはリポジトリ管理者による不利な行為を検討しており、特に制度設計に関連します。技術アーキテクチャは、すべての敵対的または誤った行為を不可能にすることはできません。ガバナンスは機会を減らし、検出を改善し、裁量を制約し、復旧を提供しなければなりません。レジストリ事業者は、親の介入を、ルートまたは中間サービスの運用の不可審査な特性としてではなく、定義された権限の説明責任ある行使として扱うべきです。

日常的な親行動は、権威あるリソース記録と認証済みリクエストに対して自動化され、透明なステータスと独立した監視が行われるべきです。手動の裁量は特定された例外のために留保されるべきです。証明書リクエストが拒否された場合、ユーザーは理由コード、依拠した証拠、修正への経路を受け取るべきです。レジストリ事業者が緊急のセキュリティ行動が必要と判断した場合、範囲、予想期間、承認根拠を記録すべきです。

影響の大きい不利な行為には職務分離が必要です。疑わしい妥協を調査する人物は、単独で失効を承認し、レビュー記録を管理すべきではありません。2名または委員会の承認はエラーを減らすことができ、緊急ルールは即時の一時的な行動を許可し、その後迅速な独立確認を行うことができます。標準は、どのイベントがその例外を正当化するか、確認がどのくらい迅速に行われるべきかを特定すべきです。

通知は重要ですが、絶対ではありません。事前通知は、計画された満了、リソース変更、緊急でないコンプライアンス問題に適切です。確認された鍵妥協への対応前には安全でない場合があります。その場合でも、明確に害を悪化させない限り、同時通知は独立したチャネルを通じて行われるべきです。技術スタッフが証明書管理を内部的なものと見なすという理由だけで、沈黙がデフォルトになってはなりません。

レビューには技術的能力と迅速な行動能力が必要です。数週間後に会合する一般的な会員上訴は、進行中のルーティングセキュリティ問題には不十分です。レジストリ事業者は、リソース権限、証明書状態、リポジトリ証拠、運用影響を調査できる独立したパネルを維持すべきです。復元、交換、修正、またはより広範な紛争が続く間の一時的な継続を命じることができるべきです。

救済手段は、証明とリソース権利の区別を維持すべきです。不適切な証明書失効を修正することは、すべての契約上の請求を決定するわけではありません。逆に、保持者は下位鍵を使用して、統治規則の下で認識された正当な移転またはリソース変更を無効にすることはできません。証明書サービスは権威あるリソース状態を反映すべきであり、その状態に関する紛争は、継続保護を伴う適切な権利手続きを通じて決定されるべきです。

透明性は、悪用可能な詳細を公開せずに悪用を抑止できます。レジストリ事業者は、緊急失効、遅延発行、争われたリソース削減、リポジトリ中断、レビュー結果の件数とクラスを報告すべきです。重要なインシデントは、即時リスクが過ぎた後に公開説明を受けるべきです。機密性の高い認証証拠は保護されたままにできます。会員は、例外的な権限が稀で、正当化され、誤りの場合に修正されているかどうかを判断するのに十分な情報を必要とします。

鍵のライフサイクル義務は具体的でテスト可能であるべき

制御は、ライフサイクル全体にわたって維持され、登録時に一度確立されるわけではありません。鍵生成は、承認されたアルゴリズムと安全なランダム性を使用すべきです。証明書リクエストは、鍵を認証された保持者に結び付けるべきです。有効化は、公開と独立した検証を確認すべきです。日常的な運用は、時間依存の製品を更新し、リポジトリを監視し、管理者権限を制限すべきです。ロールオーバーは、弱体化やデバイス障害が緊急性を生み出す前に鍵を交換すべきです。引退は、権限を失効または失効させ、時代遅れの秘密を安全に廃棄すべきです。

アルゴリズムアジリティはこの義務の一部です。RFC 6916は、RPKI のアルゴリズムアジリティ手順を説明しており、暗号アルゴリズムを時間の経過とともに変更する必要性を反映しています。レジストリ事業者は、そのような変更を1つのベンダーのハードウェアスケジュールに依存させる管理モデルを避けるべきです。資格は、サービスがサポートされるアルゴリズムを導入し、必要なオーバーラップを実行し、依拠当事者の期待を更新し、ユーザーに制御を放棄させることなく古いマテリアルを廃棄できるかどうかをテストすべきです。

定期的なロールオーバーは、復旧が機能する最良の証拠です。新しい鍵を生成し、証明書を取得し、一貫した状態を公開し、依拠当事者の収束を観測できる保持者は、同時にいくつかの重要な権利を実証しています。レジストリ事業者は、ロールオーバー間隔またはリスクベースの期待値を設定しつつ、不必要なチャーンを避けるべきです。演習は、完了した移行とポータルのステータスメッセージを区別するのに十分に文書化されるべきです。

認証コンテンツもガバナンスを必要とします。ユーザー管理は、無制限または不注意な発行を意味すべきではありません。インターフェースは、リソース範囲、プレフィックス長、起点 ID、有効期限を検証すべきです。リスクの高い変更は、保持者自身の承認ポリシー内で追加のレビューを受けることができます。ツールは、認証を削除または狭めることの推定される影響を示し、競合する現在のオブジェクトについて警告すべきです。保持者が決定を制御しますが、適切な設計は回避可能なミスを減らします。

短い有効期間はエクスポージャーを制限できますが、信頼できる更新と公開への依存度を高めます。長い有効期間は更新の圧力を減らしますが、時代遅れの権限を有効に保つ可能性があります。レジストリ事業者はバランスの取れたプロファイルを設定し、トレードオフを可視化すべきです。緊急手順は、すべての依拠当事者が即座にリフレッシュすることに依存すべきではありません。テストには、現実的なポーリング、キャッシュ、障害動作を持つバリデータを含めるべきです。

管理者のライフサイクルは、暗号ライフサイクルと同様の厳格さに値します。退任するスタッフは速やかにアクセスを失うべきです。復旧連絡先は再確認されるべきです。特権操作は強力な認証と独立した通知を使用すべきです。共有アカウントは、影響の大きい操作には禁止されるべきです。技術的に安全な HSM は、古い従業員が放置されたポータルを通じてその使用を承認できる場合、権限を保護しません。

サポートされた委任は、権利を奪うことなく小規模事業者にサービスを提供できる

ユーザー保持鍵に対する最も強い実際的な反論は、能力の不平等です。大規模ネットワークはセキュリティエンジニアを雇用し、冗長ハードウェアを運用できます。小規模保持者は1人のネットワーク管理者と証明書管理への関心がほとんどない場合があります。委任が最大の会員だけのために設計されている場合、ホスト型制御が支配的になり、権利は形式的で広く使用可能ではありません。

レジストリ事業者は、サポートされた委任サービスカテゴリを確立すべきです。プロバイダは、設定済みハードウェア、管理されたセレモニー、監視された公開、更新アラート、インシデントサポート、定期演習を提供できます。ユーザーは、セキュリティアカウントの所有権または決定的な制御を保持し、承認ポリシーを設定し、新しいプロバイダを任命する能力を持ちます。プロバイダは、証明関係を失うことなく終了できる文書化された権限の下で運用します。

コストは透明で比較可能であるべきです。基本的な委任運用に特注の法的交渉を必要とすべきではありません。標準的なサービス記述は、誰が HSM アカウントを管理するか、誰が署名を開始できるか、誰が高リスク操作を承認するか、記録がどのようにエクスポートされるか、公開がどのように移動するか、復旧がどのように機能するかを述べることができます。顧客は、価格と稼働時間だけでなく、権限と出口について2つのプロバイダを比較できるべきです。

共有インフラはそれでも分離を維持できます。プロバイダは、各顧客の鍵と承認が分離され、特権アクセスが管理され、1人の顧客が他の顧客に影響を与えない場合、認定ハードウェア上で多くの論理セキュリティドメインをホストできます。独立した評価は技術的な分離と運用慣行をテストすべきです。レジストリ事業者は、共有ハードウェアが本質的に受け入れられないか、本質的に安全であるふりをすべきではありません。

トレーニングは、すべての保持者を暗号技術者に変えるのではなく、決定に焦点を当てるべきです。管理者は、ルート認証が何をするか、鍵妥協がアカウント喪失とどう異なるか、いつロールオーバーをリクエストするか、公開を確認する方法、誰に連絡するかを理解する必要があります。演習は、組織的権限が最新であるかどうかを明らかにできます。簡潔でよく練習された手順は、誰も使用したことのない長いマニュアルよりも価値があります。

補助金は、コストが集中管理を強制する場合、小規模または公共利益ネットワークに対して正当化されるかもしれません。資金はユーザーに従い、複数の資格のあるプロバイダで使用可能であるべきです。レジストリ事業者が運営する単一のホストに価格優位性を与えることは、レジストリ事業者が作り出そうとしている市場を損なうでしょう。サポートは選択肢を広げるべきであり、財政的支援を技術的依存に変えるべきではありません。

ホスト型サービス自体も、ロックイン防止基準を満たすべきです。ユーザーは、すべてのアクティブな認証を確認し、独立した通知を受け取り、履歴をエクスポートし、復旧連絡先を指定し、委任への移行を練習できるべきです。サービスは、署名を実行するという理由だけで、レジストリ事業者を鍵権限の所有者として説明すべきではありません。ホスト型運用は、明示的な制限内で認識された保持者のために行われる、受託者的な技術的役割です。

監査は実効制御と依拠当事者の結果を検討すべき

鍵が存在し、リポジトリがリクエストに応答するかどうかだけをチェックする監査は、ガバナンスの質問を見逃します。レビュー担当者は、誰が新しい署名オブジェクトを出現させることができるか、誰がそれを防ぐことができるか、誰が鍵を交換できるか、誰が公開を移動できるか、誰がロックアウト後に復旧できるか、誰が証明書を失効できるかを追跡すべきです。文書化された権限と実際の資格情報、承認、観察された行動を比較すべきです。

テストは制御された行動を使用すべきです。監査人は、日常的なオブジェクト変更をリクエストし、承認証拠を検査し、結果の公開を独立して取得し、収束を測定できます。ロールオーバーを開始し、有効化前に一時停止し、ロールバックが機能することを確認できます。完全なエクスポートをリクエストし、テスト環境でプロバイダ移行を試行できます。利用不可能な管理者をシミュレートし、しきい値復旧が単一の請求者を拒否することを確認できます。

リポジトリ評価には、一貫性のないビュー、古いデルタ状態、完全スナップショットフォールバック、有効期限圧力、サービス拒否を含めるべきです。依拠当事者は多様であるため、テストは可能であれば複数のバリデータ実装とネットワーク位置を観測すべきです。目的は、同一のリフレッシュ時間を保証することではありません。アクションが、隠れた乖離ではなく、境界のある説明可能な収束を生み出すかどうかを検出することです。

親の行動も監査可能であるべきです。レビュー担当者は、証明書リクエスト、拒否理由、緊急行動、リソース変更、復元時間をサンプリングすべきです。レジストリ事業者のホスト型サービスのユーザーと外部プロバイダのユーザーとの間の差別的扱いを探すべきです。自身の顧客をより速く処理する親は、必要な階層的役割を反競争的優位性に変える可能性があります。

インシデント記録は原因と結果を結び付けるべきです。認証が消えた場合、記録はユーザーの指示、鍵妥協、親の行動、リポジトリ障害、有効期限、バリデータ遅延を区別すべきです。各原因は異なる救済手段を必要とします。集計レポートは、プライベートなセキュリティ詳細を公開せずにシステムの脆弱性を示すことができます。

メトリクスは虚栄心に抵抗すべきです。エクスポートが不完全であったり、移行に数ヶ月かかる場合、稼働時間だけではほとんど意味がありません。レジストリ事業者は、成功した委任登録、親応答時間の中央値、完了したロールオーバー、失敗した復旧、移行期間、検証ギャップの分数、無許可署名インシデント、レビューで覆された不利な行為、プロバイダ集中度などの測定値を公開すべきです。傾向と分布は、1つの好ましい平均よりも重要です。

3つの失敗ケースが権利が現実かどうかを明らかにする

最初に、レジストリ事業者がホストする CA を使用する中規模アクセスプロバイダを考えます。セキュリティスタッフを雇った後、委任モデルに移行することを決定します。権利ベースの設計の下では、自身の HSM で鍵を生成し、証明書リクエストを認証し、独立したリポジトリで公開を確立し、移行をリハーサルします。古い状態と新しい状態は安全にオーバーラップし、モニターは収束を観測し、ホスト型資格情報は閉じられ、プロバイダは完全な履歴を保持します。顧客が離脱するのに十分に説得力のある理由があるかどうかを、当局が判断する必要はありません。

次に、1つの事実を変更します。ホスト型サービスが有用な状態のエクスポートを拒否し、移行は年間メンテナンス期間中にのみ可能であると述べます。顧客は依然としてリソース登録を保持しているかもしれませんが、実用的な証明書の自由は欠けています。独立したレジストリレビューは、エクスポートを要求し、調整された日付を設定し、継続を監督できるべきです。レジストリ事業者自身がホストを運用している場合、決定は独立した機関に移行しなければなりません。制度的正当性は、自身のインフラのレビューを受け入れることに依存します。

2つ目のケースは、洪水後に HSM が故障した委任 CA です。現在の認証は、限られた期間公開され有効です。保持者は、しきい値復旧グループを有効化し、セカンダリサイトで新しい鍵を作成し、親に代替証明書を要求します。独立したモニターは、意図された状態と公開を比較します。妥協の証拠がないため、古い権限と新しい権限は制御されたロールオーバーを通じてオーバーラップできます。復旧は、誰も故障した鍵のエスクローコピーを取得することなく成功します。

証拠が洪水前に無許可署名を示している場合、対応は変わります。古い証明書とすべての最近のオブジェクトはレビューを必要とします。親は緊急失効措置を必要とし、一時的な継続は以前の状態よりも狭くなる可能性があります。ユーザーは事前に確立された復旧権限を通じて引き続き参加しますが、スピードと封じ込めがすべての既存の認証を保存することよりも優先されます。イベントは後に独立したレビューを受けます。

3つ目のケースは、リソース保持者とリポジトリプロバイダとの間の紛争です。プロバイダは未払いの請求書を主張し、すぐに公開を停止すると脅しています。通常の商業債権者は支払いを追求できますが、ルートセキュリティ公開の管理を無関係なネットワークへのてことして使用すべきではありません。資格条件は、継続期間、エクスポート、移行協力、紛争分離を要求すべきです。レジストリ事業者は、金融請求が適切な場で続く間、ユーザーが公開を移行することを許可できます。

保持者が会員費をめぐってレジストリ事業者とも紛争していると仮定します。同じ分離が適用されるべきです。必須の証明と公開の継続は、非公式の回収装置として撤回されるべきではありません。統治規則が別個の理由でリソース行動を許可する場合、その行動は独自の証拠、通知、レビューに従わなければなりません。請求のレバレッジと親権限を組み合わせることは、まさにユーザー制御鍵が制限しようとしている制度的支配を再現することになります。

これらのケースは、管理、移植性、復旧、レビューがなぜ一緒に属するかを示しています。ユーザーの建物内の秘密鍵は、リポジトリの強制を解決しません。ポータブルな公開は親の失効を解決しません。真正な組織的権限なしの緊急復旧は、詐称者に制御を渡す可能性があります。各保護は異なる失敗に対処し、束は移行がエンドツーエンドで練習された場合にのみ機能します。

プロバイダの多様性は、ラベルを増やすのではなく、相関する制御を減らさなければならない

レジストリ事業者は、サービスディレクトリにリストされた企業の数から回復力を推測すべきではありません。複数のブランドが、同じ HSM 事業者、クラウドアカウント、リポジトリプラットフォーム、証明書ソフトウェアチーム、インシデント請負業者に依存する場合があります。共有層での障害は、その後、見かけ上独立したユーザーに影響を与える可能性があります。プロバイダの資格は、レジストリ事業者に重要な依存関係を開示し、集中度を会員に集計して可視化させるべきです。

依存関係マッピングは、インフラだけでなく制御もカバーすべきです。2つのリポジトリサービスが異なるデータセンターで稼働していても、特権変更のために1つの管理者グループに依存する場合があります。委任 CA ベンダーは、すべての顧客の復旧権限を1つのサポートデスクに置く場合があります。監視会社は、監視されるべきサービスからのみ期待される状態を取得する場合があります。これらの取り決めは、機器が分離されている場合でも、相関する判断を生み出します。

レジストリ事業者は、各目的に対して独立性を定義すべきです。2つ目の公開エンドポイントは、最初のプロバイダが利用不可能な場合に操作できる場合にのみ、インフラの多様性を提供します。復旧管理者は、通常の事業者によって指示されない場合にのみ、組織的多様性を提供します。外部モニターは、独立して状態を取得し検証する場合にのみ、証拠の多様性を提供します。1つの組織が依然として優れたサービスを提供できるかもしれませんが、2つの製品名を使用するという理由だけで2回カウントされるべきではありません。

会員は、意図的に選択するのに十分な開示を必要とします。プロバイダの説明は、重要な下請け機能、サービス継続に関連する法域、変更管理権限、復旧依存関係、移植条件、最近の演習結果を特定すべきです。機密性の高いセキュリティ詳細は保護されたままにできます。公開目的は、集中度と出口リスクを明らかにすることで、攻撃ガイドを公開することではありません。

レジストリ事業者自身は、隠れた共通依存関係になることを避けるべきです。必然的に親機能を操作または承認し、初期段階で参照サービスを実行するかもしれません。それによって、そのポータルが唯一の認証チャネル、そのリポジトリが唯一のサポートされる公開場所、そのサポートチームが唯一の復旧権限になることは正当化されません。参照サービスは相互運用性を確立し、参加コストを下げる一方で、独立した運用の余地を残すべきです。

調達はこの分離を強化できます。レジストリ事業者の契約は、オープンインターフェースを使用し、設定と証拠のエクスポートを要求し、運用記録の顧客所有権を保護し、別のプロバイダによる移行支援を許可すべきです。他の場所で再現できないカスタム機能は精査を受けるべきです。最も安い短期オファーは、組織が重要な事業者を交換できなくする場合、コストが高くなる可能性があります。

集中度制限は、恣意的な市場シェアではなく、結果に焦点を当てるべきです。1つのプロバイダがほとんどのユーザーにサービスを提供している場合でも、すべての顧客がテストされた間隔で移行できる場合、リスクは、ユーザーが離脱できない小規模プロバイダよりも低くなります。レジストリ事業者は、シェアデータと移植時間、共通依存関係、復旧パフォーマンス、特権アクセスの範囲を組み合わせるべきです。上昇する集中度指標は、追加の演習、代替プロバイダとの予備能力、自動禁止ではなく、より綿密なレビューを引き起こす可能性があります。

出口能力は、支配的なサービスが失敗する前に存在しなければなりません。代替プロバイダは、波状に顧客を受け入れるテスト済みの能力を維持すべきです。レジストリ事業者は、複数の架空のアカウントが同時に移動する容量演習を調整し、認証キュー、リポジトリ負荷、サポートスタッフ、依拠当事者への影響を測定できます。1人の静かな顧客に対して証明された移行手順は、一般的な停止後に数百人がそれを必要とする場合に失敗する可能性があります。

レジストリ事業者は、プロバイダの買収にも計画すべきです。合併により、契約が変わらなくても、鍵、スタッフ、リポジトリ、顧客記録が1つの管理者の下に結合される可能性があります。資格のあるプロバイダは、重要な管理変更をレジストリ事業者に通知し、分離への影響を説明し、集中度や法域が大幅に変更された場合に罰則なしの移行期間を提供すべきです。顧客は、自分たちが意図的に避けていた機関の一部になったことを、完了後に知るべきではありません。

競争はそれ自体が目的ではありません。目的は、ストレス下での信頼できる選択肢です。複数のプロバイダが重要なのは、ユーザーが貧弱なサービスから逃れ、相関する障害を減らし、制度的仮定に挑戦できるからです。ユーザーが移動できず、すべてのプロバイダが1つの管理センターに依存し、親が関連ホストを優遇する場合、市場の外観はセキュリティをほとんど追加しません。多様性は、権限、インフラ、証拠が実際に分離できる場合にのみ価値があります。

レジストリ事業者は、測定可能な受入テストを伴う証明書権利憲章を採択すべき

レジストリ事業者は、簡潔な統治憲章で証明書権利を述べ、技術要件、プロバイダ条件、レビューを通じてそれらを実施すべきです。憲章は、保持者がホスト型または委任運用を選択する権利、通常の署名を管理する権利、資格のあるプロバイダを任命する権利、適時の親サービスを受ける権利、公開を移動する権利、証拠を検査する権利、鍵を交換する権利、権限を回復する権利、不利な行動に異議を唱える権利を認識すべきです。また、資格情報を保護する、連絡先を維持する、認証範囲内で発行する、状態を監視する、インシデント対応に協力するという保持者の義務も述べるべきです。

各権利には受入テストが必要です。委任は、独立した鍵生成と成功した証明によって証明されます。制御は、レジストリ事業者が単独で実行できない承認行動によって証明されます。移植性は、境界のある検証効果を伴う移行によって証明されます。復旧は、シミュレートされた喪失後の交換によって証明されます。親の説明責任は、理由のある決定、測定された応答、効果的なレビューによって証明されます。プロバイダ競争は、ベンダーのリストではなく、実際の顧客の移動によって証明されます。

レジストリ事業者は、遅延を永続させることなくモデルを段階的に導入すべきです。参照委任サービス、2つの独立した公開プロバイダ、公開されたインターフェース、監督された移行から始めることができます。初期ユーザーには、さまざまな地域の大小の保持者を含めるべきです。発見事項は、規模が拡大する前に要件を変更すべきです。ホスト型ユーザーは、移行権とエクスポートが完全に利用可能になる明確な日付を受け取るべきです。

レジストリ事業者は、自身の都合に対して懐疑的であり続けるべきです。集中ホスティングは、特に立ち上げ時には効率的かもしれません。効率性は利益であり、憲法上の議論ではありません。機関がルールを書き、親を制御し、ほとんどの秘密鍵を保持し、支配的なリポジトリを実行し、紛争を判断する場合、運用上の容易さはガバナンス権力に積み上がっています。善意は紛争を取り除きません。

分散化もロマンチック化されるべきではありません。不十分に保護された鍵、放棄されたリポジトリ、訓練されていない管理者は、ルーティングセキュリティを弱める可能性があります。レジストリ事業者は、能力、監視、復旧を要求する権利があります。制約は、セキュリティルールが比例的で、プロバイダに中立であり、修正可能でなければならないことです。それらは、すべての逸脱を集中管理の理由にするのではなく、委任運用の質を高めるべきです。

最終テストは実用的です。リソース保持者は、証拠をもって5つの質問に答えられるべきです。誰が今署名できるか？誰がその権限を防止または失効できるか？現在の状態はどこで公開されているか？サービスはどのように移動できるか？喪失または妥協後、安全な制御はどのように回復されるか？5つすべての答えが1つの機関である場合、それを説明するために使用される言語にかかわらず、システムはホスト型 CA の力を再現しています。

したがって、ユーザー制御鍵は、装飾的な分散化機能ではありません。それらは、より広範な権利配分の一部です。ポータブルな公開はリポジトリ依存を防ぎます。緊急復旧は自己管理を存続可能にします。親の制約は残りの階層を認識します。独立した監視とレビューは制度的行動を可視化します。サポートされた委任は、これらの保護を小規模事業者の手の届く範囲にします。

レジストリ事業者は、会員にリソース依存を証明書依存と交換するよう求めることなく、ルートセキュリティを強化できます。その任務は、一貫した信頼階層を提供しながら、その下のすべての機能を独占することを拒否することです。規律ある立場は、中央制御でもサポートなしのセルフサービスでもありません。それは、相互運用可能なサービス、テストされた継続、狭くてレビュー可能な制度的権限によって支えられたユーザー権限です。

NRS および BTW の役割に関する情報源