RFC 9092 - Finding and Using Geofeed Data 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9092.html
タイトル : RFC 9092 - GeoFeedデータの検索と使用
翻訳編集 : 自動生成

[要約] RFC 9092は、地理的なフィードデータ（Geofeedデータ）を見つけて使用する方法に関する規格です。この文書の目的は、インターネットリソースの地理的な位置情報を提供するための標準的なフォーマットとプロトコルを定義することです。利用場面としては、IPアドレスの地理的位置情報を特定する際、ネットワーク管理、およびコンテンツ配信の最適化などがあります。

Internet Engineering Task Force (IETF)                           R. Bush
Request for Comments: 9092                                  IIJ & Arrcus
Category: Standards Track                                     M. Candela
ISSN: 2070-1721                                                      NTT
                                                               W. Kumari
                                                                  Google
                                                              R. Housley
                                                          Vigil Security
                                                               July 2021

Finding and Using Geofeed Data

GeoFeedデータの検索と使用

Abstract

概要

This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.

このドキュメントは、GeoFeedデータのコンマ区切り値（CSV）ファイルを参照するために、ルーティングポリシーの指定言語INETNUM：クラスを調整する方法を指定し、ルーティング公開鍵インフラストラクチャを使用してGeoFeedデータCSVファイルを認証するオプションのスキームを説明します。

Status of This Memo

本文書の位置付け

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/rfc9092.

この文書の現在の状況、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9092で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Geofeed Files
   3.  inetnum: Class
   4.  Authenticating Geofeed Data
   5.  Operational Considerations
   6.  Privacy Considerations
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Example
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

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. Also, 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アドレスを使用して行われることがよくあります。また、インフラストラクチャやその他のサービスは、サービスのロケールを公開したいと思うかもしれません。[RFC8805]地理的ロケールをIPアドレスに関連付けるためのGeoFeed、構文であることを定義しますが、IPアドレスが与えられた関連するGeoFeedデータを見つける方法は指定されません。

This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC2725] inetnum: class to refer specifically to geofeed data CSV files and how to prudently use them. In all places inetnum: is used, inet6num: should also be assumed [RFC4012].

このドキュメントは、ルーティングポリシーの指定言語（RFC2725] INETNUM：クラスを拡張する方法を指定します.GeoFeed Data CSVファイルと慎重に使用する方法を参照してください。すべての場所でInetnum：inet6num：inet6num：も想定されるべきです[RFC4012]。

The reader may find [INETNUM] and [INET6NUM] informative, and certainly more verbose, descriptions of the inetnum: database classes.

リーダーは[inetnum]と[inet6num]に有益であり、確かに冗長で、inetnum：データベースクラスの説明を見つけることができます。

An optional utterly awesome but slightly complex means for authenticating geofeed data is also defined.

Geofeedデータを認証するためのオプションではなく、わずかに複雑な手段も定義されています。

1.1. Requirements Language

1.1. 要件言語

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.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. Geofeed Files

2. ジオフィードファイル

Geofeed files are described in [RFC8805]. They provide a facility for an IP address resource "owner" to associate those IP addresses to geographic locales.

GeoFeedファイルは[RFC8805]に記載されています。これらのIPアドレスを地理的ロケールに関連付けるには、IPアドレスリソース「所有者」の機能を提供します。

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アドレスを地理的なロケールに見つけたいコンテンツプロバイダーやその他の当事者は、関連するGeoFeedデータを見つける必要があります。第3章では、このドキュメントは、IPアドレスを指定して、関連するGeoFeed [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.

著しい水平規模と高い粒度を持つ大規模プロバイダーのためのGeofeedデータはかなり大きくなる可能性があります。unsigned Geofeedファイルが多数のプレフィックスのデータを組み合わせた場合、ファイルのサイズはさらに大きくなります。デュアルIPv4 / IPv6スペースが表現されている場合など

Geofeed data do have privacy considerations (see Section 6); this process makes bulk access to those data easier.

GeoFeedデータにはプライバシーの考慮事項があります（セクション6を参照）。このプロセスにより、それらのデータへのバルクアクセスが簡単になります。

This document also suggests an optional signature to strongly authenticate the data in the geofeed files.

このドキュメントはまた、GeoFeedファイル内のデータを強く認証するためのオプションの署名も示唆しています。

3. inetnum: Class

3. inetnum：クラスの

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]. Currently, change control effectively lies in the operator community.

[RIPE81]、[RIPE181]で始まる元のRPSL仕様と、後続の文書の跡は熟したコミュニティによって書かれました。[RFC2622]および[RFC4012]のIETF標準化RPSL。それ以来、それ以来、地域インターネットレジストリ（RIR）コミュニティでは、ほとんど熟した[RIPE-DB]によって修正および広範囲に強化されています。現在、変更管理は事業者コミュニティに効果的にあります。

The RPSL, and [RFC2725] and [RFC4012] used by the Regional Internet Registries (RIRs), specify the inetnum: database class. Each of these objects describes an IP address range and its attributes. The inetnum: objects form a hierarchy ordered on the address space.

