Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 9632 IIJ Research & Arrcus
Obsoletes: 9092 M. Candela
Category: Standards Track NTT
ISSN: 2070-1721 W. Kumari
Google
R. Housley
Vigil Security
August 2024
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092.
このドキュメントは、ルーティングポリシー仕様言語（RPSL）inetnumを拡張する方法を指定しています。データファイル。このドキュメントは、RFC 9092を廃止します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9632.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9632で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Geofeed Files
3. inetnum: Class
4. Fetching Geofeed Data
5. Authenticating Geofeed Data (Optional)
6. Operational Considerations
7. Privacy Considerations
8. Implementation Status
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Example
Acknowledgments
Authors' Addresses
Providers of Internet content and other services may wish to customize those services based on the geographic location of the user of the service. This is often done using the source IP address used to contact the service, which may not point to a user; see Section 14 of [RFC6269] in particular. Also, administrators of infrastructure and other services might wish to publish the locale of said infrastructure or services. infrastructure and other services might wish to publish the locale of their services. [RFC8805] defines geofeed, a syntax to associate geographic locales with IP addresses, but it does not specify how to find the relevant geofeed data given an IP address.
インターネットコンテンツやその他のサービスのプロバイダーは、サービスのユーザーの地理的位置に基づいてこれらのサービスをカスタマイズしたい場合があります。これは、ユーザーを指すことはない場合があるサービスに連絡するために使用されるソースIPアドレスを使用して行われることがよくあります。特に[RFC6269]のセクション14を参照してください。また、インフラストラクチャやその他のサービスの管理者は、当該インフラストラクチャまたはサービスのロケールを公開したい場合があります。インフラストラクチャやその他のサービスは、サービスのロケールを公開したい場合があります。[RFC8805]は、地理的な場所をIPアドレスに関連付ける構文であるGeoFeedを定義しますが、IPアドレスが与えられた関連するジオフィードデータを見つける方法を指定していません。
This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC2725] inetnum: class to refer specifically to geofeed data files and how to prudently use them. In all places inetnum: is used, inet6num: should also be assumed [RFC4012].
このドキュメントは、ルーティングポリシー仕様言語（RPSL）[RFC2725] INETNUM：GeoFeedデータファイルを特に参照するクラスと、それらを慎重に使用する方法を指定します。すべての場所でinetnum：inet6num：想定される必要があります[rfc4012]。
The reader may find [INETNUM] and [INET6NUM] informative, and certainly more verbose, descriptions of the inetnum: database classes.
読者は、[inetnum]および[inet6num]が有益であり、確かに冗長なinetnum：databaseクラスの説明を見つける場合があります。
An optional utterly awesome but slightly complex means for authenticating geofeed data is also defined in Section 5.
ジオフィードデータを認証するためのオプションの非常に素晴らしいがわずかに複雑な手段も、セクション5で定義されています。
This document obsoletes [RFC9092]. Changes from [RFC9092] include the following:
この文書は廃止[RFC9092]。[RFC9092]からの変更には、次のものが含まれます。
* RIPE has implemented the geofeed: attribute.
* RipeはGeofeed：Attributeを実装しました。
* This document allows, but discourages, an inetnum: to have both a geofeed remarks: attribute and a geofeed: attribute.
* このドキュメントは、inetnum：属性とジオフィード：属性の両方を持つことを許可しますが、阻止します。
* The Authentication section (Section 5) has been rewritten to be more formal.
* 認証セクション（セクション5）は、より正式になるように書き直されています。
* Geofeed files are only UTF-8 CSV.
* GeoFeedファイルはUTF-8 CSVのみです。
* This document stresses that authenticating geofeed data is optional.
* このドキュメントは、ジオフィードデータの認証がオプションであることを強調しています。
* IP Address Delegation extensions must not use "inherit".
* IPアドレス委任拡張機能は「継承」を使用してはなりません。
* If geofeed data are present, geographic location hints in other data should be ignored.
* ジオフィードデータが存在する場合、他のデータの地理的位置のヒントは無視する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Geofeed files are described in [RFC8805]. They provide a facility for an IP address resource "owner" to associate those IP addresses to geographic locales.
ジオフィードファイルは[RFC8805]で説明されています。それらは、IPアドレスリソース「所有者」の機能を提供して、これらのIPアドレスを地理的地域に関連付けます。
Per [RFC8805], geofeed files consist of comma-separated values (CSV) in UTF-8 text format, not HTML, richtext, or other formats.
[RFC8805]に従って、GeoFeedファイルは、HTML、RichText、またはその他の形式ではなく、UTF-8テキスト形式のコンマセパレーション値（CSV）で構成されています。
Content providers and other parties who wish to locate an IP address to a geographic locale need to find the relevant geofeed data. In Section 3, this document specifies how to find the relevant geofeed [RFC8805] file given an IP address.
IPアドレスを地理的ロケールに配置したいコンテンツプロバイダーおよびその他の関係者は、関連するジオフィードデータを見つける必要があります。セクション3では、このドキュメントは、IPアドレスが与えられた関連するGeoFeeed [RFC8805]ファイルを見つける方法を指定しています。
Geofeed data for large providers with significant horizontal scale and high granularity can be quite large. The size of a file can be even larger if an unsigned geofeed file combines data for many prefixes, if dual IPv4/IPv6 spaces are represented, etc.
大きな水平スケールと高い粒度性を持つ大規模なプロバイダー向けのジオフィードデータは非常に大きくなる可能性があります。署名されていないジオフィードファイルが多くのプレフィックスのデータを組み合わせた場合、デュアルIPv4/IPv6スペースが表されている場合など、ファイルのサイズはさらに大きくなります。
Geofeed data do have privacy considerations (see Section 7); this process makes bulk access to those data easier.
Geofeedデータにはプライバシーに関する考慮事項があります（セクション7を参照）。このプロセスにより、これらのデータへの一括アクセスが容易になります。
This document also suggests an optional signature to strongly authenticate the data in the geofeed files.
このドキュメントは、GeoFeedファイルのデータを強く認証するためのオプションの署名も提案しています。
The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent documents were written by the RIPE community. The IETF standardized RPSL in [RFC2622] and [RFC4012]. Since then, it has been modified and extensively enhanced in the Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB]. At the time of publishing this document, change control of the RPSL effectively lies in the operator community.
[Ripe81]、[Ripe181]から始まる元のRPSL仕様、およびその後の文書の軌跡は、Ripeコミュニティによって書かれました。IETFは[RFC2622]および[RFC4012]のRPSLを標準化しました。それ以来、それは地域のインターネットレジストリ（RIR）コミュニティで変更され、主にRipe [Ripe-DB]によって大幅に強化されています。このドキュメントを公開する時点で、RPSLの制御を変更することは、オペレーターコミュニティに効果的にあります。
The inetnum: database class is specified by the RPSL, as well as Routing Policy System Security [RFC2725] and RPSLng [RFC4012], which are used by the Regional Internet Registries (RIRs). Each of these objects describes an IP address range and its attributes. The inetnum: objects form a hierarchy ordered on the address space.
INETNUM：データベースクラスは、RPSLによって指定され、ルーティングポリシーシステムセキュリティ[RFC2725]およびRPSLNG [RFC4012]が指定されており、これは地域のインターネットレジストリ（RIRS）で使用されます。これらの各オブジェクトは、IPアドレス範囲とその属性を記述します。inetnum：オブジェクトは、アドレス空間で注文された階層を形成します。
Ideally, the RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Absent implementation of the geofeed: attribute in a particular RIR database, this document defines the syntax of a Geofeed remarks: attribute, which contains an HTTPS URL of a geofeed file. The format of the inetnum: geofeed remarks: attribute MUST be as in this example, "remarks: Geofeed ", where the token "Geofeed " MUST be case sensitive, followed by a URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file.
理想的には、RPSLが増強され、新しいRPSL Geofeed：属性がinetnum：classを定義します。ジオフィードの実装の欠如：属性特定のRIRデータベースの属性このドキュメントは、ジオフィードファイルのHTTPS URLを含むジオフィードの備考：属性の構文を定義します。inetnum：geofeed remarks：属性の形式は、この例のように「備考：geofeed」でなければなりません。ここで、トークン「geofeed」はケースに敏感でなければなりません。Geofeed [RFC8805]ファイル。
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed
While we leave global agreement of RPSL modification to the relevant parties, we specify that a proper geofeed: attribute in the inetnum: class MUST be "geofeed:" and MUST be followed by a single URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file.
RPSL修正のグローバルな合意を関連当事者に任せている間、適切なジオフィード：inetnum：classの属性が「ジオフィード：」でなければならないことを指定し、変化する単一のURLが続く必要がありますが、参照する必要があります。単一のジオフィード[RFC8805]ファイル。
inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed
The URL uses HTTPS, so the WebPKI provides authentication, integrity, and confidentiality for the fetched geofeed file. However, the WebPKI cannot provide authentication of IP address space assignment. In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP space assignment; see optional authentication in Section 5.
URLはHTTPSを使用するため、WebPKIはフェッチされたジオフィードファイルの認証、整合性、および機密性を提供します。ただし、WebPKIはIPアドレススペースの割り当ての認証を提供することはできません。対照的に、RPKI（[RFC6481]を参照）を使用して、IPスペース割り当てを認証できます。セクション5のオプションの認証を参照してください。
Until all producers of inetnum: objects, i.e., the RIRs, state that they have migrated to supporting a geofeed: attribute, consumers looking at inetnum: objects to find geofeed URLs MUST be able to consume both the remarks: and geofeed: forms.
INETNUM：オブジェクト、つまりRIRSのすべての生産者が、ジオフィードをサポートするために移行したと述べています。
The migration not only implies that the RIRs support the geofeed: attribute, but that all registrants have migrated any inetnum: objects from remarks: to geofeed: attributes.
移行は、RIRSがGeofeed：属性をサポートすることを意味するだけでなく、すべての登録者がinetnum：nemarks：to Geofeed：属性を移行したことを意味します。
Any particular inetnum: object SHOULD have, at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. As the remarks: form cannot be formally checked by the RIR, this cannot be formally enforced. A geofeed: attribute is preferred, of course, if the RIR supports it. If there is more than one type of attribute in the intetnum: object, the geofeed: attribute MUST be used.
特定のinetnum：オブジェクトは、せいぜい1つのジオフィードリファレンスを持つ必要があります。備考：フォームをRIRによって正式にチェックすることはできませんが、これは正式に実施することはできません。Geofeed：もちろん、RIRがサポートする場合、属性が推奨されます。intetnum：object、geofeed：属性に複数のタイプの属性がある場合は、使用する必要があります。
For inetnum: objects covering the same address range, a signed geofeed file MUST be preferred over an unsigned file. If none are signed, or more than one is signed, the (signed) inetnum: with the most recent last-modified: attribute MUST be preferred.
INETNUM：同じアドレス範囲をカバーするオブジェクトでは、署名されたジオフィードファイルを署名していないファイルよりも優先する必要があります。署名されていない場合、または複数の署名に署名されている場合、（署名された）inetnum：最新のラスト修飾：属性を優先する必要があります。
If a geofeed file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects. Files with geofeed references from multiple inetnum: objects are not compatible with the signing procedure in Section 5.
GeoFeedファイルがIPアドレススペースの複数の分離範囲を記述している場合、複数のinetnum：オブジェクトからジオフィード参照がある可能性があります。複数のinetnumからのジオフィード参照を備えたファイル：オブジェクトは、セクション5の署名手順と互換性がありません。
An unsigned, and only an unsigned, geofeed file MAY be referenced by multiple inetnum: objects and MAY contain prefixes from more than one registry.
署名されていない、署名されていないジオフィードファイルのみが、複数のinetnum：オブジェクトによって参照される場合があり、複数のレジストリからの接頭辞が含まれている場合があります。
When fetching, the most specific inetnum: object with a geofeed reference MUST be used.
フェッチするとき、最も具体的なinetnum：ジオフィード参照を持つオブジェクトを使用する必要があります。
It is significant that geofeed data may have finer granularity than the inetnum: that refers to them. For example, an INETNUM object for an address range P could refer to a geofeed file in which P has been subdivided into one or more longer prefixes.
ジオフィードデータは、inetnumよりも細かい粒度を持っている可能性があることが重要です。それはそれらを指します。たとえば、アドレス範囲PのINETNUMオブジェクトは、Pが1つ以上の長いプレフィックスに細分化されたジオフィードファイルを参照できます。
This document provides a guideline for how interested parties should fetch and read geofeed files.
このドキュメントは、利害関係者がGeofeedファイルを取得して読み取る方法に関するガイドラインを提供します。
Historically, before [RFC9092], this was done in varied ways, at the discretion of the implementor, often without consistent authentication, where data were mostly imported from email without formal authorization or validation.
歴史的には、[RFC9092]の前に、これはさまざまな方法で、多くの場合、一貫した認証なしで実装者の裁量で行われました。
To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP [RFC0959] services SHOULD be used for large-scale access to gather inetnum: objects with geofeed references. This uses efficient bulk access instead of fetching via brute-force search through the IP space.
RIRSのWHOIS [RFC3912]サービスの負荷を最小限に抑えるには、RIRのFTP [RFC0959]サービスを使用して、GeoFeed参照を持つオブジェクトを収集するために大規模なアクセスに使用する必要があります。これにより、IPスペースを介してブルートフォース検索を介してフェッチする代わりに、効率的なバルクアクセスが使用されます。
When reading data from an unsigned geofeed file, one MUST ignore data outside the referring inetnum: object's address range. This is to avoid importing data about ranges not under the control of the operator. Note that signed files MUST only contain prefixes within the referring inetnum:'s range as mandated in Section 5.
署名されていないジオフィードファイルからデータを読み取る場合、参照Inetnum：Objectのアドレス範囲外のデータを無視する必要があります。これは、オペレーターの制御下にない範囲に関するデータのインポートを避けるためです。署名されたファイルには、セクション5で義務付けられている参照Inetnum： 'の範囲内にプレフィックスのみが含まれている必要があることに注意してください。
If geofeed files are fetched, other location information from the inetnum: MUST be ignored.
GeoFeedファイルがフェッチされている場合、INETNUMからの他の位置情報：無視する必要があります。
Given an address range of interest, the most specific inetnum: object with a geofeed reference MUST be used to fetch the geofeed file. For example, if the fetching party finds the following inetnum: objects:
対象のアドレス範囲を考えると、最も具体的なinetnum：Geofeedリファレンスを持つオブジェクトを使用して、ジオフィードファイルを取得する必要があります。たとえば、フェッチパーティが次の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
An application looking for geofeed data for 192.0.2.0/29 MUST ignore data in geofeed_1 because 192.0.2.0/29 is within the more specific 192.0.2.0/24 inetnum: covering that address range and that inetnum: does have a geofeed reference.
192.0.2.0/29のGeoFeedデータを探しているアプリケーションは、192.0.2.0/29がより具体的な192.0.2.0/24内にあるため、GeoFeed_1のデータを無視する必要があります。
Hints in inetnum: objects such as country:, geoloc:, etc., tend to be administrative, and not deployment specific. Consider large, possibly global, providers with headquarters very far from most of their deployments. Therefore, if geofeed data are specified, either as a geofeed: attribute or in a geofeed remarks: attribute, other geographic hints such as country:, geoloc:, DNS geoloc RRsets, etc., for that address range MUST be ignored.
inetnumのヒント：国：geoloc：、などのオブジェクトは、管理的であり、展開固有ではない傾向があります。本部を持つ大規模で、おそらくグローバルなプロバイダーが、ほとんどの展開から非常に遠く考えてください。したがって、ジオフィードデータが指定されている場合、ジオフィード：属性またはジオフィードの備考：属性：国：geoloc：、dns geoloc rrsetsなどのその他の地理的ヒントは、そのアドレス範囲を無視する必要があります。
There is open-source code to traverse the RPSL data across all of the RIRs, collect all geofeed references, and process them [GEOFEED-FINDER]. It implements the steps above and of all the Operational Considerations described in Section 6, including caching. It produces a single geofeed file, merging all the geofeed files found. This open-source code can be run daily by a cron job, and the output file can be directly used.
すべてのRIRでRPSLデータを通過し、すべてのジオフィード参照を収集し、それらを処理するためのオープンソースコードがあります[GeoFeed-Finder]。上記の手順と、キャッシュを含むセクション6で説明されているすべての運用上の考慮事項を実装します。1つのジオフィードファイルを生成し、見つかったすべてのジオフィードファイルをマージします。このオープンソースコードは、Cronジョブによって毎日実行でき、出力ファイルを直接使用できます。
RIRs are converging on Registration Data Access Protocol (RDAP) support, which includes geofeed data; see [RDAP-GEOFEED]. This SHOULD NOT be used for bulk retrieval of geofeed data.
RIRSは、ジオフィードデータを含む登録データアクセスプロトコル（RDAP）サポートに収束しています。[rdap-geofeed]を参照してください。これは、ジオフィードデータのバルク検索に使用しないでください。
The question arises whether a particular geofeed [RFC8805] data set is valid, i.e., is authorized by the "owner" of the IP address space and is authoritative in some sense. The inetnum: that points to the geofeed [RFC8805] file provides some assurance. Unfortunately, the RPSL in some repositories is weakly authenticated at best. An approach where the RPSL was signed per [RFC7909] would be good, except it would have to be deployed by all RPSL registries, and there is a fair number of them.
問題は、特定のGeofeed [RFC8805]データセットが有効であるかどうか、つまりIPアドレス空間の「所有者」によって承認され、何らかの意味で権威あるかどうかが生じます。inetnum：それは、Geofeed [RFC8805]ファイルを指します。残念ながら、一部のリポジトリのRPSLは、せいぜい弱く認証されています。[RFC7909]ごとにRPSLに署名されたアプローチは、すべてのRPSLレジストリによって展開する必要があり、かなりの数があります。
The remainder of this section specifies an optional authenticator for the geofeed data set that follows "Signed Object Template for the Resource Public Key Infrastructure (RPKI)" [RFC6488].
このセクションの残りの部分は、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」[RFC6488]に続くジオフィードデータセットのオプションの認証器を指定します。
A single optional authenticator MAY be appended to a geofeed [RFC8805] file. It is a digest of the main body of the file signed by the private key of the relevant RPKI certificate for a covering address range. The following format bundles the relevant RPKI certificate with a signature over the geofeed text.
単一のオプションの認証器は、GeoFeed [RFC8805]ファイルに追加される場合があります。これは、カバーアドレス範囲の関連するRPKI証明書の秘密鍵によって署名されたファイルの本体のダイジェストです。次の形式では、関連するRPKI証明書をGeoFeeedテキストに署名してバンドルします。
The canonicalization procedure converts the data from their internal character representation to the UTF-8 [RFC3629] character encoding, and the <CRLF> sequence MUST be used to denote the end of each line of text. A blank line is represented solely by the <CRLF> sequence. For robustness, any non-printable characters MUST NOT be changed by canonicalization. Trailing blank lines MUST NOT appear at the end of the file. That is, the file must not end with multiple consecutive <CRLF> sequences. Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be covered by the digital signature.
標準化手順は、データを内部文字表現からUTF-8 [RFC3629]文字エンコードに変換し、<CRLF>シーケンスを使用して、各テキスト行の終わりを示す必要があります。空白は、<CRLF>シーケンスのみで表されます。堅牢性のために、印刷不可能な文字を標準化によって変更してはなりません。後続の空白線は、ファイルの最後に表示されてはなりません。つまり、ファイルは複数の連続した<CRLF>シーケンスで終了してはなりません。オペレーティングシステムで使用されるファイル終了マーカーは、ファイルコンテンツの一部であるとは見なされません。存在する場合、そのようなファイルの終了マーカーをデジタル署名でカバーしてはなりません。
If the authenticator is not in the canonical form described above, then the authenticator is invalid.
認証機が上記の標準形式にない場合、認証器は無効です。
Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] is used to create a detached DER-encoded signature that is then Base64 encoded with padding (as defined in Section 4 of [RFC4648]) and line wrapped to 72 or fewer characters. The same digest algorithm MUST be used for calculating the message digest of the content being signed, which is the geofeed file, and for calculating the message digest on the SignerInfo SignedAttributes [RFC8933]. The message digest algorithm identifier MUST appear in both the CMS SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier [RFC5652]. The RPKI certificate covering the geofeed inetnum: object's address range is included in the CMS SignedData certificates field [RFC5652].
[RFC5485]からの剥離した署名をファイル標準化後、暗号化メッセージの構文（CMS）[RFC5652]を使用して、パディングでエンコードされた分離したderエンコード署名を作成するために使用されます（[RFC4688のセクション4で定義されているように））72文字以下にラインしたライン。同じダイジェストアルゴリズムを使用して、署名されているコンテンツのメッセージを計算するために使用する必要があります。これは、ジオフィードファイルである署名されたコンテンツのダイジェスト、およびSignerInfo SigneDattributes [RFC8933]でメッセージダイジェストを計算するために使用する必要があります。メッセージダイジェストアルゴリズム識別子は、CMS SignedData DigestalGorithMidentifiersとSignerinfo DigestalGorithMidentifier [RFC5652]の両方に表示する必要があります。Geofeed Inetnum：Objectのアドレス範囲をカバーするRPKI証明書は、CMS SignedData証明書フィールド[RFC5652]に含まれています。
The address range of the signing certificate MUST cover all prefixes in the signed geofeed file. If not, the authenticator is invalid.
署名証明書のアドレス範囲は、署名されたジオフィードファイルのすべてのプレフィックスをカバーする必要があります。そうでない場合、認証器は無効です。
The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]. If it is present, the authenticator is invalid.
署名証明書には、自律システム識別子委任証明書延長[RFC3779]を含めてはなりません。存在する場合、認証器は無効です。
As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the authenticator is invalid.
他の多くのRPKI署名されたオブジェクトと同様に、IPアドレス委任証明書拡張は、[RFC3779]のセクション2.2.3.5で定義されている「継承」機能を使用してはなりません。「継承」が使用されている場合、認証器は無効です。
An IP Address Delegation extension using "inherit" would complicate processing. The implementation would have to build the certification path from the end entity to the trust anchor, then validate the path from the trust anchor to the end entity, and then the parameter would have to be remembered when the validated public key was used to validate a signature on a CMS object. Having to remember things from certification path validation for use with CMS object processing would be quite complex and error-prone. Additionally, the certificates do not get that much bigger by repeating the information.
「継承」を使用したIPアドレス委任拡張機能は、処理を複雑にします。実装は、最終エンティティからトラストアンカーへの認証パスを構築し、トラストアンカーから最終エンティティへのパスを検証する必要があります。CMSオブジェクトの署名。CMSオブジェクト処理で使用するための認証パス検証から物事を覚えておくことは非常に複雑でエラーが発生しやすいでしょう。さらに、情報を繰り返しても証明書はそれほど大きくなりません。
An address range A "covers" address range B if the range of B is identical to or a subset of A. "Address range" is used here because inetnum: objects and RPKI certificates need not align on Classless Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those of the lines in a geofeed file do align.
bの範囲が同一であるか、Aのサブセットが同一である場合、アドレス範囲Aアドレス範囲b「アドレス範囲」がここで使用されている場合、inetnum：オブジェクトとRPKI証明書はクラスレスインタードメインルーティング（CIDR）に並べる必要はありません。[RFC4632]プレフィックス境界、一方、ジオフィードファイルの線の境界は整列します。
The Certification Authority (CA) SHOULD sign only one geofeed file with each generated private key and SHOULD generate a new key pair for each new version of a particular geofeed file. The CA MUST generate a new end entity (EE) certificate for each signing of a particular geofeed file. An associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).
認証機関（CA）は、生成された各秘密鍵で1つのジオフィードファイルのみに署名する必要があり、特定のGeoFeedファイルの新しいバージョンごとに新しいキーペアを生成する必要があります。CAは、特定のGeoFeedファイルの署名ごとに、新しいENDエンティティ（EE）証明書を生成する必要があります。この方法で使用される関連EE証明書は、「1回限りの」EE証明書と呼ばれます（[RFC6487]のセクション3を参照）。
Identifying the private key associated with the certificate and getting the department that controls the private key (which might be stored in a Hardware Security Module (HSM)) to generate the CMS signature is left as an exercise for the implementor. On the other hand, verifying the signature has no similar complexity; the certificate, which is validated in the public RPKI, contains the needed public key. The RPKI trust anchors for the RIRs are expected to already be available to the party performing signature validation. Validation of the CMS signature over the geofeed file involves:
証明書に関連付けられた秘密鍵を特定し、秘密鍵（ハードウェアセキュリティモジュール（HSM）に保存される可能性がある）を制御する部門を取得してCMS署名を生成することは、実装者の演習として残されます。一方、署名を検証するには、同様の複雑さがありません。公開RPKIで検証されている証明書には、必要な公開キーが含まれています。RPKIトラストアンカーのRIRSは、署名検証を行うパーティーがすでに利用できると予想されています。GeoFeedファイルを介したCMS署名の検証には、以下が含まれます。
1. Obtaining the signer's certificate from the CMS SignedData CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652]. If the key identifiers do not match, then validation MUST fail.
1. CMS SignedData証明書[RFC5652]から署名者の証明書を取得します。証明書件名KeyDeyIdentifier拡張機能[RFC5280]は、CMS SignerInfo Signeridentifier [RFC5652]の件名KeyIdentifierと一致する必要があります。キー識別子が一致しない場合、検証が失敗する必要があります。
2. Validating the signer's certificate MUST ensure that it is part of the current [RFC9286] manifest and that all resources are covered by the RPKI certificate.
2. 署名者の証明書の検証は、現在の[RFC9286]マニフェストの一部であり、すべてのリソースがRPKI証明書でカバーされていることを確認する必要があります。
3. Constructing the certification path for the signer's certificate. All of the needed certificates are expected to be readily available in the RPKI repository. The certification path MUST be valid according to the validation algorithm in [RFC5280] and the additional checks specified in [RFC3779] associated with the IP Address Delegation certificate extension and the Autonomous System Identifier Delegation certificate extension. If certification path validation is unsuccessful, then validation MUST fail.
3. 署名者の証明書の認証パスの構築。必要な証明書はすべて、RPKIリポジトリで容易に利用できると予想されます。認証パスは、[RFC5280]の検証アルゴリズムと、IPアドレス委任証明書拡張および自律システム識別子委任証明書拡張に関連する[RFC3779]で指定された追加のチェックに従って有効でなければなりません。認証パスの検証が失敗した場合、検証に失敗する必要があります。
4. Validating the CMS SignedData as specified in [RFC5652] using the public key from the validated signer's certificate. If the signature validation is unsuccessful, then validation MUST fail.
4. 検証済みの署名者の証明書から公開キーを使用して、[RFC5652]で指定されているCMS SignedDataを検証します。署名検証が失敗した場合、検証が失敗する必要があります。
5. Confirming that the eContentType object identifier (OID) is id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This OID MUST appear within both the eContentType in the encapContentInfo object and within the ContentType signed attribute in the signerInfo object (see [RFC6488]).
5. econtentTypeオブジェクト識別子（OID）がID-CT-GEOFEEDCSVWITHCRLF（1.2.840.113549.1.9.16.1.47）であることを確認します。このoidは、encapcontentinfoオブジェクトのecontentTypeと、signerinfoオブジェクトのcontentType符号付き属性の両方に表示する必要があります（[rfc6488]を参照）。
6. Verifying that the IP Address Delegation certificate extension [RFC3779] covers all of the address ranges of the geofeed file. If all of the address ranges are not covered, then validation MUST fail.
6. IPアドレス代表団の証明書拡張[RFC3779]がGeoFeedファイルのすべてのアドレス範囲をカバーすることを確認します。すべてのアドレス範囲がカバーされていない場合、検証に失敗する必要があります。
All of the above steps MUST be successful to consider the geofeed file signature as valid.
上記のすべての手順は、GeoFeedファイルの署名を有効と見なすために成功する必要があります。
The authenticator MUST be hidden as a series of "#" comments at the end of the geofeed file. The following simple example is cryptographically incorrect:
Authenticatorは、GeoFeedファイルの最後にある一連の「＃」コメントとして非表示にする必要があります。次の簡単な例は、暗号化的に間違っています。
# 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 correct and full example is in Appendix A.
正確で完全な例は、付録Aにあります。
The CMS signature does not cover the signature lines.
CMSの署名は、署名行をカバーしません。
The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present as shown in the example. The RPKI Signature's IP address range MUST match that of the geofeed URL in the inetnum: that points to the geofeed file.
ブラケット "＃rpki signature：" and "＃end signature："は、例に示すように存在する必要があります。RPKI署名のIPアドレス範囲は、GeoFeedファイルを指すINETNUMのGeoFeeed URLの範囲と一致する必要があります。
To create the needed inetnum: objects, an operator wishing to register the location of their geofeed file needs to coordinate with their Regional Internet Registry (RIR) or National Internet Registry (NIR) and/or any provider Local Internet Registry (LIR) that has assigned address ranges to them. RIRs/NIRs provide means for assignees to create and maintain inetnum: objects. They also provide means of assigning or sub-assigning IP address resources and allowing the assignee to create WHOIS data, including inetnum: objects, thereby referring to geofeed files.
必要なinetnum：オブジェクトを作成するには、ジオフィードファイルの場所を登録したいオペレーターであるオペレーターは、地域のインターネットレジストリ（RIR）またはナショナルインターネットレジストリ（NIR）、および/またはプロバイダーのローカルインターネットレジストリ（LIR）と調整する必要があります。割り当てられたアドレスの範囲はそれらに範囲です。RIRS/NIRSは、譲受人がinetnum：オブジェクトを作成および維持する手段を提供します。また、IPアドレスリソースの割り当てまたはサブアサインの手段を提供し、譲受人がinetnum：オブジェクトを含むWHOISデータを作成できるようにし、それによってジオフィードファイルを参照します。
The geofeed files MUST be published via and fetched using HTTPS [RFC9110].
GeoFeedファイルは、HTTPS [RFC9110]を使用して公開し、フェッチする必要があります。
When using data from a geofeed file, one MUST ignore data outside the referring inetnum: object's inetnum: attribute address range.
GeoFeedファイルからデータを使用する場合、参照Inetnum：Object's Inetnum：属性アドレス範囲の外側のデータを無視する必要があります。
If and only if the geofeed file is not signed per Section 5, then multiple inetnum: objects MAY refer to the same geofeed file, and the consumer MUST use only lines in the geofeed file where the prefix is covered by the address range of the inetnum: object's URL it has followed.
GeoFeedファイルがセクション5に従って署名されていない場合にのみ、複数のINETNUM：オブジェクトは同じGeoFeedファイルを参照し、消費者はプレフィックスがINETNUMのアドレス範囲でカバーされているジオフィードファイルのラインのみを使用する必要があります。：Object's URLそれに続いています。
If the geofeed file is signed, and the signer's certificate changes, the signature in the geofeed file MUST be updated.
GeoFeedファイルが署名され、署名者の証明書が変更された場合、GeoFeedファイルの署名を更新する必要があります。
It is good key hygiene to use a given key for only one purpose. To dedicate a signing private key for signing a geofeed file, an RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for the purpose shown in Appendix A.
特定のキーを1つの目的のみで使用することは、良いキー衛生です。Geofeedファイルに署名するための署名秘密鍵を捧げるために、RPKI認証局（CA）は、付録Aに示す目的のみを考慮して下位証明書を発行することができます。
Harvesting and publishing aggregated geofeed data outside of the RPSL model should be avoided as it could lead to detailed data of one aggregatee undesirably affecting the less detailed data of a different aggregatee. Moreover, publishing aggregated geofeed data prevents the reader of the data from performing the checks described in Sections 4 and 5.
RPSLモデルの外側の収穫と公開のジオフィードデータは、異なる骨材の詳細なデータに望ましくない1つの集合体の詳細なデータにつながる可能性があるため、避ける必要があります。さらに、集約されたジオフィードデータを公開すると、データの読者がセクション4および5で説明されているチェックの実行を防ぎます。
At the time of publishing this document, geolocation providers have bulk WHOIS data access at all the RIRs. An anonymized version of such data is openly available for all RIRs except ARIN, which requires an authorization. However, for users without such authorization, the same result can be achieved with extra RDAP effort. There is open-source code to pass over such data across all RIRs, collect all geofeed references, and process them [GEOFEED-FINDER].
このドキュメントを公開している時点で、Geolocation ProvidersにはすべてのRIRSでデータアクセスがかなりあります。そのようなデータの匿名バージョンは、ARINを除くすべてのRIRが公然と利用できます。これには、承認が必要です。ただし、そのような承認のないユーザーの場合、追加のRDAPの取り組みで同じ結果を達成できます。すべてのRIRにそのようなデータを渡すオープンソースコードがあり、すべてのジオフィード参照を収集し、それらを処理します[GeoFeed-Finder]。
To prevent undue load on RPSL and geofeed servers, entity-fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups. Section 3.4 of [RFC8805] suggests use of the HTTP Expires header [RFC9111] to signal when geofeed data should be refetched. As the data change very infrequently, in the absence of such an HTTP Header signal, collectors SHOULD NOT fetch more frequently than weekly. It would be polite not to fetch at magic times such as midnight UTC, the first of the month, etc., because too many others are likely to do the same.
RPSLおよびGeoFeedサーバーの過度の負荷を防ぐために、これらのメカニズムを使用してエンティティを拡張するジオフィードデータを頻繁にリアルタイムで検索することはできません。[RFC8805]のセクション3.4は、GeoFeedデータを再排除する必要がある場合に、HTTPの有効期限がヘッダー[RFC9111]を使用することを示唆しています。データが非常にまれに変化するにつれて、このようなHTTPヘッダー信号がない場合、コレクターは毎週よりも頻繁に取得するべきではありません。Midnight UTC、最初の月などの魔法の時代にフェッチしないことは礼儀正しいでしょう。
[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document, the operator should be aware of this exposure in geofeed data and be cautious. All the privacy considerations of Section 4 of [RFC8805] apply to this document.
[RFC8805] Geofeedデータは、IPアドレスのおおよその場所を明らかにする可能性があり、個々のユーザーのおおよその場所が明らかになる可能性があります。残念ながら、[RFC8805]は、このユーザーの露出による可能性のある損害を回避または改善することに関するプライバシーガイダンスを提供しません。このドキュメントで説明されているように、ジオフィードファイルへのポインターを公開する際に、オペレーターはジオフィードデータでのこの露出を認識し、注意する必要があります。[RFC8805]のセクション4のプライバシーに関するすべての考慮事項は、このドキュメントに適用されます。
Where [RFC8805] provided the ability to publish location data, this document makes bulk access to those data readily available. This is a goal, not an accident.
[RFC8805]がロケーションデータを公開する機能を提供する場合、このドキュメントにより、これらのデータに大量にアクセスできるようになります。これは目標であり、事故ではありません。
At the time of publishing this document, the geofeed: attribute in inetnum objects has been implemented in the RIPE and APNIC databases.
このドキュメントの公開時点では、GeoFeed：Inetnumオブジェクトの属性は、RipeおよびApnicデータベースに実装されています。
Registrants in databases that do not yet support the geofeed: attribute are using the remarks: attribute, or equivalent.
まだGeoFeeedをサポートしていないデータベースの登録：属性は、属性、または同等の備考を使用しています。
At the time of publishing this document, the registry data published by ARIN are not the same RPSL as that of the other registries (see [RFC7485] for a survey of the WHOIS Tower of Babel). Therefore, when fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the RDAP [RFC9082], etc., the "NetRange" attribute/key must be treated as "inetnum", and the "Comment" attribute must be treated as "remarks".
このドキュメントの公開時点では、ARINによって公開されたレジストリデータは、他のレジストリのRPSLと同じではありません（Whois Tower of Babelの調査については[RFC7485]を参照）。したがって、FTP [RFC0959]、WHOIS [RFC3912]、RDAP [RFC9082]などを介してアリンからフェッチする場合、「netrange」属性/キーは「inetnum」として扱わなければなりません。「発言」として。
[rpki-client] can be used to authenticate a signed geofeed file.
[RPKI-Client]を使用して、署名されたジオフィードファイルを認証できます。
It is generally prudent for a consumer of geofeed data to also use other sources to cross-validate the data. All the security considerations of [RFC8805] apply here as well.
一般に、Geofeedデータの消費者が他のソースを使用してデータを通過することも賢明です。[RFC8805]のすべてのセキュリティに関する考慮事項もここにも適用されます。
The consumer of geofeed data SHOULD fetch and process the data themselves. Importing data sets produced and/or processed by a third-party places significant trust in the third-party.
Geofeedデータの消費者は、データ自体を取得して処理する必要があります。サードパーティによって生成および/または処理されたデータセットのインポートは、サードパーティに大きな信頼をもたらします。
As mentioned in Section 5, some RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious geofeed files. Section 5 suggests an unfortunately complex method for stronger authentication based on the RPKI.
セクション5で述べたように、一部のRPSLリポジトリは、認証があったとしても弱いです。これにより、inetnum：悪意のあるジオフィードファイルを指すオブジェクトのスプーフィングが可能になります。セクション5では、RPKIに基づいたより強力な認証のための残念な複雑な方法を示唆しています。
For example, if an inetnum: for a wide address range (e.g., a /16) points to an RPKI-signed geofeed file, a customer or attacker could publish an unsigned equal or narrower (e.g., a /24) inetnum: in a WHOIS registry that has weak authorization, abusing the rule that the most-specific inetnum: object with a geofeed reference MUST be used.
たとえば、inetnum：広いアドレス範囲（a /16）の場合、RPKIに署名したジオフィードファイルを指している場合、顧客または攻撃者は、符号なしの平等または狭い（例えば、a /24）inetnumを公開できます。承認が弱いWHOISレジストリは、最も固有のINETNUM：GeOfeed参照を持つオブジェクトを使用する必要があるというルールを乱用します。
If signatures were mandatory, the above attack would be stymied, but of course that is not happening anytime soon.
署名が必須であれば、上記の攻撃は阻害されますが、もちろんそれはすぐに起こっていません。
The RPSL providers have had to throttle fetching from their servers due to too-frequent queries. Usually, they throttle by the querying IP address or block. Similar defenses will likely need to be deployed by geofeed file servers.
RPSLプロバイダーは、あまりにも頻繁なクエリのためにサーバーからフェッチする必要がありました。通常、彼らはクエリのIPアドレスまたはブロックによってスロットルします。同様の防御は、GeoFeedファイルサーバーによって展開する必要がある可能性があります。
In the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group (located at <https://www.iana.org/assignments/smi-numbers/>), the reference for this registration has been updated to this document:
S/MIME CMSコンテンツタイプ（1.2.840.113549.1.9.16.1）のSMIセキュリティでは、管理情報の構造（SMI）番号（MIBモジュール登録）レジストリグループ（<https://www.iana.orgにあります。/assignments/smi-numbers/>）、この登録のリファレンスはこのドキュメントに更新されました。
+=========+==========================+===========+
| Decimal | Description | Reference |
+=========+==========================+===========+
| 47 | id-ct-geofeedCSVwithCRLF | RFC 9632 |
+---------+--------------------------+-----------+
Table 1: From SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.1)
表1：S/MIMEモジュール識別子のSMIセキュリティから（1.2.840.113549.1.9.16.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>.
[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>.
This appendix provides an example, including a trust anchor, a Certificate Revocation List (CRL) signed by the trust anchor, a CA certificate subordinate to the trust anchor, a CRL signed by the CA, an end entity certificate subordinate to the CA for signing the geofeed, and a detached signature.
この付録には、トラストアンカー、トラストアンカーが署名した証明書取消リスト（CRL）、信託アンカーに従属するCA証明書、CAが署名したCRL、署名のためにCAに従属するENDエンティティ証明書などの例を提供します。ジオフィード、および分離された署名。
The trust anchor is represented by a self-signed certificate. As usual in the RPKI, the trust anchor has authority over all IPv4 address blocks, all IPv6 address blocks, and all Autonomous System (AS) numbers.
トラストアンカーは、自己署名証明書で表されます。RPKIの通常のように、Trust Anchorはすべての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-----
The CRL is issued by the trust anchor.
CRLはTrust Anchorによって発行されます。
-----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-----
The CA certificate is issued by the trust anchor. This certificate grants authority over one IPv4 address block (192.0.2.0/24) and two AS numbers (64496 and 64497).
CA証明書は、Trust Anchorによって発行されます。この証明書は、1つのIPv4アドレスブロック（192.0.2.0/24）と2つのAs Numbers（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-----
The CRL is issued by the CA.
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-----
The end entity certificate is issued by the CA. This certificate grants signature authority for one IPv4 address block (192.0.2.0/24). Signature authority for AS numbers is not needed for geofeed data signatures, so no AS numbers are included in the end entity certificate.
End Entity証明書はCAによって発行されます。この証明書は、1つのIPv4アドレスブロック（192.0.2.0/24）に署名機関を付与します。Geofeedデータ署名には数字の署名権が必要ではないため、End Entity証明書に数字が含まれていないため。
-----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-----
The end entity certificate is displayed below in detail. For brevity, the other two certificates are not.
End Entity証明書を詳細に以下に表示します。簡潔にするために、他の2つの証明書はそうではありません。
0 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
: }
To allow reproduction of the signature results, the end entity private key is provided. For brevity, the other two private keys are not.
署名結果の再現を可能にするために、End Entityの秘密キーが提供されます。簡潔にするために、他の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-----
The signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF) yields the following detached CMS signature.
「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
Thanks to Rob Austein for the CMS and detached signature clue, George Michaelson for the first and substantial external review, and Erik Kline who was too shy to agree to coauthorship. Additionally, we express our gratitude to early implementors, including Menno Schepers, Flavio Luciani, Eric Dugas, and Kevin Pack. Also, thanks to the following geolocation providers who are consuming geofeeds with this described solution: Jonathan Kosgei (ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat (bigdatacloud.com). For an amazing number of helpful reviews, we thank Job Snijders, who also found an ASN.1 'inherit' issue, Adrian Farrel, Antonio Prado, Francesca Palombini, Jean-Michel Combes (INTDIR), John Scudder, Kyle Rose (SECDIR), Martin Duke, Mohamed Boucadair, Murray Kucherawy, Paul Kyzivat (GENART), Rob Wilton, Roman Danyliw, and Ties de Kock.
CMSと独立したシグネチャーの手がかり、最初の実質的な外部レビューについてはジョージマイケルソン、そして共著者に同意するには恥ずかしすぎるエリッククラインに感謝します。さらに、Menno Schepers、Flavio Luciani、Eric Dugas、Kevin Packなど、初期の実施者に感謝します。また、この説明されたソリューションでジオフィードを消費している次のジオロケーションプロバイダーのおかげで、Jonathan Kosgei（IPDATA.CO）、Ben Dowling（IPINFO.IO）、およびPOL NisenBlat（BigDatacloud.com）。驚くべき数の有益なレビューについては、ASN.1の「継承」問題、エイドリアンファレル、アントニオプラド、フランチェスカパロビニ、ジャンミシェルコーム（intdir）、ジョンスカダー、カイルローズ（Secdir）を見つけたJob Snijdersに感謝します。、Martin Duke、Mohamed Boucadair、Murray Kuchherawy、Paul Kyzivat（Genart）、Rob Wilton、Roman Danyliw、Ties de Kock。
Randy Bush
IIJ Research & Arrcus
5147 Crystal Springs
Bainbridge Island, Washington 98110
United States of America
Email: randy@psg.com
Massimo Candela
NTT
Veemweg 23
3771 MT Barneveld
Netherlands
Email: massimo@ntt.net
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
United States of America
Email: housley@vigilsec.com