RFC 9632: ジオフィード・データの見つけ方と利用方法
要旨
本文書では、ルーティング・ポリシー仕様言語(RPSL)のinetnum:クラスを拡張し、ジオフィードのコンマ区切り値(CSV)データ・ファイルを参照する方法を規定し、リソース公開鍵基盤(RPKI)を使用してジオフィード・データ・ファイルを認可するオプションのスキームについて説明する。この文書により、RFC 9092を廃止する。
本文書の位置付け
本文書は、インターネット標準化過程の文書である。
この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション2を参照のこと。
本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、<https://www.rfc-editor.org/info/rfc9632>で入手できる。
著作権に関する通知
Copyright (c) 2024 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
インターネット・コンテンツや他のサービスのプロバイダは、サービスを利用するユーザの地理的位置に基づいて、サービスをカスタマイズしたい場合がある。これは、サービスとの接続に利用される送信元IPアドレスを用いて行われることが多いが、このIPアドレスはユーザを指し示さない場合がある。特に[RFC6269]のセクション14を参照のこと。また、インフラや他のサービスの管理者は、そのインフラやサービスのロケールを公開したい場合がある。[RFC8805]は地理的なロケールをIPアドレスに関連付ける構文であるジオフィードを定義しているが、IPアドレスから関連するジオフィード・データを検索する方法は規定されていない。
本文書では、ルーティング・ポリシー仕様言語(RPSL)[RFC2725]のinetnum:クラスを拡張して、ジオフィード・データ・ファイルを参照する方法と、それらを慎重に利用する方法について説明する。inetnum:が使用されるすべての場所では、inet6num:も想定する必要がある[RFC4012]。
読者は、[INETNUM]と[INET6NUM]がinetnum:データベース・クラスの説明が有益だが、冗長であると感じるかも知れない。
セクション5ではジオフィード・データを認証するためのオプションの非常に素晴らしいが少し複雑な手段も定義している。
本文書は[RFC9092]を廃止する。[RFC9092]からの変更点は以下のとおりである:
- RIPEは
geofeed:属性を実装している。 - 本文書では、
inetnum:がジオフィードremarks:属性とgeofeed:属性の両方を持つことを許可しているが、推奨はしない。 - 認証セクション(セクション5)は、より正式なものになるように書き直された。
- ジオフィード・ファイルはUTF-8 CSVのみである。
- 本文書では、ジオフィード・データの認証はオプションであることを強調している。
- IPアドレス委任拡張機能では「inherit」(継承)を使用してはならない。
- ジオフィード・データが存在する場合、他のデータの地理的位置のヒントは無視する必要がある。
1.1. 要件言語
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
2. ジオフィード・ファイル
ジオフィード・ファイルは[RFC8805]で説明されている。これは、IPアドレス・リソースの「保有者」がIPアドレスを地理的なロケールに関連付けるための機能を提供する。
[RFC8805]によると、ジオフィード・ファイルは、HTML、リッチテキスト、または他の形式ではなく、UTF-8テキスト形式のカンマ区切り値(CSV)で構成する。
IPアドレスから地理的なロケールを特定したいコンテンツ・プロバイダや、他の関係者は、関連するジオフィード・データを見つける必要がある。本文書のセクション3では、IPアドレスを指定して関連するジオフィード[RFC8805]ファイルを見つける方法を規定する。
大規模プロバイダのジオフィード・データは、水平方向のスケールが大きく、粒度が細かいため、かなり大きくなる可能性がある。署名されていないジオフィード・ファイルが数多くのプレフィックスのデータを結合している場合や、IPv4/IPv6のデュアル空間が表現されている場合など、ファイルのサイズはさらに大きくなる可能性がある。
ジオフィード・データにはプライバシーに関する考慮事項がある(セクション7を参照)。このプロセスにより、これらのデータへの大量アクセスが容易になる。
本文書はまた、ジオフィード・ファイルのデータを強力に認証するために、オプションの署名も提案している。
3. inetnum:クラス
[RIPE81]、[RIPE181]に始まるオリジナルのRPSL仕様と、その後の一連の文書は、RIPEコミュニティが作成した。IETFは[RFC2622]と[RFC4012]でRPSLを標準化した。それ以来、地域インターネット・レジストリ(RIR)コミュニティで、主にRIPE[RIPE-DB]が修正し、大幅に拡張してきた。本文書の発行時点で、RPSLの変更管理は事実上、オペレータ・コミュニティが担っている。
inetnum:データベース・クラスは、RPSLのほか、地域インターネット・レジストリ(RIR)で使われているルーティング・ポリシー・システム・セキュリティ[RFC2725]とRPSLng[RFC4012]によって指定される。これらのオブジェクトは、IPアドレスの範囲とその属性を記述する。inetnum:オブジェクトは、アドレス空間に基づいて順序付けられた階層を形成する。
理想的には、RPSLを拡張して、inetnum:クラスに新しいRPSLのgeofeed:属性を定義する。特定のRIRデータベースにgeofeed:属性が実装されていない場合、本文書は、ジオフィード・ファイルのHTTPS URLを含むジオフィードのremarks:属性の構文を定義する。inetnum:のジオフィードremarks:属性の書式は、この例のように「remarks: Geofeed」としなければならない(MUST)。ここで、トークン「Geofeed」は大文字と小文字を区別しなければならず(MUST)、その後にさまざまなURLが続くが、一つのジオフィード[RFC8805]ファイルのみを参照しなければならない(MUST)。
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed
RPSLの変更に関するグローバルな合意は関係者に委ねるが、inetnum:クラスの適切なgeofeed:属性は必ず「geofeed:」でなければならない(MUST)。また、それに続くURLは1つでなければならず(MUST)、URLは変化するものの、1つのジオフィード[RFC8805]ファイルのみを参照しなければならない(MUST)。
inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed
URLはHTTPSを使用するため、WebPKIは取得したジオフィード・ファイルに対して認証、完全性、機密性を提供する。ただし、WebPKIはIPアドレス空間割り当ての認証を提供できない。対照的に、RPKI([RFC6481]を参照)はIP空間割り当ての認証に使用できる。セクション5のオプション認証を参照のこと。
inetnum:オブジェクトのすべてのプロデューサ、つまりRIRがgeofeed:属性のサポートに移行したと表明するまで、ジオフィードURLを見つけるためにinetnum:オブジェクトを参照するコンシューマは、remarks:とgeofeed:の両方の書式を利用できなければならない(MUST)。
この移行は、RIRがgeofeed:属性をサポートするだけでなく、すべての登録者がすべての inetnum:オブジェクトをremarks:からgeofeed:属性に移行したことを意味する。
特定のinetnum:オブジェクトは、それが実装されているとき、remarks:であれ、適切なgeofeed:属性であれ、最大で1つのジオフィード参照を持つ必要がある(SHOULD)。remarks:の形式はRIRが正式にチェックできないため、これを正式に強制することはできない。RIRがサポートしていれば、geofeed:属性が優先される。intetnum:オブジェクトに複数のタイプの属性がある場合は、geofeed:属性を使わなければならない(MUST)。
同じアドレス範囲をカバーするinetnum:オブジェクトに対しては、署名されていないファイルよりも署名されたジオフィード・ファイルを優先しなければならない(MUST)。署名されたものがない場合、または複数の署名されたものがある場合は、最新のlast-modified:属性を持つ(署名された)inetnum:を優先しなければならない(MUST)。
ジオフィード・ファイルが複数のIPアドレス空間のバラバラの範囲を記述している場合、複数のinetnum:オブジェクトのジオフィード参照が存在する可能性がある。複数のinetnum:オブジェクトのジオフィード参照を含むファイルは、セクション5の署名手順と互換性がない。
署名されていないジオフィード・ファイルは、複数のinetnum:オブジェクトで参照してもよいし、複数のレジストリのプレフィックスを含んでもよい(MAY)。
取得時には、ジオフィード参照を持つ最もスペシフィックなinetnum:オブジェクトを使用しなければならない(MUST)。
ジオフィード・データの粒度は、それらを参照するinetnum:よりも細かいかも知れない、ということは重要である。例えば、アドレス範囲PのINETNUMオブジェクトは、Pが複数のより長いプレフィックスに細分化されたジオフィード・ファイルを参照することができる。
4. ジオフィード・データの取得
本文書は、関係者がどのようにジオフィード・ファイルを取得し、読み取るかについてのガイドラインを提供する。
歴史的に見ると、[RFC9092]以前は、これは実装者の裁量でさまざまな方法で行われており、多くの場合、一貫した認証がなく、正式な承認や検証なしに電子メールからデータがインポートされることがほとんどであった。
RIRのWHOIS[RFC3912]サービスの負荷を最小限に抑えるため、RIRのFTP[RFC0959]サービスを、ジオフィード参照を持つinetnum:オブジェクトを収集するための大規模なアクセスに使用する必要がある(SHOULD)。これにより、IP空間を総当たりで検索して取得する代わりに、効率的な一括アクセスに使用できる。
署名されていないジオフィード・ファイルからデータを読み取る場合、参照元のinetnum:オブジェクトのアドレス範囲外のデータを無視しなければならない(MUST)。これは、オペレータの制御下にない範囲に関するデータのインポートを避けるためである。署名済みァイルは、セクション5で義務付けられている参照元のinetnum:の範囲内のプレフィックスのみを含めなければならない(MUST)ことに留意する。
ジオフィード・ファイルを取得する場合、inetnum:の他の位置情報は無視しなければならない(MUST)。
関心のあるアドレス範囲が与えられた場合、ジオフィードファイルを取得するために、ジオフィード参照を持つ最もスペシフィックなinetnum:オブジェクトを使用しなければならない(MUST)。例えば、取得側が次のinetnum:オブジェクトを見つけた場合:
inetnum: 192.0.0.0/22 # example
remarks: Geofeed https://example.com/geofeed_1
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed_2
192.0.2.0/29のジオフィード・データを探すアプリケーションは、geofeed_1のデータを無視しなければならない(MUST)。なぜなら、192.0.2.0/29はそのアドレス範囲をカバーする、モア・スペシフィックな192.0.2.0/24のinetnum:にあり、そのinetnum:にはジオフィード参照があるからである。
inetnum:オブジェクトに含まれるcountry:、geoloc:などのヒントは、管理上のものであり、展開に固有のものではない傾向がある。大規模でグローバルなプロバイダで、ほとんどの展開から本社が非常に離れている場合を考えてみる。したがって、geofeed:属性またはジオフィードremarks:属性でジオフィード・データを指定した場合、そのアドレス範囲のcountry:、geoloc:、DNS geoloc RRsetsなどの他の地理的ヒントは無視しなければならない(MUST)。
RPSLデータをすべてのRIRでトラバースし、すべてのジオフィード参照を収集し、処理するオープンソースのコードがある[GEOFEED-FINDER]。これは、上記の手順と、キャッシュを含むセクション6で説明するすべての運用上の考慮事項を実装している。見つかったすべてのジオフィード・ファイルをマージして、1つのジオフィード・ファイルを生成する。このオープンソースのコードはcronジョブによって毎日実行することができ、出力ファイルを直接使用することができる。
RIRは、ジオフィード・データを含む登録データ・アクセス・プロトコル(RDAP)のサポートにまとまっている。[RDAP-GEOFEED]を参照のこと。これは、ジオフィード・データの一括取得には使用するべきではない(SHOULD NOT)。
5. ジオフィード・データの認証(オプション)
特定のジオフィード[RFC8805]データセットが有効かどうか、つまりIPアドレス空間の「保有者」によって認可され、ある意味で信頼できるかどうかという疑問が生じる。ジオフィード[RFC8805]ファイルを指すinetnum:は、ある程度の保証を提供する。残念ながら、いくつかのリポジトリのRPSLは、せいぜい弱い認証である。RPSLが[RFC7909]に従って署名するアプローチは、すべてのRPSLレジストリで展開する必要があることを除けば、良いアプローチであり、その数はかなり多い。
このセクションの残りの部分では、「リソース公開鍵基盤 (RPKI)の署名済みオブジェクトのテンプレート」[RFC6488] に従うジオフィード・データセットのオプションの認証コードを規定する。
ジオフィード[RFC8805]ファイルには、オプションの認証コードを1つ付加してもよい(MAY)。これは、カバーするアドレス範囲に関連するRPKI証明書の秘密鍵で署名されたファイル本体のダイジェストである。以下の形式は、該当するRPKI証明書とジオフィード・テキストの署名がバンドルされている。
正規化手順は、データを内部文字表現からUTF-8[RFC3629]文字エンコーディングに変換し、各テキスト行の終わりを示すために<CRLF>シーケンスを使用しなければならない(MUST)。空白行は<CRLF>シーケンスのみで表される。堅牢性のために、印刷できない文字は正規化によって変更してはならない(MUST NOT)。末尾の空白行はファイルの末尾に現れてはならない(MUST NOT)。つまり、ファイルは複数の連続した<CRLF>シーケンスで終わってはならない。オペレーティング・システムが使用するファイル終了マーカーは、ファイル内容の一部とは見なされない。存在する場合、そのようなファイル終了マーカーはデジタル署名でカバーしてはならない(MUST NOT)。
認証コードが上記の正規形式でない場合、その認証コードは無効である。
[RFC5485]から分離署名を借用し、ファイルの正規化後、暗号メッセージ構文(CMS)[RFC5652]を使用して分離DERエンコード署名を作成し、その後、パディング([RFC4648]セクション4で定義)付きでBase64エンコードし、72文字以下に行折り返しをする。署名対象のコンテンツ(ジオフィード・ファイル)のメッセージ・ダイジェストを計算するとともに、SignerInfo SignedAttributes[RFC8933]のメッセージ・ダイジェストを計算するときにも、同じダイジェスト・アルゴリズムを使用しなければならない(MUST)。メッセージ・ダイジェスト・アルゴリズム識別子は、CMS SignedData DigestAlgorithmIdentifiersとSignerInfo DigestAlgorithmIdentifier[RFC5652]の両方に出現しなければならない(MUST)。ジオフィードのinetnum:オブジェクトのアドレス範囲をカバーするRPKI証明書は、CMS SignedData証明書フィールド[RFC5652]に含まれる。
署名証明書のアドレス範囲は、署名済みジオフィード・ファイルのすべてのプレフィックスをカバーしなければならない(MUST)。そうでない場合、認証コードは無効である。
署名証明書は、自律システム識別子委任証明書拡張[RFC3779]を含んではならない(MUST NOT)。これが存在する場合、認証コードは無効である。
他の多くのRPKI署名済みオブジェクトと同様に、IPアドレス委任証明書拡張では、 [RFC3779]のセクション2.2.3.5で定義されている「inherit」(継承)機能を使用してはならない。「inherit」が使用されている場合、認証コードは無効となる。
「inherit」を使用するIPアドレス委任拡張は、処理を複雑にする。実装は、エンド・エンティティからトラストアンカーへの認証パスを構築し、次にトラストアンカーからエンド・エンティティへのパスを検証し、検証された公開鍵を使用してCMSオブジェクトの署名を検証するときにパラメータを記憶しなければならない。CMSオブジェクト処理で使用するために、認証パスの検証から得た情報を記憶しなければならないのは、非常に複雑でエラーが発生しやすくなる。さらに、情報を繰り返すことで証明書がそれほど大きくなることはない。
アドレス範囲Aは、アドレス範囲Bの範囲がAと同一であるか、Aの一部である場合に、アドレス範囲Bを「カバー」する。ここで「アドレス範囲」を使用しているのは、inetnum:オブジェクトとRPKI証明書はクラスレス・ドメイン間ルーティング(CIDR)[RFC4632]のプレフィックス境界に合わせる必要はないが、ジオフィード・ファイルの行の境界では合わせる必要があるためである。
認証局(CA)は、生成した秘密鍵で1つのジオフィード・ファイルにのみ署名し、特定のジオフィード・ファイルの新しいバージョンごとに新しい鍵ペアを生成する必要がある(SHOULD)。CAは、特定のジオフィード・ファイルの署名ごとに、新しいエンド・エンティティ(EE)証明書を生成しなければならない。この方法で使用される関連EE証明書は、「ワンタイム使用」EE証明書と呼ばれる([RFC6487]のセクション3を参照)。
証明書に関連付けられた秘密鍵を識別し、秘密鍵(ハードウェア・セキュリティ・モジュール(HSM)に格納されている可能性がある)を管理する部門にCMS署名を生成させることは、実装者の課題として残る。一方、署名の検証には同様の複雑さはない。公開RPKIで検証された証明書には、必要な公開鍵が含まれている。RIRのRPKIトラストアンカーは、署名検証を実行する関係者がすでに利用できるものと想定する。ジオフィード・ファイルに対するCMS署名の検証には、以下の作業が含まれる。
- CMS SignedData CertificateSet [RFC5652]から署名者の証明書を取得する。証明書の SubjectKeyIdentifier拡張[RFC5280]は[RFC5652]のSubjectKeyIdentifierと一致しなければならない(MUST)。鍵識別子が一致しない場合は、検証は失敗しなければならない(MUST)。
- 署名者の証明書を検証することで、それが現在の[RFC9286]マニフェストの一部であり、すべてのリソースがRPKI証明書でカバーされていることを確認しなければならない(MUST)。
- 署名者の証明書の認証パスを構築する。必要な証明書はすべて、RPKIリポジトリで容易に入手できることが期待される。認証パスは、[RFC5280]の検証アルゴリズムと、 [RFC3779]で規定されているIPアドレス委任証明書拡張と自律システム識別子委任証明書拡張に関連する追加のチェックに従って有効でなければならない(MUST)。認証パスの検証が失敗した場合、検証は失敗にならなければならない(MUST)。
- 検証された署名者の証明書の公開鍵を使用して、[RFC5652]で規定されているようにCMS SignedDataを検証する。署名の検証が失敗した場合、検証は失敗しなければならない(MUST)。
- eContentTypeオブジェクト識別子(OID)がid-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47)であることを確認する。このOIDは、encapContentInfoオブジェクトのeContentTypeとsignerInfoオブジェクトのContentType署名属性の両方に現れなければならない(MUST)([RFC6488]参照)。
- IPアドレス委任証明書拡張[RFC3779]がジオフィード・ファイルのすべてのアドレス範囲をカバーしていることを検証する。すべてのアドレス範囲がカバーされていない場合、検証は失敗にならなければならない(MUST)。
ジオフィード・ファイルの署名を有効なものと見なすには、上記の手順をすべて成功させなければならない(MUST)。
認証コードはジオフィード・ファイルの末尾に一連の「#」コメントとして隠さなければならない(MUST)。以下の単純な例は暗号法的に正しくない:
# RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
...
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0 - 192.0.2.255
正しい完全な例は付録Aにある。
CMS署名は署名行をカバーしていない。
例に示すように、「# RPKI Signature:」と「# End Signature:」で囲まなければならない(MUST)。RPKI署名のIPアドレス範囲は、ジオフィード・ファイルを指すinetnum:の ジオフィードURLと一致しなければならない(MUST)。
6. 運用上の考慮事項
必要なinetnum:オブジェクトを作成するには、ジオフィード・ファイルの場所を登録したいオペレータは、地域インターネット・レジストリ(RIR)または国内インターネット・レジストリ(NIR)、および/またはアドレス範囲を割り当てたプロバイダのローカル・インターネット・レジストリ(LIR)と調整する必要がある。RIR/NIRは、割当先がinetnum:オブジェクトを作成し、維持するための手段を提供する。また、IPアドレス・リソースの割り当てまたはサブ割り当ての手段を提供し、譲受先がinetnum:オブジェクトを含むWHOISデータを作成することを許可し、それによってジオフィード・ファイルを参照できるようにする。
ジオフィード・ファイルは、HTTPS[RFC9110]を使用して公開および取得しなければならない(MUST)。
ジオフィード・ファイルのデータを使用するとき、参照元のinetnum:オブジェクトのinetnum:属性アドレス範囲外のデータを無視しなければならない(MUST)。
ジオフィード・ファイルがセクション5に従って署名されていない場合に限り、複数のinetnum:オブジェクトは同じジオフィード・ファイルを参照してもよい(MAY)。また、コンシューマーは、ジオフィード・ファイルの中で、プレフィックスが従ったinetnum: オブジェクトのURLのアドレス範囲でカバーされている行だけを使用しなければならない(MUST)。
ジオフィード・ファイルが署名され、署名者の証明書が変更された場合、ジオフィード・ファイルの署名を更新しなければならない(MUST)。
特定の鍵を1つの目的にのみ使用することは、鍵のセキュリティ管理上好ましいことである。署名用秘密鍵をジオフィード・ファイルの署名専用とする場合、RPKI認証局(CA)は、付録Aに示す目的専用の下位証明書を発行することができる。
ある集約先の詳細データが別の集約先の詳細度の低いデータに望ましくない影響を与える可能性があるため、RPSLモデルの外で集約されたジオフィード・データを取得して公開することは避けるべきである。さらに、集約されたジオフィード・データを公開すると、データの読み取り側がセクション4と5で説明したチェックを実行できなくなる。
この文書の公開時点で、ジオロケーション・プロバイダはすべてのRIRでWHOISデータに大量アクセスしている。このようなデータの匿名バージョンは、認可が必要なARINを除くすべてのRIRで公開されている。ただし、そのような認可のないユーザでも、追加のRDAP作業で同じ結果を得ることができる。このようなデータをすべてのRIRに渡し、すべてのジオフィード参照を収集して処理するオープンソース・コードがある[GEOFEED -FINDER]。¶
RPSLとジオフィード・サーバに過度の負荷がかからないようにするため、これらのメカニズムを使用してジオフィード・データを取得するエンティティは、頻繁なリアルタイム検索を行ってはならない(MUST NOT)。[RFC8805]のセクション 3.4では、ジオフィード・データを再取得するタイミングを通知するために、HTTP Expiresヘッダ[RFC9111]を使用することが提案している。このような HTTPヘッダ・シグナルがない場合、データの変更頻度は非常に低いため、コレクタは週1回よりも頻繁に取得すべきではない(SHOULD NOT)。UTCの深夜や月初などの魔法の時間に取得しないのが礼儀だろう。なぜなら、他の多くの人が同じことを行う可能性が高いためである。
7. プライバシーに関する考慮事項
[RFC8805]のジオフィード・データは、IPアドレスのおおよその位置を明らかにするかも知れず、その結果、個々のユーザのおおよその位置が明らかになるかも知れない。残念ながら、[RFC8805]は、このようなユーザの暴露による損害の可能性を回避または軽減するためのプライバシーに関する指針を提供していない。本文書で説明しているように、ジオフィード・ファイルへのポインタを公開する場合、オペレータはジオフィード・データにおけるこの暴露を認識し、慎重でなければならない。[RFC8805]のセクション4のプライバシーに関する考慮事項はすべてこの文書に適用される。
[RFC8805]が位置データを公開する機能が提供されていたが、本文書はそれらのデータへの一括アクセスを容易に利用できる。これは偶然ではなく目標である。
8. 実施状況
本文書の公開時点で、inetnumオブジェクトのgeofeed:属性はRIPEとAPNICデータベースに実装されている。
geofeed:属性をまだサポートしていないデータベースの登録者は、remarks:属性または同等の属性を使用している。
この文書の公開時点では、ARINが公開しているレジストリ・データは、他のレジストリのRPSLと同じではない(WHOISのバベルの塔の調査については[RFC7485]を参照のこと)。したがって、ARINからFTP[RFC0959]、WHOIS[RFC3912]、RDAP[RFC9082]などで取得する場合、「NetRange」属性/鍵は「inetnum」として、「Comment」属性は「remarks」として扱わなければならない。
[rpki-client]は、署名されたジオフィード・ファイルの認可に使用できる。
9. セキュリティに関する考慮事項
一般に、ジオフィード・データのコンシューマは、他のソースも使用してデータを相互検証することが賢明である。[RFC8805]のすべてのセキュリティ上の考慮事項がここでも適用される。
ジオフィード・データのコンシューマは、自分自身でデータを取得して処理する必要がある(SHOULD)。サードパーティによって作成および/または処理されたデータセットのインポートは、サードパーティに大きな信頼が置くことになる。
セクション5で述べたように、RPSLリポジトリには認証が弱い(あるいはまったくない)ものがある。これにより、悪意のあるジオフィード・ファイルを指すinetnum:オブジェクトのなりすましが可能になる。セクション5では、遺憾ながら、RPKIに基づくより強力な認証のための複雑な方法を提案している。
例えば、広いアドレス範囲(例: /16)のinetnum:がRPKI署名付きジオフィード・ファイルを指している場合、顧客や攻撃者は、弱い認可を持つWHOISレジストリで、署名のない同等またはより狭い(例: /24)inetnum:を公開し、ジオフィード参照を持つ最も具体的なinetnum:オブジェクトを使用しなければならないというルールを悪用することができる。
もし、署名が必須であれば、上記の攻撃は阻止できるだろうが、もちろんそれはすぐには起こらない。
RPSLプロバイダは、クエリの頻度が高過ぎるため、サーバからのフェッチを制限しなければならない。通常、クエリのIPアドレスかブロックによって制限をかけている。ジオフィード・ファイル・サーバも同様の防御策を導入する必要があるだろう。
10. IANAに関する考慮事項
管理情報構造(SMI)番号(MIBモジュール登録)レジストリ・グループ(<https://www.iana.org/assignments/smi-numbers/>)のS/MIME CMSコンテンツ・タイプのSMIセキュリティ(1.2.840.113549.1.9.16.1)において、この登録の参考文献はこの文書に更新した:
| 10進数 | 説明 | 参考資料 |
|---|---|---|
| 47 | id-ct-geofeedCSVwithCRLF | RFC9632 |
表1: SMIセキュリティのS/MIMEモジュール識別子(1.2.840.113549.1.9.16.1)
11. 参考文献
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/info/rfc2622>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <https://www.rfc-editor.org/info/rfc2725>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, <https://www.rfc-editor.org/info/rfc4012>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. Kumari, "A Format for Self-Published IP Geolocation Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, <https://www.rfc-editor.org/info/rfc8805>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection", RFC 8933, DOI 10.17487/RFC8933, October 2020, <https://www.rfc-editor.org/info/rfc8933>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, <https://www.rfc-editor.org/info/rfc9286>.
11.2. 参考規格
[GEOFEED-FINDER] "geofeed-finder", commit 5f557a4, March 2024, <https://github.com/massimocandela/geofeed-finder>.
[INET6NUM] RIPE NCC, "RIPE Database Documentation: Description of the INET6NUM Object", <https://apps.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Primary-Objects/#description-of-the-inet6num-object>.
[INETNUM] RIPE NCC, "RIPE Database Documentation: Description of the INETNUM Object", <https://apps.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Primary-Objects/#description-of-the-inetnum-object>.
[RDAP-GEOFEED] Singh, J. and T. Harrison, "An RDAP Extension for Geofeed Data", Work in Progress, Internet-Draft, draft-ietf-regext-rdap-geofeed-07, 6 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-geofeed-07>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, <https://www.rfc-editor.org/info/rfc5485>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, "Inventory and Analysis of WHOIS Registration Objects", RFC 7485, DOI 10.17487/RFC7485, March 2015, <https://www.rfc-editor.org/info/rfc7485>.
[RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures", RFC 7909, DOI 10.17487/RFC7909, June 2016, <https://www.rfc-editor.org/info/rfc7909>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.
[RFC9092] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9092, DOI 10.17487/RFC9092, July 2021, <https://www.rfc-editor.org/info/rfc9092>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RIPE-DB] RIPE NCC, "RIPE Database Documentation", September 2023, <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation>.
[RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A Routing Registry", October 1994, <https://www.ripe.net/publications/docs/ripe-181>.
[RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The RIPE Database", February 1993, <https://www.ripe.net/publications/docs/ripe-081>.
[rpki-client] Snijders, J., "Example on how to use rpki-client to authenticate a signed Geofeed", September 2023, <https://sobornost.net/~job/using_geofeed_authenticators.txt>.
付録A. 例
本付録では、トラストアンカー、トラストアンカーによって署名された証明書失効リスト(CRL)、トラストアンカーに従属するCA証明書、CAによって署名されたCRL、ジオフィードに署名するためのCAに従属するエンド・エンティティ証明書、および分離署名を含む例を示す。
トラストアンカーは、自己署名証明書で表される。RPKIでは通常、トラストアンカーはすべてのIPv4アドレス・ブロック、すべてのIPv6アドレス・ブロック、およびすべての自律システム(AS)番号に対する権限を持つ。
-----BEGIN CERTIFICATE-----
MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5
MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw
M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf
DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E
dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj
sgrwLE2F1fIRkVkwASqToq/D5v9voXaYYaXUNJb4H/5wenRuvT5O/n6PXh70rMQy
F5yzLs96ytxqg5gGX9kabVnvxFU8nHfPa0rhlwfTJnljAgMBAAGjggGHMIIBgzAd
BgNVHQ4EFgQUwL1SXb7SeLIW7LOjQ5XSBguZCDIwHwYDVR0jBBgwFoAUwL1SXb7S
eLIW7LOjQ5XSBguZCDIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI
KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA////
/zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0
1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N
JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih
nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5
v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF
W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg==
-----END CERTIFICATE-----
CRLはトラストアンカーが発行する。
-----BEGIN X509 CRL-----
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
DTIzMDkyMzE1NTUzOFoXDTIzMTAyMzE1NTUzOFqgLzAtMB8GA1UdIwQYMBaAFMC9
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEEMA0GCSqGSIb3DQEBCwUAA4IB
AQCngOu+Nq3WC4y/pHtLoheAOtNg32WWsKPNiEyL+QalmOtURUsWMzOq41bmoPzQ
NDQoRmXe9mvohAVRe0CnM7A07HOtSfjw5aoouPXGTtfwEomHG2CYk+2U1bvxgZyA
E1c5TvyhkabFMO0+857wqxRP+ht9NV0lMX6kUFlEOCw3ELVd9oNNRBwKQtXj1huM
6Sf26va2a1tnC5zP01hN+EY3S9T5T1gcgPGBcqRWKoXJEbRzCrLsb/TMj5cMpIje
AHZoBojVAmvL1AIH/BnGAQj0+XqaJ0axHvlqJa8iX8QwKqhp+o6sv/atY2QDDRmE
Yjq/VrBVKu5VsDY2Lr29HszA
-----END X509 CRL-----
CA証明書はトラストアンカーが発行する。この証明書は、1つのIPv4アドレス・ブロック(192.0.2.0/24)と2つのAS番号(64496と64497)に対する権限を付与する。
-----BEGIN CERTIFICATE-----
MIIE7DCCA9SgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDLkwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MjMxNTU1MzhaFw0yNDA5
MjIxNTU1MzhaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
TnJQHgLJDYqww9yKWtjjAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUOs4s70+yG30R
4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAUwL1SXb7SeLIW7LOjQ5XSBguZCDIwDwYD
VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
BgEFBQcOAjBDBgNVHR8EPDA6MDigNqA0hjJyc3luYzovL3Jwa2kuZXhhbXBsZS5u
ZXQvcmVwb3NpdG9yeS9leGFtcGxlLXRhLmNybDBOBggrBgEFBQcBAQRCMEAwPgYI
KwYBBQUHMAKGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
YW1wbGUtdGEuY2VyMIG5BggrBgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5
bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQw
NQYIKwYBBQUHMA2GKWh0dHBzOi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRp
b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw
b3NpdG9yeS8wHwYIKwYBBQUHAQcBAf8EEDAOMAwEAgABMAYDBADAAAIwIQYIKwYB
BQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEA
arIrZWb22wFmP+hVjhdg3IsKHB6fQdMuUR0u2DyZTVvbL6C+HyGAH32pi5mR/QLX
FAfdqALaB7r68tQTGLIW6bGljT+BqUPJmZcj56x3cBLJlltxwFatTloypjFt3cls
xFCuuD9J2iBxc6odTKi6u0mhQjD+C9m4xkbe8XXWWx85IHm1s6rYbpGgiMWxBC80
qqAzmBHGROWKUEvh00EYIYdiAvyFcrj7QtDiRJL5TDOySVd9pWJkerDzhqwE1IaZ
rpHck+lkYTS7jTD++6v32HG62GdsmryOQUk3aU1rLb3kS8vzaGbrgHpGPid0Hd0x
ZSl1AoIMpp5mZ7/h9aW5+A==
-----END CERTIFICATE-----
CRLはCAが発行する。
-----BEGIN X509 CRL-----
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yMzA5MjMxNTU1MzhaFw0y
MzEwMjMxNTU1MzhaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEACwCNzcAoqbMcUL1kBY65
YhL95OnBqAcuc99pD4i9c1BmVOl7bXU3cJqLaOZ6Z8CmN0kBbcHyqlHBJ9oA/aYD
ByhxsjzKk7jxtM2IlTpEvCEqvnGLSVihgS3h0NA+sgWqHGL3Rhcj6hVsi+j9GENc
T6F9np1mxbI3i2xhgeDJG1pryvH0hWXh7yJiYS8ItNEaIIXDT3szK/J9wnPjukTR
5MITiK9P3TCFujawb3O7rIT5PPgkM6eiCdwDgt6gjmw6cow5+rMjNHSRa+GOviSd
gXljVDfJvF4tKHmw59Jc2aFnSGfX1/ITDNiNfXYpUYFOcsqxkYf8F0uO7AtbRmTF
2w==
-----END X509 CRL-----
エンド・エンティティ証明書はCAが発行する。この証明書は、1つのIPv4アドレス・ブロック(192.0.2.0/24)の署名権限を付与する。AS番号の署名権限はジオフィード・データの署名には必要ないため、エンド・エンティティ証明書にはAS番号を含まない。
-----BEGIN CERTIFICATE-----
MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvAwDQYJKoZIhvcNAQEL
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
Mzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkxNTU1MzhaMDMxMTAvBgNV
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
AAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDgYDVR0PAQH/BAQDAgeAMBgGA1Ud
IAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR0fBFowWDBWoFSgUoZQcnN5bmM6Ly9y
cGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvM0FDRTJDRUY0RkIyMUI3RDExRTNF
MTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmwwbAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUF
BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB
BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUe
e0+uCidTH+4p7At3u2ncgHcGTsag3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131g
MdliL5GQ3P4QfKnfkuPR6S1V8suq6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdG
lXVLjth4x/uu1O4V54GLEhDAPQC8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yi
s6u758nbA7ND40JNhGG5JNGQgDchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IW
Ucv72Mekq+i46T/w3RnaGn4x7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg
8fK1fd/f6fjZ9w==
-----END CERTIFICATE-----
エンド・エンティティ証明書の詳細を以下に表示する。簡潔にするために、他の2つの証明書は表示しない。
1 1110: SEQUENCE {
4 830: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 20: INTEGER
: 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9
: 6E E1 66 F0
35 13: SEQUENCE {
37 9: OBJECT IDENTIFIER
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
48 0: NULL
: }
50 51: SEQUENCE {
52 49: SET {
54 47: SEQUENCE {
56 3: OBJECT IDENTIFIER commonName (2 5 4 3)
61 40: PrintableString
: '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642'
: }
: }
: }
103 30: SEQUENCE {
105 13: UTCTime 23/09/2023 15:55:38 GMT
120 13: UTCTime 19/07/2024 15:55:38 GMT
: }
135 51: SEQUENCE {
137 49: SET {
139 47: SEQUENCE {
141 3: OBJECT IDENTIFIER commonName (2 5 4 3)
146 40: PrintableString
: '914652A3BD51C144260198889F5C45ABF053A187'
: }
: }
: }
188 290: SEQUENCE {
192 13: SEQUENCE {
194 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
205 0: NULL
: }
207 271: BIT STRING, encapsulates {
212 266: SEQUENCE {
216 257: INTEGER
: 00 B2 71 34 2B 39 BF EA 07 65 B7 8B 72 A2 F0 F8
: 40 FC 31 16 CA 28 B6 4E 01 A8 F6 98 02 C0 EF 65
: B0 84 48 E9 96 FF 93 E6 92 89 65 8F F6 44 9C CE
: 57 10 82 D3 C2 57 0A FA DA 14 D0 64 22 28 C0 13
: 74 04 BD 1C 2B 4F F9 93 58 A6 25 D8 B9 A9 D3 37
: 9E F2 AC C0 CF 02 9E 84 75 D6 F0 7C A5 01 70 AE
: E6 66 AF 9C 69 85 74 6F 13 E9 B3 B8 95 4B 82 ED
: 95 D6 EA 66 05 7B 96 96 87 B2 9A E7 61 E9 65 89
: F8 60 E3 C0 F5 CE DD 18 97 05 E8 C1 AC E1 4D 5E
: 16 85 2D ED 3C CB 80 CF 7E BF D2 FE D5 C9 38 19
: BB 43 34 29 B6 66 CF 2D 8B 46 7E 9A D8 BB 8E 65
: 88 51 6A A8 FF 78 51 E2 E9 21 27 D7 77 7E 80 28
: 6C EA 4C 50 9C 73 71 16 F6 5E 54 14 4D 4C 14 B9
: 67 A0 4A 20 AA DA 0B A0 A0 01 B7 42 24 38 51 8A
: 78 2F C4 81 E6 81 75 62 DE E3 AF 5D 74 2F 6B 41
: FB 79 C3 A8 3A 72 6C 46 F9 A6 03 74 81 01 DF 8C
: EB
477 3: INTEGER 65537
: }
: }
: }
482 352: [3] {
486 348: SEQUENCE {
490 29: SEQUENCE {
492 3: OBJECT IDENTIFIER
: subjectKeyIdentifier (2 5 29 14)
497 22: OCTET STRING, encapsulates {
499 20: OCTET STRING
: 91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB
: F0 53 A1 87
: }
: }
521 31: SEQUENCE {
523 3: OBJECT IDENTIFIER
: authorityKeyIdentifier (2 5 29 35)
528 24: OCTET STRING, encapsulates {
530 22: SEQUENCE {
532 20: [0]
: 3A CE 2C EF 4F B2 1B 7D 11 E3 E1 84 EF C1 E2 97
: B3 77 86 42
: }
: }
: }
554 14: SEQUENCE {
556 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
561 1: BOOLEAN TRUE
564 4: OCTET STRING, encapsulates {
566 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
570 24: SEQUENCE {
572 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
577 1: BOOLEAN TRUE
580 14: OCTET STRING, encapsulates {
582 12: SEQUENCE {
584 10: SEQUENCE {
586 8: OBJECT IDENTIFIER
: resourceCertificatePolicy (1 3 6 1 5 5 7 14 2)
: }
: }
: }
: }
596 97: SEQUENCE {
598 3: OBJECT IDENTIFIER
: cRLDistributionPoints (2 5 29 31)
603 90: OCTET STRING, encapsulates {
605 88: SEQUENCE {
607 86: SEQUENCE {
609 84: [0] {
611 82: [0] {
613 80: [6]
: 'rsync://rpki.example.net/repository/3ACE'
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.crl'
: }
: }
: }
: }
: }
: }
695 108: SEQUENCE {
697 8: OBJECT IDENTIFIER
: authorityInfoAccess (1 3 6 1 5 5 7 1 1)
707 96: OCTET STRING, encapsulates {
709 94: SEQUENCE {
711 92: SEQUENCE {
713 8: OBJECT IDENTIFIER
: caIssuers (1 3 6 1 5 5 7 48 2)
723 80: [6]
: 'rsync://rpki.example.net/repository/3ACE'
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.cer'
: }
: }
: }
: }
805 31: SEQUENCE {
807 8: OBJECT IDENTIFIER
: ipAddrBlocks (1 3 6 1 5 5 7 1 7)
817 1: BOOLEAN TRUE
820 16: OCTET STRING, encapsulates {
822 14: SEQUENCE {
824 12: SEQUENCE {
826 2: OCTET STRING 00 01
830 6: SEQUENCE {
832 4: BIT STRING
: '010000000000000000000011'B
: }
: }
: }
: }
: }
: }
: }
: }
838 13: SEQUENCE {
840 9: OBJECT IDENTIFIER
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
851 0: NULL
: }
853 257: BIT STRING
: 97 1B 76 E4 55 1E 7B 4F AE 0A 27 53 1F EE 29 EC
: 0B 77 BB 69 DC 80 77 06 4E C6 A0 DD 47 28 3E 37
: 04 FC 8D 49 81 02 51 BB D4 E2 33 88 8D 07 50 BB
: 2D B7 5D D7 7D 60 31 D9 62 2F 91 90 DC FE 10 7C
: A9 DF 92 E3 D1 E9 2D 55 F2 CB AA E9 94 F5 29 04
: 72 2C 9C 7E 10 F8 03 37 6A DB FE 28 E2 D1 33 8A
: E9 12 8F 34 17 46 95 75 4B 8E D8 78 C7 FB AE D4
: EE 15 E7 81 8B 12 10 C0 3D 00 BC 21 49 B9 8A 7B
: 4B FC 7C 75 33 5C 76 A6 D3 7F FA 3E 47 0F 75 D4
: 5D DD F1 D7 7C A2 B3 AB BB E7 C9 DB 03 B3 43 E3
: 42 4D 84 61 B9 24 D1 90 80 37 21 2F 82 10 CC 88
: 72 94 C3 42 F9 B2 94 8B 2C 8C 1F 3D CC AA 85 40
: 92 52 01 F3 A2 16 51 CB FB D8 C7 A4 AB E8 B8 E9
: 3F F0 DD 19 DA 1A 7E 31 ED 10 09 72 D5 49 5B 0D
: DE E5 83 2B 16 74 1C BA E6 86 3A CD 10 72 8C 56
: EC 18 B8 5B B1 20 F1 F2 B5 7D DF DF E9 F8 D9 F7
: }
署名結果を再現できるように、エンド・エンティティの秘密鍵が提供される。簡潔にするために、他の2つの秘密鍵は提供しない。
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio
pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z
ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ
mpkwmygPjfECT9wbWo0yn3jxJb36+M/QjjUP28oNIVn/IKoPZRXnqchEbuuCJ651
IsaFSqtiThm4WZtvCH/IDq+6/dcMucmTjIRcYwW7fdHfjplllVPve9c/OmpWEQvF
t3ArWUt5AoGBANs4764yHxo4mctLIE7G7l/tf9bP4KKUiYw4R4ByEocuqMC4yhmt
MPCfOFLOQet71OWCkjP2L/7EKUe9yx7G5KmxAHY6jOjvcRkvGsl6lWFOsQ8p126M
Y9hmGzMOjtsdhAiMmOWKzjvm4WqfMgghQe+PnjjSVkgTt+7BxpIuGBAvAoGBANBg
26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm07l
nE+lAZwxm+29PTD0nqCFE91teyzjnQaLO5kkAdJiFuVV3icLOGo399FrnJbKensm
FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
-----END RSA PRIVATE KEY-----
「192.0.2.0/24,US,WA,Seattle」(CRとLFで終了)に署名すると、以下の独立したCMS署名を生成する。
# RPKI Signature: 192.0.2.0/24
# MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv
# AwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkx
# NTU1MzhaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
# FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
# zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
# ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71R
# wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
# wDgYDVR0PAQH/BAQDAgeAMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR
# 0fBFowWDBWoFSgUoZQcnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvc
# nkvM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmww
# bAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUFBzAChlByc3luYzovL3Jwa2kuZXhhbXB
# sZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRT
# I5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcBBwEB/wQQMA4wDAQCAAEwBgMEAMAAA
# jANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUee0+uCidTH+4p7At3u2ncgHcGTsag
# 3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131gMdliL5GQ3P4QfKnfkuPR6S1V8su
# q6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdGlXVLjth4x/uu1O4V54GLEhDAPQ
# C8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yis6u758nbA7ND40JNhGG5JNGQg
# DchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IWUcv72Mekq+i46T/w3RnaGn4x
# 7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg8fK1fd/f6fjZ9zGCAaowggG
# mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk
# iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTIzMDkyMzE1N
# TUzOFowLwYJKoZIhvcNAQkEMSIEICvi8p5S8ckg2wTRhDBQzGijjyqs5T6I+4Vt
# BHypfcEWMA0GCSqGSIb3DQEBAQUABIIBAKZND7pKdVdfpB6zaJN89wTt+sXd0io
# 0WULMc+o6gRJFt3wmKNW2nYPrDbocJ+Q/rDMGxbp4QetJ0MQtn1+AYAS8v5jPDO
# 4a63U4/mJ2D3wSnQsDP0lUVknqRzfnS66HgHqiOVdHB0U+OnMEJuqHNTLx0dknb
# L3zwxyDJTHdo+dMB0U9xdcjwpsPM3xqg57EXj5EIQK5JbardXCjrsysAnEdktUY
# oyayGNbbQelANYJcOmuHhSXArR+qqzvNP2MDRqqKEcpd65YW6FSnqlVMIBH2M3P
# D2F0p3sdm4IeGAZWaERVB4AXO1PUFDNdhamr4XpIwqIoAig7xiLm7j8qu5Oc=
# End Signature: 192.0.2.0/24
⚠️ ジオフィード・ファイルの検証
% curl -O https://sobornost.net/geofeed.csv
% rpki-client -f geofeed.csv
File: geofeed.csv
Hash identifier: owVqlXn5Br1R5w0biSp9ocxpM5VTjQg5pDFhbKT3kFc=
Subject key identifier: 22:2D:C6:F1:33:55:BE:C5:79:DD:D5:C1:E7:B1:0B:11:E1:D9:A7:E9
Certificate issuer: /CN=caa805dbac364749b9b115590ab6ef0f970cdbd8
Certificate serial: 07
Authority key identifier: CA:A8:05:DB:AC:36:47:49:B9:B1:15:59:0A:B6:EF:0F:97:0C:DB:D8
Authority info access: rsync://rpki.ripe.net/repository/DEFAULT/yqgF26w2R0m5sRVZCrbvD5cM29g.cer
Signing time: Wed 10 Jan 2024 18:40:45 +0000
Geofeed not before: Wed 10 Jan 2024 18:40:35 +0000
Geofeed not after: Thu 09 Jan 2025 18:40:35 +0000
Geofeed CSV records: IP: 2001:67c:208c::/48 (NL,NL-NH,Amsterdam,)
Validation: OK
Signature path: rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/yqgF26w2R0m5sRVZCrbvD5cM29g.crl
rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/yqgF26w2R0m5sRVZCrbvD5cM29g.mft
rsync://rpki.ripe.net/repository/DEFAULT/yqgF26w2R0m5sRVZCrbvD5cM29g.cer
rsync://rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.crl
rsync://rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.mft
rsync://rpki.ripe.net/repository/aca/KpSo3VVK5wEHIJnHC2QHVV3d5mk.cer
rsync://rpki.ripe.net/repository/aca/7DNNDzoYvgAht7joQih2Qayxcxo.crl
rsync://rpki.ripe.net/repository/aca/7DNNDzoYvgAht7joQih2Qayxcxo.mft
rsync://rpki.ripe.net/repository/ec334d0f3a18be0021b7b8e842287641acb1731a.cer
rsync://rpki.ripe.net/repository/ripe-ncc-ta.crl
rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
Signature path expires: Sun 11 Aug 2024 16:20:42 +0000
% rpki-client -j -f geofeed.csv
{
"file": "geofeed.csv",
"hash_id": "owVqlXn5Br1R5w0biSp9ocxpM5VTjQg5pDFhbKT3kFc=",
"type": "geofeed",
"ski": "22:2D:C6:F1:33:55:BE:C5:79:DD:D5:C1:E7:B1:0B:11:E1:D9:A7:E9",
"cert_issuer": "/CN=caa805dbac364749b9b115590ab6ef0f970cdbd8",
"cert_serial": "07",
"aki": "CA:A8:05:DB:AC:36:47:49:B9:B1:15:59:0A:B6:EF:0F:97:0C:DB:D8",
"aia": "rsync://rpki.ripe.net/repository/DEFAULT/yqgF26w2R0m5sRVZCrbvD5cM29g.cer",
"signing_time": 1704912045,
"valid_since": 1704912035,
"valid_until": 1736448035,
"expires": 1723393242,
"records": [
{ "prefix": "2001:67c:208c::/48", "location": "NL,NL-NH,Amsterdam," }
],
"validation": "OK"
}
謝辞
CMSと独立した署名のヒントを提供してくれたロブ・オースティン、最初の実質的な外部レビューをしてくれたジョージ・ミケルソン、そして恥ずかしがり屋で共著者になるのを同意してくれなかったエリック・クラインに感謝する。さらに、 メンノ・シェパース、フラビオ・ルチアーニ、エリック・デュガス、ケビン・パックなどの初期の実装者にも感謝の意を表する。また、ここで説明したソリューションでジオフィードを使用している以下のジオロケーション・プロバイダにも感謝する: ジョナサン・コスゲイ (ipdata.co)、ベン・ダウリング(ipinfo.io)、ポル・ナイゼンブラット(bigdatacloud.com)。驚くほど多くの役立つレビューを提供してくれたジョブ・スナイデルス(ASN.1の「inherit」問題も見つけてくれた)をはじめ、エイドリアン・ファレル、アントニオ・プラド、フランチェスカ・パロンビーニ、ジャン＝ミシェル・コンブ(INTDIR)、ジョン・スカダー、カイル・ローズ(SECDIR)、マーティン・デューク、モハメド・ブカデール、マレー・クチェラウィ、ポール・キジバット(GENART)、ロブ・ウィルトン、ロマン・ダニリュー、タイ・デ・コックに感謝する。
著者のアドレス
ランディ・ブッシュ
IIJ Research & Arrcus
5147 Crystal Springs
Bainbridge Island, Washington 98110
アメリカ合衆国
メールアドレス: randy@psg.com
マッシモ・カンデラ
NTT
Veemweg 23
3771 MT Barneveld
オランダ
メールアドレス: massimo@ntt.net
ウォーレン・クマリ
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
アメリカ合衆国
メールアドレス: warren@kumari.net
ラス・ハウスリー
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
アメリカ合衆国
メールアドレス: housley@vigilsec.com
更新履歴
- 2024.8.11
Discussion