RSL、[RFC2725]と[RFC4012]と[RFC4012]が、inetnum：データベース・クラスを指定します。これらの各オブジェクトは、IPアドレス範囲とその属性を説明しています。inetnum：オブジェクトはアドレス空間に順序付けられた階層を形成します。

Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, 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は、inetnum：クラスの新しいRPSL GeoFeed：属性を定義するために拡張されます。このような時間まで、このドキュメントはGeofeed lements：属性の構文を定義します。これには、GeoFeedファイルのHTTPS URLが含まれています。inetnumの形式：geofeed備考：属性は、この例のように、 "備考：geofeed"、トークン "geofeed"が大文字と小文字を区別しなければならず、その後に異なるURLが続く必要がありますが、単一のものだけを参照する必要があります。GeoFeed [RFC8805]ファイル。

       inetnum: 192.0.2.0/24 # example
       remarks: Geofeed https://example.com/geofeed.csv

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：クラスの適切なGeoFeed：属性が "Geofeed："でなければならず、その後に異なる単一のURLを続ける必要がありますが、それだけに参照する必要があります。単一のGeoFeed [RFC8805]ファイル。

       inetnum: 192.0.2.0/24 # example
       geofeed: https://example.com/geofeed.csv

Registries MAY, for the interim, provide a mix of the remarks: attribute form and the geofeed: attribute form.

暫定的に、暫定のために、remofts：属性フォームとGeofeed：属性フォームの組み合わせを提供することがあります。

The URL uses HTTPS, so the WebPKI provides authentication, integrity, and confidentiality for the fetched geofeed file. However, the WebPKI can not 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 4.

URLはHTTPSを使用するため、WebPKIはフェッチされたGEOFEEDファイルの認証、整合性、および機密性を提供します。ただし、WebPKIはIPアドレススペース割り当ての認証を提供できません。対照的に、RPKI（[RFC6481]参照）を使用してIPスペース割り当てを認証できます。セクション4のオプション認証を参照してください。

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. 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.

inetnumのすべてのプロデューサー：つまり、inetnumを探している消費者のオブジェクト、すなわち、inetnumを探している消費者：jafeed URLを見つけるためにオブジェクトは、次の備考とGeoFeed：Formsの両方を消費することができなければなりません。移行は、RIRSがGeoFeed：属性をサポートすることを意味するだけでなく、すべての登録者はinetnum：exolubeからのオブジェクトをelemplics：属性：属性に移行したことを意味します。

Any particular inetnum: object MUST have, at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute when it is implemented. If there is more than one, all are ignored.

任意の特定のinetnum：オブジェクトは、備考：または適切なGeoFeed：属性が実装されたときに、1つのGeofeed参照を持つ必要があります。複数の場合は、すべて無視されます。

If a geofeed CSV 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 4.

GeoFeed CSVファイルでは、複数の互いに素なIPアドレス・スペースが記述されている場合、複数のInetnum：オブジェクトからGeoFeed参照がある可能性があります。複数のinetnumからのGeoFeed参照を持つファイル：オブジェクトはセクション4の署名手順と互換性がありません。

When geofeed references are provided by multiple inetnum: objects that have identical address ranges, then the geofeed reference on the inetnum: with the most recent last-modified: attribute SHOULD be preferred.

GeoFeed参照が複数のinetnum：同一のアドレス範囲を持つオブジェクトによって提供されている場合、inetnum上のGeoFeed参照：最新の最後の変更：属性が推奨されるはずです。

As inetnum: objects form a hierarchy, geofeed references SHOULD be at the lowest applicable inetnum: object covering the relevant address ranges in the referenced geofeed file. When fetching, the most specific inetnum: object with a geofeed reference MUST be used.

inetnum：オブジェクトが階層を形成するように、Geofeedの参照は該当するinetnum：参照されているGeoFeedファイル内の関連アドレス範囲をカバーするオブジェクトにあるべきです。フェッチすると、GeoFeed参照を持つオブジェクトを使用する必要があります。

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.

GeoFeedデータがinetnumよりも細かい粒度を有し得ることは重要です。例えば、アドレス範囲Pに対するinetnumオブジェクトは、Pが1つ以上のより長い接頭辞に細分されたGeoFeedファイルを指すことができる。

Currently, 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 Registration Data Access Protocol (RDAP) [RFC9082], etc., the "NetRange" attribute/key MUST be treated as "inetnum", and the "Comment" attribute MUST be treated as "remarks".

現在、Arinによって公開されたレジストリデータは、他のレジストリのレジストリと同じRPSLではありません（Babelのwhois塔の調査については、[RFC7485]を参照）。したがって、FTP [RFC0959]、登録データアクセスプロトコル（RFC9082]など、Arinからフェッチすると、「NetRange」属性/ keyは "inetnum"として扱われなければなりません。コメント "属性"備考 "として扱われる必要があります。

4. Authenticating Geofeed Data

4. 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 many repositories is weakly authenticated at best. An approach where 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は最善で認証されています。RPC7909は、RFC7909ごとにRPSLが署名されたアプローチは、すべてのRPSLレジストリによって展開されなければならず、それらの公正な番号があります。

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. One needs a format that bundles the relevant RPKI certificate with the signature of the geofeed text.

