要約
- NRS のデフォルトは、リソース保有者が秘密鍵を生成または生成を許可し、署名権限を制御し、資格のある運用サポートを選択できる委任 CA とすべきである。ホスト型署名はオプションであり、実質的な参加の条件ではない。
- 鍵の保管は証明書の自由の一部に過ぎない。保有者はまた、タイムリーな親証明書サービス、使用可能な公開インターフェース、エクスポート可能な署名状態、独立した監視、およびルーティングセキュリティのカバレッジを失うことなくプロバイダを変更する文書化された権利を必要とする。
- ポータブルな公開は、通常のサービス移行としてテストされるべきである。重複、リポジトリの同期、マニフェスト、失効情報、依拠当事者の可視性、ロールバックには、移行中に検証ギャップが生じないように測定された受け入れ基準が必要である。
- 緊急復旧は日常的な鍵のエスクローに依存すべきではない。オフラインの復旧資格情報、マルチパーティ認証、事前に合意された鍵交換手順、および範囲を限定した継続措置により、通常の署名は保有者に残しつつ、制御を復元できる。
- ユーザ制御の下位鍵は親 CA を無効化しない。NRS ルールは、遅延発行、選択的失効、リポジトリ妨害、説明のないリソース削減などの不利な行為を、通知、証拠、迅速なレビュー、救済策を通じて制限しなければならない。
- 小規模事業者には支援付き委任が必要である：管理されたハードウェア、セレモニー、ヘルスチェック、トレーニング、ユーザのセキュリティドメインでの契約運用。重要な違いは、誰が権限と退出を制御するかであり、誰が物理的に各コマンドを入力するかではない。
- 設計は観察可能な演習で判断されるべきである：独立した鍵生成、定期的なロールオーバー、公開プロバイダの移行、侵害復旧、親との紛争、依拠当事者の収束。これらのテストに耐えられない権利は、記述的な約束であり、運用上の権利ではない。
RPKI の権限は、一つのサービスが統一的に見せかけても分割されている
Resource Public Key Infrastructure（RPKI）は、多くの場合、運用者に対してホスト型サービスを利用するか、委任 CA を運用するかという単純な製品選択として提示される。この説明は有用ではあるが不完全である。いくつかの権限がその下に存在する。親 CA は子のリソース保持を証明する。子は秘密鍵を制御し、署名製品を発行する。リポジトリは証明書、失効情報、マニフェスト、ルート発信元オブジェクトを利用可能にする。依拠当事者はそれらの製品を取得して検証する。運用ポータルは要求を認証し、顧客に代わって署名を実行することがある。
一つの機関がこれらすべての機能を実行すると、ユーザの体験はスムーズになり得る。また、権力がどこにあるのかを曖昧にすることもある。ユーザは発信元を承認するためにクリックする一方で、サービスが関連する秘密鍵を生成して保持するかもしれない。同じ機関が、要求の認証方法、オブジェクトの公開時期、アカウントの復旧方法、エクスポートの可能性を決定することもできる。顧客はサービス関係を持っているが、必ずしも独立して使用可能な証明機能を持っているわけではない。
この区別が重要なのは、ルーティングセキュリティの権限が実際の接続性を形成し得るからである。ルート発信元認証はそれだけではルータに命令しない。依拠ネットワークが検証済み状態をどのように使用するかを決定する。しかし、広範な検証は署名済み状態に実質的な結果を与える。誤った撤回、古い公開、過度に広い認証、侵害された鍵は、経路がどのように分類されるかに影響を与える可能性がある。したがって、通常の署名と復旧を集中させることは、正式なリソース登録が変わらなくても、ガバナンス上の依存関係を生み出す。
関連する標準は、すべての機能を一つの運用者に制御させることを要求していない。RFC 6480で説明される RPKI アーキテクチャは、インターネット番号リソースに関連する階層を確立する。RFC 6487の証明書プロファイルは、リソース証明書が権限を表現する方法を制約する。署名オブジェクトとリポジトリの標準は、製品を利用可能にして検証する方法を定義する。証明書登録と公開プロトコルは、組織境界を越えた相互作用をサポートする。このモジュール性は単なるエンジニアリング上の便宜ではない。それは制度的な選択の余地を提供する。
NRS はその余地を意図的に利用すべきである。リソース認識、親による証明、子による署名、リポジトリ運用、依拠当事者による検証は、ポリシー、契約、監査、インシデント対応において区別されたままであるべきです。プロバイダは複数の機能を提供することができるが、それらを組み合わせることで、後でユーザがそれらを分離する権利を消し去るべきではない。ある機関は、それが行使する各権力を正当化する必要があり、顧客が便利なインターフェースを好むからといって広範な権限を継承するべきではない。
自己満足に対する最も強い警告は階層そのものから来る。自身の秘密鍵を制御する子であっても主権者ではない。親は証明書の再発行を拒否し、ポリシーが許せば認定リソースを削減し、証明書を取り消し、タイムリーなロールオーバーをサポートしない可能性がある。リポジトリ運用者は公開を遅らせたり、誤って処理したりすることがある。依拠当事者は、リフレッシュと有効期限のルールが解決するまで古い素材を保持することができる。したがって、目標は鍵の保持が依存性を排除するというロマンチックな主張ではない。それは依存性の憲法的な配分である：各行為者は必要な最小限の権力を受け取り、各権力には証拠、時間制限、レビューがある。
ユーザ保持の鍵は通常の推定であるべき
デフォルトの取り決めは、リソース保持者が制御するセキュリティ境界内での鍵生成から始めるべきである。その境界は、保持者の施設内のハードウェアセキュリティモジュール、保持者のアカウント内の専用クラウドセキュリティサービス、オフラインデバイス、または契約に基づいて運用される管理されたアプライアンスである可能性がある。正確な機器はリスクと規模を反映すべきである。重要なのは、保持者が使用を許可し、プロバイダを交換し、鍵操作の証拠を取得し、Society が一方的に通常の署名権限を行使することを防ぐことができることである。
鍵を生成するだけでは不十分である。制御とは、保持者が誰がそれを活性化できるか、どの承認ルールの下で、どの署名製品に対して、どの監査記録とともに、どの期間に決定できることを意味する。大規模なアドレス保持者には二人組ルールが適切かもしれない。小規模な運用者は、一人の責任ある管理者と独立した復旧連絡先を使用するかもしれない。広範なルート認証や侵害が疑われる後の交換などの高リスク行動は、定期的な更新よりも強い承認を必要とする。
NRS は、高価なアプライアンスを一つ指定することなく、委任された保管のためのベースラインを公表すべきである。ベースラインは、エントロピー、サポートされるアルゴリズム、安全なバックアップ、アクセスログ、職務分離、失効準備、時刻同期、管理者変更、保護された復旧素材、廃棄に対処すべきである。必須のセキュリティ成果とオプションの実装パターンを区別すべきである。運用者は、好みのベンダーから購入することなく、必要な制御を証明できるべきである。
ユーザ保管の推定は、運用が外部委託される場合にも適用されるべきである。管理セキュリティ会社が HSM を管理し、署名をスケジュールし、公開を監視することができる。ユーザがアカウント、承認ポリシー、交換権限を制御している場合、これは委任された運用のままである。逆に、「顧客管理」とラベル付けされたデバイスは、プロバイダのみが設定をエクスポートし、新しい管理者を承認し、公開を切り替えることができる場合、独立性をほとんど提供しない。ガバナンスは、マーケティングの説明ではなく、実効的な権限を検討すべきである。
一部の組織はホスト型署名を選択する。スタッフが不足しているか、小さなリソースセットのみを運用しているか、シンプルなサービスを重視しているかもしれない。NRS は強い認証、可視的な承認、測定されたサービス品質でその選択を支援すべきである。しかし、ホスト型ユーザは明確なアップグレードパスを受けるべきである。自身の鍵を確立し、必要な下位証明書関係を取得し、公開を移動し、依拠当事者の可視性を確認し、罰則的な料金や裁量的な遅延なしにホスト型署名を閉鎖できるべきである。
デフォルトルールは市場を形成する。委任操作が例外的な承認、長い交渉、または専門的な個人的接触を必要とする場合、ポリシーがオプションと呼んでも、ホスト型制御が実質的な標準になる。NRS はその負担を逆転させるべきである。準拠した委任要求は日常的であるべきである。拒否は、特定のセキュリティまたは承認の欠陥を特定し、その修正方法を示し、迅速な独立したレビューを許可すべきである。Society は技術的要件を強制することができる；それらの要件を自身のサービスシェアを保護するために使用すべきではない。
同じ原則が鍵の証拠にも適用される。ユーザは鍵の作成、証明書要求、証明書発行、オブジェクト署名、失効、ロールオーバーの検証可能な記録を受け取るべきである。これらの記録は、秘密鍵を公開することなく、監査や紛争の際に有用であるべきである。プロバイダがセレモニーを実行する場合、ユーザは何が起こったかを示すのに十分な証明とログを受け取るべきである。証拠はサービスが変更されたときに顧客とともに移動すべきである。
証明書の権利は束であり、単一の保管請求ではない
鍵が「ユーザ制御」と呼ばれることは、関連する権利が指定されない限りスローガンになる可能性がある。最初の権利は生成または独立して承認された生成である。二番目は排他的な通常の使用である：NRS もプロバイダも、インフラを運用しているという理由だけで新しい署名製品を作成できるべきではない。三番目は信頼できる記録を通じた検査である。四番目は通常のロールオーバーと緊急侵害手順を通じた交換である。五番目はプロバイダ間の移動である。六番目は古い権限の安全な引退による終了である。
束にはタイムリーな親サービスが含まれなければならない。親が証明書要求を無視したり、変更を遅らせたり、正当な交換鍵を拒否したりする場合、子は無期限に有効な証明を維持できない。NRS は、定期的な発行、計画的なロールオーバー、リソース変更、緊急侵害のためのサービス目標を設定すべきである。時間は完全な認証要求から測定されるべきである。要求に欠陥がある場合、応答は欠陥を特定し、不透明なキューを再開しないようにすべきである。
また、公開へのアクセスも含まれなければならない。正しく署名するが、製品を確実に利用可能にできない子 CA は、有用な独立性を持たない。保持者は、資格のあるリポジトリプロバイダの中から選択し、適切な場合には自身の準拠リポジトリを運用し、完全な現在のインベントリを取得できるべきである。リポジトリ条件は、無関係の会員紛争や商業サービスに継続的な公開を条件付けるべきではない。
データポータビリティは別の権利である。保持者は、公開証明書、署名オブジェクト、マニフェスト、失効製品、リポジトリパス、関連するタイミング情報、設定、監査履歴を文書化された形式でエクスポートできるべきである。秘密鍵は、特にハードウェアにおいて、設計上エクスポート不可能かもしれないが、それがユーザを閉じ込めるべきではない。交換鍵と調整された移行が可能でなければならない。非エクスポート可能性は鍵を保護できる；証明関係の非ポータビリティを正当化できない。
束には独立した観察が含まれる。ユーザは行動を実行した同じダッシュボードを信頼する必要はない。外部のモニターは、依拠当事者が行うようにリポジトリを取得し、リソースチェーンを検証し、期待される製品と観測された製品を比較し、消失、不一致、予期しない発信元変更、期限切れ接近について警告すべきである。NRS は、保持者と第三者モニターが悪意のある変更を迅速に検出できるように、標準化されたフィードまたは通知をサポートすべきである。
最後に、証明書の権利には救済策が必要である。サービスが遅延または妨害されたユーザは、ルーティングの結果を理解する迅速なチャネルを持つべきである。レビューは、公開の復元、一時的な継続措置、修正された発行、または保存された状態を命じることができるべきである。金銭的補償は後で重要になるかもしれないが、迅速な技術的修正に代わるものではない。関連する証明書が期限切れになった後にのみ救済される権利は、効果的な権利ではない。
（以降のセクションも同様に翻訳されているが、以下省略）