1つのオプションのオーセンティケータがGeoFeed [RFC8805]ファイルに追加されることがあります。カバーアドレス範囲については、関連するRPKI証明書の秘密鍵によって署名されたファイルの本体のダイジェストです。関連するRPKI証明書をGeoFeedテキストの署名とバンドルする形式が必要です。

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 a 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 processed by the digital signature algorithm.

正規化手順は、データを内部文字表現からUTF-8 [RFC3629]文字符号化に変換し、<CRLF>シーケンスを使用してテキスト行の終わりを表す必要があります。空白行は<CRLF>シーケンスだけで表されます。堅牢性のために、正規化されていない文字は、正規化によって変更されてはいけません。末尾の空白行はファイルの末尾に表示されないでください。つまり、ファイルは複数の連続した<CRLF>シーケンスで終わらないでください。オペレーティングシステムで使用されているファイルの終わりマーカーは、ファイル内容の一部とは見なされません。存在する場合、そのようなファイルの終わりマーカーはデジタル署名アルゴリズムによって処理されてはならない。

Should the authenticator be syntactically incorrect per the above, the authenticator is invalid.

オーセンティケータが上記のもので構文的に正しくない場合は、オーセンティケータが無効です。

Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] would be used to create a detached DER-encoded signature that is then padded BASE64 encoded (as per Section 4 of [RFC4648]) and line wrapped to 72 or fewer characters. The same digest algorithm MUST be used for calculating the message digest on 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 SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier [RFC5652].

[RFC5485]の[RFC5485]からの[RFC5485]からの[RFC5485]から、暗号化メッセージ構文（CMS）[RFC5652]は、符号化されたパディングされたDER符号化シグニチャを作成するために使用され、（RFC4648のセクション4に従って）。72文字以下にラップされた行。ジェオフィードファイルであるコンテンツのメッセージダイジェストを計算するために同じダイジェストアルゴリズムを使用する必要があります。これは、GEOFEEDファイルであり、SignerInfo SignedAttributes [RFC8933]でメッセージダイジェストを計算します。メッセージダイジェストアルゴリズムIDは、SignedData DigestalGorithmIdentifiersとSignerInfo DigestalGorithmIdentifier [RFC5652]の両方に表示されている必要があります。

The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs.

署名証明書のアドレス範囲は、それが署名するGeofeedファイル内のすべてのプレフィックスをカバーする必要があります。

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 CSV lines in a geofeed file do.

アドレス範囲Aの範囲が同じまたはAの範囲が同一である場合、またはAアドレス範囲がある場合は、Inetnum：オブジェクトおよびRPKI証明書がクラスレス間ドメインルーティング（CIDR）に整列する必要がないため、ここで使用されるアドレス範囲Bが使用されます。[RFC4632] GeoFeedファイル内のCSV行のものは境界を接頭辞境界を付けます。

As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field.

署名者が署名に関連するカバーされたRPKIリソースを指定すると、inetnum：オブジェクトのアドレス範囲を網羅するRPKI証明書が[RFC5652] CMS SignedData証明書フィールドに含まれています。

Identifying the private key associated with the certificate and getting the department that controls the private key (which might be trapped in a Hardware Security Module (HSM)) to sign the CMS blob is left as an exercise for the implementor. On the other hand, verifying the signature requires no complexity; the certificate, which can be validated in the public RPKI, has the needed public key. The trust anchors for the RIRs are expected to already be available to the party performing signature validation. Validation of the CMS signature on the geofeed file involves:

証明書に関連付けられた秘密鍵を識別し、CMS BLOBに署名するための秘密鍵（HSM）に閉じ込められている可能性がある）を制御する部門の取得は、実装者の演習として残されています。一方、署名の検証は複雑さを必要としません。公開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]から署名者の証明書を入手する。Certificate SubjectKeyIdentifier拡張子[RFC5280]は、CMS SignerInfo SignerIdentifier [RFC5652]のSubjectKeyIdentifierと一致する必要があります。キー識別子が一致しない場合、検証は失敗する必要があります。

Validation of the signer's certificate MUST ensure that it is part of the current [RFC6486] manifest and that the resources are covered by the RPKI certificate.

署名者の証明書の検証は、現在の[RFC6486]マニフェストの一部であり、リソースがRPKI証明書でカバーされていることを確認する必要があります。

2. 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.

2. 署名者の証明書の認証パスを構築する。必要な証明書はすべてRPKIリポジトリですぐに入手可能であると予想されます。認証パスは、[RFC5280]の検証アルゴリズムとIPアドレス委任証明書拡張機能と自律システム識別子委任証明書拡張に関連付けられている[RFC3779]で指定された追加チェックに従って有効でなければなりません。認証パス検証が失敗した場合、検証は失敗する必要があります。

3. 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.

3. 有効な署名者の証明書から公開鍵を使用して[RFC5652]で指定されているCMS SignedDataを検証します。署名検証が失敗した場合、検証は失敗する必要があります。

4. 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.

4. IPアドレス委任証明書の拡張子[RFC3779]がGeoFeedファイルのすべてのアドレス範囲をカバーすることを確認します。すべてのアドレス範囲がカバーされていない場合、検証は失敗する必要があります。

All of these steps MUST be successful to consider the geofeed file signature as valid.

Geofeedファイルの署名を有効で考慮して、これらの手順をすべて成功させる必要があります。

As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate covering the inetnum: object's address range is included in the CMS SignedData certificates field [RFC5652].

署名者が署名に関連するカバーされたRPKIリソースを指定すると、inetnum：オブジェクトのアドレス範囲をカバーするRPKI証明書はCMS SignedData証明書フィールド[RFC5652]に含まれています。

Identifying the private key associated with the certificate and getting the department with the Hardware Security Module (HSM) to sign the CMS blob is left as an exercise for the implementor. On the other hand, verifying the signature requires no complexity; the certificate, which can be validated in the public RPKI, has the needed public key.

証明書に関連付けられた秘密鍵を識別し、CMS BLOBに署名するためのハードウェアセキュリティモジュール（HSM）を使用して部門を取得することは、実装者の演習として残されています。一方、署名の検証は複雑さを必要としません。公開RPKIで検証できる証明書には、必要な公開鍵があります。

The appendix MUST be hidden as a series of "#" comments at the end of the geofeed file. The following is a cryptographically incorrect, albeit simple, example. A correct and full example is in Appendix A.

付録は、GeoFeedファイルの最後にあるシリーズの "＃"コメントとして非表示にする必要があります。以下は、シンプルな例ですが、暗号的に正しくありません。正しい完全な例は付録Aにあります。

       # 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

The signature does not cover the signature lines.

署名は署名回線を覆っていません。

The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present following the model as shown. Their IP address range MUST match that of the inetnum: URL followed to the file.

表示されているように、モデルに従って括弧内の「＃rpki signature：」と「＃end signature：」が存在している必要があります。それらのIPアドレス範囲は、inetnum：URLの後にファイルにそれと一致する必要があります。

[RPKI-RSC] describes and provides code for a CMS profile for a general purpose listing of checksums (a "checklist") for use with the Resource Public Key Infrastructure (RPKI). It provides usable, albeit complex, code to sign geofeed files.

[RPKI-RSC]は、リソース公開鍵インフラストラクチャ（RPKI）で使用するためのCMSプロファイル（「チェックリスト」）のCMSプロファイルのコードを説明して提供します。Geofeedファイルに署名するためのコード、複合コード、コードを提供します。

[RPKI-RTA] describes a CMS profile for a general purpose Resource Tagged Attestation (RTA) based on the RPKI. While this is expected to become applicable in the long run, for the purposes of this document, a self-signed root trust anchor is used.

[RPKI-RTA] RPKIに基づく汎用リソースタグ付き検証（RTA）のCMSプロファイルを説明しています。この文書の目的のために、これは長期的に適用可能になると予想されていますが、自己署名されたルート信頼アンカーが使用されます。

5. Operational Considerations

5. 運用上の考慮事項

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：オブジェクトを作成するには、GeoFeedファイルの場所を登録したいオペレーターが、リージョナルインターネットレジストリ（RIR）またはNational Internet Registry（NIR）および/または使用するプロバイダーローカルインターネットレジストリ（LIR）と調整する必要があります。割り当てられたアドレスはそれらに範囲です。RIRS / NIRSは、inetnum：オブジェクトを作成および維持するための担当者のための手段を提供します。また、IPアドレスリソースを割り当てたり、サブアサイトしたり、inetnum：オブジェクトを含むWhoISデータを作成してGeoFeedファイルを参照することもできます。

The geofeed files MUST be published via and fetched using HTTPS [RFC2818].

Geofeedファイルは、https [rfc2818]を使用して発行してフェッチする必要があります。

When using data from a geofeed file, one MUST ignore data outside the referring inetnum: object's inetnum: attribute address range.

GeoFeedファイルからデータを使用する場合、参照inetnum：オブジェクトのinetnum：属性アドレス範囲の参照の外側にデータを無視する必要があります。

If and only if the geofeed file is not signed per Section 4, 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ファイルがセクション4ごとに署名されていない場合に限り、複数のinetnum：オブジェクトが同じGeoFeedファイルを参照することができ、コンシューマはGeoFeedファイル内の行だけを使用しなければなりません。：オブジェクトの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に示す目的のために排他的に従属証明書を発行することができる。

To minimize the load on RIR WHOIS [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be used for large-scale access to gather geofeed URLs. This also provides bulk access instead of fetching by brute-force search through the IP space.

RIR Whois [RFC3912]サービスの負荷を最小限に抑えるために、RIRのFTP [RFC0959]サービスを使用して、GeoFeed URLを収集するための大規模アクセスに使用する必要があります。これはまた、IPスペースを通してブルートフォース検索によるフェッチの代わりにバルクアクセスを提供します。

Currently, 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].

現在、地理化プロバイダはすべてのRIRSでバルクのデータアクセスを持っています。そのようなデータの匿名化されたバージョンは、Arinを除くすべてのRIRSに対して公認を必要としています。ただし、そのような承認なしのユーザーにとっては、余分なRDAP努力で同じ結果が得られます。すべてのRIRSにわたってそのようなデータを渡すオープンソースコードがあり、すべてのGeoFeed参照を収集し、それらを[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 [RFC7234] 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サーバーの過度の負荷を防ぐために、これらのメカニズムを使用したエンティティ取得GeoFeedデータは頻繁にリアルタイムルックアップを実行してはなりません。[RFC8805]のセクション3.4は、GeoFeedデータをレプリックするときにHTTP expiresヘッダ[RFC7234]を使用することを提案します。データが非常に頻繁に変化するにつれて、そのようなHTTPヘッダー信号がない場合、コレクターは毎週より頻繁に取り込まれてはいけません。他の人が同じことをする可能性が高いため、月曜日のUTCなどの魔法の時刻にフェッチしないでください。

6. Privacy Considerations

6. プライバシーに関する考慮事項

[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]は、このユーザーの露出による可能な損傷を回避または改善することに関するプライバシーガイダンスを提供しません。この文書に記載されているように、GeoFeedファイルへのポインタを公開すると、オペレータはGeofeedデータでこのエクスポージャーを認識し、慎重になる必要があります。[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]は位置データを公開する機能を提供していれば、この文書はそれらのデータへのバルクアクセスを容易に利用可能にします。これは事故ではなく目標です。

7. Security Considerations

7. セキュリティに関する考慮事項

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]のセキュリティ上の考慮事項もここに適用されます。

As mentioned in Section 4, many RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious geofeed files. Section 4 suggests an unfortunately complex method for stronger authentication based on the RPKI.

セクション4で述べたように、多くのRPSLリポジトリには、いずれかの認証があれば弱い。これにより、inetnumのなりすまし：悪意のあるGeoFeedファイルを指すオブジェクト。セクション4は、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）の場合、顧客または攻撃者は、符号なし等値または狭い（例えば、A / 24）Inetnumを発行することができます。GeoFeed参照を持つ最も特有のinetnum：オブジェクトを使用する必要があるというルールを乱用している承認が弱いWhoisレジストリ。

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ファイルサーバーによってデプロイされる可能性があります。

8. IANA Considerations

8. IANAの考慮事項

IANA has registered object identifiers for one content type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:

IANAは、次のように「SMIセキュリティ（1.2.840.113549.1.9.16.1）」レジストリに「SMIセキュリティ（1.2.840.113549.1.9.16.1）」の1つのコンテンツタイプのオブジェクト識別子を登録しています。

            +=========+==========================+============+
            | Decimal | Description              | References |
            +=========+==========================+============+
            | 47      | id-ct-geofeedCSVwithCRLF | RFC 9092   |
            +---------+--------------------------+------------+

Table 1

表1

9. References

9. 参考文献

9.1. Normative References

9.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>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC2622] Alaettinoglu、C、Villamizar、C、Gerich、E.、Kessens、D.、Meyer、D.、Bates、T.、Karrenberg、D.、およびM.Terpstra、「ルーティングポリシー仕様言語（RPSL） "、RFC 2622、DOI 10.17487 / RFC2622、1999年6月、<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>.

[RFC2725] Villamizar、C、Alaettinoglu、C.、Meyer、D.、およびS。マーフィー、「ルーティング政策システムセキュリティ」、RFC 2725、DOI 10.17487 / RFC2725、1999年12月、<https：//www.rfc-editor.org/info/rfc2725>。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.

[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。

[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>.

[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<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>.

[RFC3779] Lynn、C、Kent、S.、K. SEO、「IPアドレスのX.509拡張機能」、RFC 3779、DOI 10.17487 / RFC3779、2004年6月、<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>.

[RFC4012] Blunk、L.、Damas、J.、Parent、F.、およびA. Robachevsky、 "ルーティングポリシー仕様言語Next Generation（RPSLNG）"、RFC 4012、DOI 10.17487 / RFC4012、2005年3月、<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>.

[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<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>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<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>.

[RFC5652] Housley、R.、 "Cryptographic Message Syntax（CMS）"、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<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>.

[RFC6481] Huston、G.、Loomans、R.およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<https：//www.rfc-編集者。ORG / INFO / RFC6481>。

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

[RFC6486] Austein、R.、Huston、G.、Kent、S.、およびM.Lepinski、「リソース公開鍵インフラストラクチャ（RPKI）」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<https：//www.rfc-editor.org/info/rfc6486>。

[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>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.

[RFC8805] kline、E.、Duleba、K.、Szamonek、Z.、Moser、S.、およびW.Kumari、「自己発行IP地理化フィードのフォーマット」、RFC 8805、DOI 10.17487 / RFC8805、2020年8月<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>.

[RFC8933] Housley、R.、「アルゴリズム識別子保護のための暗号メッセージ構文（CMS）への更新」、RFC 8933、DOI 10.17487 / RFC8933、2020年10月、<https://www.rfc-editor.org/info/RFC8933>。

9.2. Informative References

9.2. 参考引用

[GEOFEED-FINDER] "geofeed-finder", commit 5f557a4, June 2021, <https://github.com/massimocandela/geofeed-finder>.

[Geofeed-Finder] "Geofeed-Finder"、Commit 5F557A4、2021年6月、<https：//github.com/massimocandela/geofeed-finder>。

[INET6NUM] RIPE NCC, "Description of the INET6NUM Object", October 2019, <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/ rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-3-description-of-the-inet6num-object>.

[inet6num]熟したNCC、「Inet6numオブジェクトの説明」、2019年10月、<https://www.ripe.net/manage-ips-and-asns/db/support/documentation/Ripe-Database-Documentation/ RPSL-オブジェクト・タイプ/ 4-2 - プライマリオブジェクトの説明/ 4-2-3-inet-inet6num-object>。

[INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020, <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/ rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object>.

[inetnum]熟したNCC、「Inetnumオブジェクトの説明」、2020年6月、<https://www.rep.net/manage-IPS-and-asns/db/support/documentation/Ripe-Database-Documentation/ RPSL-オブジェクト型/ 4-2 - プライマリオブジェクト/ 4-2-4-of-inetnum-object>の説明

[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>.

[RFC0959] Postel、J.およびJ. Reynolds、 "File Transfer Protocol"、STD 9、RFC 959、DOI 10.17487 / RFC0959、1985年10月、<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>.

[RFC3912] Daigle、L.、 "Whoisプロトコル仕様"、RFC 3912、DOI 10.17487 / RFC3912、2004年9月、<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>.

[RFC4632] Fuller、V.およびT.Li、「クラスレスドメイン間ルーティング（CIDR）：インターネットアドレス割り当てと集約計画」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<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>.

【RFC5485】Housley、R.、「インターネットドラフトドキュメント上のデジタルシグネチャ」、RFC 5485、DOI 10.17487 / RFC5485、2009年3月、<https：//www.rfc-editor.org/info/rfc5485>。

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.

[RFC7234] Field、R.、Ed。、Nottingham、M.、Ed。、J.Reschke、Ed。、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：キャッシング」、RFC 7234、DOI 10.17487 / RFC7234、2014年6月<https://www.rfc-editor.org/info/rfc7234>。

[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>.

[RFC7485] Zhou、L.、Kong、N.、Shen、S.、Sheng、S.、A. Servin、「Whois登録オブジェクトの在庫と分析」、RFC 7485、DOI 10.17487 / RFC7485、2015年3月、<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>.

[RFC7909] Kisteleki、R.およびB. Haberman、リソース公開鍵インフラストラクチャ（RPKI）シグニチャ（RPKI）シグネチャ（RPKI）シグネチャ "、RFC 7909、DOI 10.17487 / RFC7909、2016年6月、<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>.

[RFC9082] Hollenbeck、S.およびA.ニュートン、「登録データアクセスプロトコル（RDAP）クエリフォーマット」、STD 95、RFC 9082、DOI 10.17487 / RFC9082、2021年6月、<https://www.rfc-editor.org/ info / rfc9082>。

[RIPE-DB] RIPE NCC, "RIPE Database Documentation", <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation>.

[RIPE-DB]熟したNCC、「熟したデータベースのドキュメント」、<https://www.repe.net/manage-ips-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>.

[RIPE181]熟したNCC、「ルーティングレジストリのIPルーティングポリシーの表現」、<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>.

[RIPE81]熟したNCC、「熟したデータベースのIPルーティングポリシーの表現」、1993年2月、<https：//www.ripe.net/publications/docs/ripe-081>。

[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "Resource Public Key Infrastructure (RPKI) object profile for Signed Checklist (RSC)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rsc-04, 31 May 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04>.

[RPKI-RSC] Snijders、J.、Harrison、T.、およびB. Maddison、「リソース公開鍵インフラストラクチャ（RPKI）オブジェクトプロファイル（RSC）（RSC））、進行中の作業、インターネットドラフト、ドラフトIETF-SIDOPS-RPKI-RSC-04,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04>。

[RPKI-RTA] Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, T., and M. Hoffmann, "A profile for Resource Tagged Attestations (RTAs)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rta-00, 21 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>.

[RPKI-RTA] Michaelson、GG、Huston、G.、Harrison、T.、Bruijnzels、T.、およびM.Hoffmann、「リソースタグ化認証のプロフィール（RTAS）」、進行中の作業、インターネットドラフト、ドラフト-ietf-sidrops-rpki-RTA-00,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>。

Appendix A. Example

付録A.例

This appendix provides an example that includes a trust anchor, a CA certificate subordinate to the trust anchor, an end-entity certificate subordinate to the CA for signing the geofeed, and a detached signature.

この付録では、GeoFeedに署名するためのCAに署名するためのCAに従属するCAに従属する信頼アンカー、信託アンカーに準拠したCA証明書、および切り離された署名を含む例を提供します。

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）番号を超える権限を持っています。

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証明書は信託アンカーによって発行されます。この証明書は、1つのIPv4アドレスブロック（192.0.2.0/24）と2つの数字（64496と64497）を超える権限を付与します。

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 certificate.

エンドエンティティ証明書はCAによって発行されます。この証明書は、1つのIPv4アドレスブロック（192.0.2.0/24）に対して署名権限を付与します。Geofeedデータシグネチャには、GeoFeedデータシグネチャには署名権限が必要ありませんので、番号が証明書に含まれています。

The end-entity certificate is displayed below in detail. For brevity, the other two certificates are not.

エンドエンティティ証明書は以下の詳細に表示されます。簡潔にするために、他の2つの証明書はそうではありません。

       0 1189: SEQUENCE {
       4  909:  SEQUENCE {
       8    3:   [0] {
      10    1:    INTEGER 2
             :     }
      13   20:   INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E4
      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 20/05/2021 16:05:45 GMT
     120   13:    UTCTime 16/03/2022 16:05:45 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  431:   [3] {
     486  427:    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   12:     SEQUENCE {
     556    3:      OBJECT IDENTIFIER basicConstraints (2 5 29 19)
     561    1:      BOOLEAN TRUE
     564    2:      OCTET STRING, encapsulates {
     566    0:       SEQUENCE {}
             :        }
             :       }
     568   14:     SEQUENCE {
     570    3:      OBJECT IDENTIFIER keyUsage (2 5 29 15)
     575    1:      BOOLEAN TRUE
     578    4:      OCTET STRING, encapsulates {
     580    2:       BIT STRING 7 unused bits
             :        '1'B (bit 0)
             :        }
             :       }
     584   24:     SEQUENCE {
     586    3:      OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
     591    1:      BOOLEAN TRUE
     594   14:      OCTET STRING, encapsulates {
     596   12:       SEQUENCE {
     598   10:        SEQUENCE {
     600    8:         OBJECT IDENTIFIER
             :          resourceCertificatePolicy (1 3 6 1 5 5 7 14 2)
             :          }
             :         }
             :        }
             :       }
     610   97:     SEQUENCE {
     612    3:      OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
     617   90:      OCTET STRING, encapsulates {
     619   88:       SEQUENCE {
     621   86:        SEQUENCE {
     623   84:         [0] {
     625   82:          [0] {
     627   80:           [6]
             :          'rsync://rpki.example.net/repository/3ACE2CEF4F'
             :          'B21B7D11E3E184EFC1E297B3778642.crl'
             :            }
             :           }
             :          }
             :         }
             :        }
             :       }
     709  108:     SEQUENCE {
     711    8:      OBJECT IDENTIFIER authorityInfoAccess
             :       (1 3 6 1 5 5 7 1 1)
     721   96:      OCTET STRING, encapsulates {
     723   94:       SEQUENCE {
     725   92:        SEQUENCE {
     727    8:         OBJECT IDENTIFIER caIssuers (1 3 6 1 5 5 7 48 2)
     737   80:         [6]
             :          'rsync://rpki.example.net/repository/3ACE2CEF4F'
             :          'B21B7D11E3E184EFC1E297B3778642.cer'
             :          }
             :         }
             :        }
             :       }
     819   25:     SEQUENCE {
     821    8:      OBJECT IDENTIFIER ipAddrBlocks (1 3 6 1 5 5 7 1 7)
     831    1:      BOOLEAN TRUE
     834   10:      OCTET STRING, encapsulates {
     836    8:       SEQUENCE {
     838    6:        SEQUENCE {
     840    2:         OCTET STRING 00 01
     844    0:         NULL
             :          }
             :         }
             :        }
             :       }
     846   69:     SEQUENCE {
     848    8:      OBJECT IDENTIFIER subjectInfoAccess
             :       (1 3 6 1 5 5 7 1 11)
     858   57:      OCTET STRING, encapsulates {
     860   55:       SEQUENCE {
     862   53:        SEQUENCE {
     864    8:         OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
     874   41:         [6]
             :          'https://rrdp.example.net/notification.xml'
             :          }
             :         }
             :        }
             :       }
             :      }
             :     }
             :    }
     917   13:  SEQUENCE {
     919    9:   OBJECT IDENTIFIER sha256WithRSAEncryption
             :    (1 2 840 113549 1 1 11)
     930    0:   NULL
             :    }
     932  257:  BIT STRING
             :   48 C2 F7 C8 15 A7 43 1B EE E8 8A 68 7C A5 3F 4E
             :   39 DE 6B 49 F8 09 0D D3 B7 EC 2B FA 86 C3 F7 BD
             :   D0 32 6F ED CA 75 86 F8 E3 E2 EC B7 B2 07 FB 3C
             :   94 3B 70 A3 46 AE 0C 9B AB F9 44 D2 37 1E F8 04
             :   60 56 36 E2 D8 1A F3 66 C5 80 9C 1F 38 E9 29 F0
             :   B2 4B 70 E9 C7 A7 6A 27 FA 03 0C 3A AB 4D 0D B2
             :   90 1E A4 C0 5D D9 58 3F F6 C2 85 BC EC 09 15 53
             :   A0 35 CA A2 42 25 CF E6 B1 89 3D 60 5C 38 CB F9
             :   D9 AF FB 69 D8 DF 5F 0A 67 3A 28 E2 4C E8 0C 96
             :   84 06 98 2D 93 3D 9A 72 75 92 A3 97 11 00 4D D1
             :   44 42 CB 1A DF 7C 43 9E 5A 69 FB FA FD C6 E3 55
             :   61 1B 51 70 2D FA A1 6A DA 54 0D E3 CC DE 85 EA
             :   B0 C4 F2 BF 31 B3 7C A5 21 25 73 E8 97 82 43 86
             :   11 63 06 CC B2 38 DC FE D8 89 2C CE D9 63 12 1E
             :   E4 8A D8 CF 56 6D 37 A9 FF 48 4B 2C 24 0B 30 44
             :   88 29 B3 61 21 0A DF C7 4B 6C 40 98 60 8E 86 05
             :   }

To allow reproduction of the signature results, the end-entity private key is provided. For brevity, the other two private keys are not.

署名結果の再現を許可するために、エンドエンティティ秘密鍵が提供されます。簡潔にするために、他の2つの秘密鍵はそうではありません。

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,2,2,24,000,2000,24,,2,24,2000"（CrとLFで終了）の署名は、次の切り離されたCMS署名をもたらします。

    # RPKI Signature: 192.0.2.0 - 192.0.2.255
    # MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
    # IhvcNAQkQAS+gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
    # QwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
    # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYx
    # NjA1NDVaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
    # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
    # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
    # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
    # r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
    # FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
    # zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
    # ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggGvMIIBqzAdBgNVHQ4EFgQUkUZSo71R
    # wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
    # wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBg
    # grBgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZ
    # S5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5
    # N0IzNzc4NjQyLmNybDBsBggrBgEFBQcBAQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5
    # jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0
    # QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIuY2VyMBkGCCsGAQUFBwEHAQH/BAowC
    # DAGBAIAAQUAMEUGCCsGAQUFBwELBDkwNzA1BggrBgEFBQcwDYYpaHR0cHM6Ly9y
    # cmRwLmV4YW1wbGUubmV0L25vdGlmaWNhdGlvbi54bWwwDQYJKoZIhvcNAQELBQA
    # DggEBAEjC98gVp0Mb7uiKaHylP0453mtJ+AkN07fsK/qGw/e90DJv7cp1hvjj4u
    # y3sgf7PJQ7cKNGrgybq/lE0jce+ARgVjbi2BrzZsWAnB846Snwsktw6cenaif6A
    # ww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP5rGJPWBcOMv52a/7adjfXwpn
    # OijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xDnlpp+/r9xuNVYRtRcC36oWr
    # aVA3jzN6F6rDE8r8xs3ylISVz6JeCQ4YRYwbMsjjc/tiJLM7ZYxIe5IrYz1ZtN6
    # n/SEssJAswRIgps2EhCt/HS2xAmGCOhgUxggGqMIIBpgIBA4AUkUZSo71RwUQmA
    # ZiIn1xFq/BToYcwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3
    # DQEJEAEvMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjAxNjI4MzlaMC8GCSqGSIb3DQE
    # JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU+iPuFbQR8qX3BFjANBgkqhkiG9w
    # 0BAQEFAASCAQB85HsCBrU3EcVOcf4nC6Z3jrOjT+fVlyTDAObF6GTNWgrxe7jSA
    # Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJntl9D3igt38M
    # o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s6OPox3M0+6eKH3/vBKnw1s1ayM
    # 0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vp0qyF2D9v+w+nyhZOPmuePm7
    # YqLyOw/E99PVBs9uI+hmBiCz/BK2Z3VRjrrlrUU+49eldSTkZ2sJyhCbbV2Ufgi
    # S2FOquAgJzjilyN3BDQLV8Rp9cGh0PpVslKH2na
    # End Signature: 192.0.2.0 - 192.0.2.255

Acknowledgments

謝辞

Thanks to Rob Austein for 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; Job Snijders, who provided running code; 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 Adrian Farrel, Antonio Prado, Francesca Palombini, Jean-Michel Combes (INTDIR), John Scudder, Kyle Rose (SECDIR), Martin Duke, Murray Kucherawy, Paul Kyzivat (GENART), Rob Wilton, and Roman Danyliw. The authors also thank George Michaelson, the awesome document shepherd.

CMSと脱却されたシグネチャーの手がかりのためのRob Austein、最初の陸上の外部レビューのためのGeorge Michaelson、および共著に同意するには恥ずかしがり屋のklineのためにありがとう。さらに、Menno Schepersを含む、私たちは早期実装者に感謝を表明します。Flavio Luciani。Eric Dugas;実行コードを提供している求人Snijders。ケビンパック。また、この記載の解決策を使用してGeofeedsを消費している次の地理的構成プロバイダーのおかげで：Jonathan Kosgei（IPData.co）、Ben Dowling（IPinfo.io）、およびPol Nisenblat（BigDatacloud.com）。素晴らしい役立つレビューのために、私たちはAdrian Farrel、Antonio Farrel、Antonio Prado、Francesca Palombini、Jean-Michel Combes（intdir）、John Scudder、Kyle Rose（Secdir）、Martin Duke、Murray Kucherawy、Paul Kyzivat（Genart）、Rob Wilton、そしてローマのダニリウォン。著者らはまた、George Michaelson、The Awesome Document Shepherdに感謝します。

Authors' Addresses

著者の住所

Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America

Randy Bush Iij＆Arrcus 5147 Crystal Springs Bainbridge Island、ワシントン98110アメリカ

   Email: randy@psg.com

Massimo Candela NTT Siriusdreef 70-72 2132 WT Hoofddorp Netherlands

Massimo Candela NTT SiriusDreef 70-72 2132 WT HoofdDorpオランダ

   Email: massimo@ntt.net

Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America

Warren Kumari Google 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国

   Email: warren@kumari.net

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America

Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com