[要約] RFC 8182は、RPKIリポジトリデルタプロトコル（RRDP）に関する仕様です。RRDPは、RPKIデータの効率的な配信と更新を可能にするために設計されています。
Internet Engineering Task Force (IETF) T. Bruijnzeels
Request for Comments: 8182 O. Muravskiy
Category: Standards Track RIPE NCC
ISSN: 2070-1721 B. Weber
Cobenian
R. Austein
Dragon Research Labs
July 2017
The RPKI Repository Delta Protocol (RRDP)
RPKIリポジトリデルタプロトコル（RRDP）
Abstract
概要
In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.
リソース公開鍵インフラストラクチャ（RPKI）では、認証局（CA）がエンドエンティティ証明書、証明書失効リスト（CRL）、RPKI署名付きオブジェクトなどの証明書をリポジトリに公開します。依拠当事者は、公開された情報をそれらのリポジトリから取得します。このドキュメントでは、この目的のための新しいRPKIリポジトリデルタプロトコル（RRDP）を指定します。 RRDPは特にスケーリング用に設計されました。 HTTPS（HTTP over Transport Layer Security（TLS））を使用して取得できる現在のスナップショットファイルとデルタファイルをリストする更新通知ファイルに依存し、コンテンツ配信ネットワーク（CDN）またはその他のキャッシュインフラストラクチャの使用を可能にしますこれらのファイルの取得。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8182.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8182で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. RPKI Repository Delta Protocol Implementation . . . . . . . . 4
3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 4
3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 5
3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 6
3.3.1. Initialization . . . . . . . . . . . . . . . . . . . 6
3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 6
3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7
3.4.1. Processing the Update Notification File . . . . . . . 7
3.4.2. Processing Delta Files . . . . . . . . . . . . . . . 9
3.4.3. Processing a Snapshot File . . . . . . . . . . . . . 10
3.4.4. Polling the Update Notification File . . . . . . . . 10
3.4.5. Considerations Regarding Operational Failures in RRDP 11
3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 11
3.5.1. Update Notification File . . . . . . . . . . . . . . 11
3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 13
3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 15
3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 17
4. Operational Considerations . . . . . . . . . . . . . . . . . 18
4.1. Compatibility with previous standards . . . . . . . . . . 18
4.2. Distribution Considerations . . . . . . . . . . . . . . . 19
4.3. HTTPS Considerations . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
In the Resource Public Key Infrastructure (RPKI), Certificate
Authorities publish certificates [RFC6487], RPKI signed objects
[RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may
have an embedded mechanism to publish to these repositories, or they
may use a separate Repository Server and publication protocol. RPKI
repositories are currently accessible using the rsync protocol
[RSYNC], allowing Relying Parties to synchronize a local copy of the
RPKI repository used for validation with the remote repositories
[RFC6481].
rsync [RSYNC] has proven valuable in the early deployment of RPKI, because it allowed operators to gain experience without the need to invent a custom protocol. However, operational experience has brought concerns to light that we wish to address here:
rsync [RSYNC]は、オペレーターがカスタムプロトコルを開発する必要なしに経験を積むことができるため、RPKIの初期導入において価値があることが証明されています。しかし、運用経験から、ここで対処したい懸念が明らかになりました。
o rsync [RSYNC] is designed to limit the amount of data that needs to be transferred between client and server. However, the server needs to spend significant resources in terms of CPU and memory for every connection. This is a problem in an envisioned RPKI deployment where thousands of Relying Parties query a small number of central repositories, and it makes these repositories weak to denial-of-service attacks.
o rsync [RSYNC]は、クライアントとサーバーの間で転送する必要があるデータの量を制限するように設計されています。ただし、サーバーは、接続ごとにCPUとメモリの観点からかなりのリソースを費やす必要があります。これは、数千の依拠当事者が少数の中央リポジトリーを照会する想定されるRPKIデプロイメントの問題であり、これらのリポジトリーをサービス拒否攻撃に対して脆弱にします。
o A secondary concern is the lack of supported rsync server and client libraries. In practice, all implementations have to make system calls to an rsync binary. This is inefficient; it introduces fragility with regards to updates of this binary, makes it difficult to catch and report problems to operators, and complicates software development and testing.
o もう1つの問題は、サポートされているrsyncサーバーおよびクライアントライブラリがないことです。実際には、すべての実装でrsyncバイナリへのシステムコールを行う必要があります。これは非効率的です。このバイナリの更新に関して脆弱性を導入し、問題をキャッチしてオペレーターに報告することを困難にし、ソフトウェアの開発とテストを複雑にします。
This document specifies an alternative repository access protocol based on Update Notification, Snapshot, and Delta Files that a Relying Party can retrieve over the HTTPS protocol. This allows Relying Parties to either perform a full (re-)synchronization of their local copy of the repository using Snapshot Files or use Delta Files to keep their local repository updated after initial synchronization. We call this the RPKI Repository Delta Protocol, or RRDP in short.
このドキュメントでは、依存パーティがHTTPSプロトコルを介して取得できる更新通知、スナップショット、および差分ファイルに基づく代替リポジトリアクセスプロトコルを指定します。これにより、依拠当事者は、スナップショットファイルを使用してリポジトリのローカルコピーの完全（再）同期を実行するか、差分ファイルを使用して、初期同期後にローカルリポジトリを更新し続けることができます。これをRPKIリポジトリデルタプロトコル、またはRRDPと略します。
RRDP was designed to support scaling in RPKI's asymmetric deployment. It is consistent (in terms of data structures) with the publication protocol [RFC8181] and treats publication events of one or more repository objects as discrete events that can be communicated to Relying Parties. This approach helps to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. RRDP also provides a standards- based way to obtain consistent, point-in-time views of a single repository, eliminating a number of consistency-related issues. Finally, this approach allows these discrete events to be communicated as immutable files. This enables Repository Servers to pre-calculate these files only once for all clients, thus limiting the CPU and memory investments required, and enables the use of a caching infrastructure to reduce the load on a Repository Server when a large number of Relying Parties are querying it.
RRDPは、RPKIの非対称展開でのスケーリングをサポートするように設計されました。これは（データ構造の点で）公開プロトコル[RFC8181]と一貫しており、1つ以上のリポジトリオブジェクトの公開イベントを、依拠当事者に通信できる個別のイベントとして扱います。このアプローチは、ネットワークを通過するデータの量を最小限に抑え、リポジトリの収束が発生するまでの時間を最小限に抑えるのに役立ちます。 RRDPは、単一のリポジトリーの一貫した特定の時点のビューを取得する標準ベースの方法も提供し、一貫性に関連する多くの問題を排除します。最後に、このアプローチでは、これらの個別のイベントを不変のファイルとして伝達できます。これにより、リポジトリサーバーはすべてのクライアントに対してこれらのファイルを1回だけ事前計算できるため、必要なCPUとメモリへの投資が制限され、キャッシュインフラストラクチャを使用して、多数の依拠当事者がクエリを実行しているときにリポジトリサーバーの負荷を軽減できます。それ。
This document allows the use of RRDP as an additional repository distribution mechanism for RPKI. In time, RRDP may replace rsync [RSYNC] as the only mandatory-to-implement repository distribution mechanism. However, this transition is outside of the scope of this document.
このドキュメントでは、RPKIの追加のリポジトリ配布メカニズムとしてRRDPを使用できます。やがて、RRDPはrsync [RSYNC]を唯一の必須のリポジトリ配布メカニズムとして置き換えるかもしれません。ただし、この移行はこのドキュメントの範囲外です。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Certification Authorities in the RPKI use a Repository Server to publish their RPKI products, such as manifests, CRLs, signed certificates, and RPKI-signed objects. This Repository Server may be remote or embedded in the Certificate Authority engine itself. Certificates in the RPKI that use a Repository Server that supports RRDP include a special Subject Information Access (SIA) pointer referring to an Update Notification File.
RPKIの証明機関は、リポジトリサーバーを使用して、マニフェスト、CRL、署名付き証明書、RPKI署名付きオブジェクトなどのRPKI製品を公開します。このリポジトリサーバーはリモートであるか、認証局エンジン自体に埋め込まれている場合があります。 RRDPをサポートするリポジトリサーバーを使用するRPKIの証明書には、更新通知ファイルを参照する特別なサブジェクト情報アクセス（SIA）ポインターが含まれています。
The Update Notification File includes a globally unique session_id in the form of a version 4 Universally Unique IDentifier (UUID) [RFC4122] and serial number that can be used by the Relying Party to determine if it and the repository are synchronized. Furthermore, it includes a link to the most recent complete snapshot of current objects that are published by the Repository Server, and a list of links to Delta Files, for each revision starting at a point determined by the Repository Server, up to the current revision of the repository.
更新通知ファイルには、バージョン4のUniversally Unique IDentifier（UUID）[RFC4122]の形式でグローバルに一意のsession_idと、依存パーティがそれとリポジトリが同期しているかどうかを判断するために使用できるシリアル番号が含まれています。さらに、Repository Serverによって公開されている現在のオブジェクトの最新の完全なスナップショットへのリンクと、Repository Serverによって決定されたポイントから現在のリビジョンまでの各リビジョンのデルタファイルへのリンクのリストが含まれます。リポジトリの。
A Relying Party that learns about an Update Notification File location for the first time can download it and then proceed to download the latest Snapshot File, thus creating a local copy of the repository that is in sync with the Repository Server. The Relying Party records the location of this Update Notification File, the session_id, and the current serial number.
更新通知ファイルの場所を初めて認識した証明書利用者は、それをダウンロードしてから最新のスナップショットファイルをダウンロードし、リポジトリサーバーと同期するリポジトリのローカルコピーを作成できます。証明書利用者は、この更新通知ファイルの場所、session_id、および現在のシリアル番号を記録します。
Relying Parties are encouraged to re-fetch this Update Notification File at regular intervals, but not more often than once per minute. After re-fetching the Update Notification File, the Relying Party may find that there are one or more Delta Files available that allow it to synchronize its local repository with the current state of the Repository Server. If no contiguous chain of deltas from the Relying Party's serial to the latest repository serial is available, or if the session_id has changed, the Relying Party performs a full resynchronization instead.
依拠当事者は、この更新通知ファイルを定期的に再フェッチすることをお勧めしますが、頻度は1分に1回以下です。更新通知ファイルを再フェッチした後、証明書利用者は、ローカルリポジトリをリポジトリサーバーの現在の状態と同期できるようにする1つ以上のデルタファイルが利用できることを見つける場合があります。証明書利用者のシリアルから最新のリポジトリシリアルへのデルタの連続したチェーンが利用できない場合、またはsession_idが変更された場合、証明書利用者は代わりに完全再同期を実行します。
As soon as the Relying Party fetches new content in this way, it could start a validation process. An example of a reason why a Relying Party may not choose to do this immediately is because it has learned of more than one notification location, and it prefers to complete all its updates before validating.
依存パーティがこの方法で新しいコンテンツをフェッチするとすぐに、検証プロセスを開始できます。依拠当事者がこれをすぐに選択しない理由の例は、それが複数の通知場所を知っており、検証する前にすべての更新を完了することを好むためです。
The Repository Server could use a caching infrastructure to reduce its load, particularly because snapshots and deltas for any given session_id and serial number contain an immutable record of the state of the Repository Server at a certain point in time. For this reason, these files can be cached indefinitely. Update Notification Files are polled by Relying Parties to discover if updates exist; for this reason, Update Notification Files may not be cached for longer than one minute.
特に、特定のsession_idとシリアル番号のスナップショットとデルタには、特定の時点でのリポジトリサーバーの状態の不変のレコードが含まれているため、リポジトリサーバーはキャッシュインフラストラクチャを使用して負荷を軽減できます。このため、これらのファイルは無期限にキャッシュできます。更新通知ファイルは、更新が存在するかどうかを検出するために依拠当事者によってポーリングされます。このため、更新通知ファイルは1分以上キャッシュされない場合があります。
Certificate Authorities that use RRDP MUST include an instance of an SIA AccessDescription extension in resource certificates they produce, in addition to the ones defined in [RFC6487]:
RRDPを使用する認証局は、[RFC6487]で定義されているものに加えて、作成するリソース証明書にSIA AccessDescription拡張機能のインスタンスを含める必要があります。
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
This extension MUST use an accessMethod of id-ad-rpkiNotify; see Section 6:
この拡張機能では、id-ad-rpkiNotifyのaccessMethodを使用する必要があります。セクション6を参照してください。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 }
The accessLocation MUST be an HTTPS URI as defined in [RFC7230] that will point to the Update Notification File for the Repository Server that publishes the products of this Certificate Authority certificate.
accessLocationは、[RFC7230]で定義されているHTTPS URIである必要があります。これは、この認証局証明書の製品を公開するリポジトリサーバーの更新通知ファイルを指します。
When the Repository Server initializes, it performs the following actions:
リポジトリサーバーは、初期化時に次のアクションを実行します。
o The server MUST generate a new random version 4 UUID (see Section 4.1.3 of [RFC4122]) to be used as the session_id.
o サーバーは、session_idとして使用される新しいランダムバージョン4 UUID（[RFC4122]のセクション4.1.3を参照）を生成する必要があります。
o The server MUST then generate a Snapshot File for serial number ONE for this new session that includes all currently known published objects that the Repository Server is responsible for. Note that this Snapshot File may contain zero publish elements at this point if no objects have been submitted for publication yet.
o 次に、サーバーは、この新しいセッションのシリアル番号1のスナップショットファイルを生成する必要があります。このスナップショットファイルには、Repository Serverが担当する既知のすべての公開オブジェクトが含まれています。このスナップショットファイルには、オブジェクトがまだ発行のために送信されていない場合、この時点で発行要素が含まれていない場合があります。
o This Snapshot File MUST be made available at a URL that is unique to this session_id and serial number, so that it can be cached indefinitely. The format and caching concerns for Snapshot Files are explained in more detail in Section 3.5.2.
o このスナップショットファイルは、無期限にキャッシュできるように、このsession_idとシリアル番号に固有のURLで使用できるようにする必要があります。スナップショットファイルのフォーマットとキャッシングの問題については、セクション3.5.2で詳しく説明しています。
o After the Snapshot File has been published, the Repository Server MUST publish a new Update Notification File that contains the new session_id, has serial number ONE, has one reference to the Snapshot File that was just published, and contains no delta references. The format and caching concerns for Update Notification Files are explained in more detail in Section 3.5.1.
o スナップショットファイルが公開された後、リポジトリサーバーは、新しいsession_idを含み、シリアル番号ONEを持ち、公開されたばかりのスナップショットファイルへの参照を1つ持ち、デルタ参照を含まない新しい更新通知ファイルを公開する必要があります。更新通知ファイルの形式とキャッシュに関する問題については、セクション3.5.1で詳しく説明しています。
Whenever the Repository Server receives updates from a Certificate Authority, it MUST generate new snapshot and Delta Files within one minute. If a Repository Server services a large number of Certificate Authorities, it MAY choose to combine updates from multiple CAs. If a Repository Server combines updates in this way, it MUST ensure that publication never postponed for longer than one minute for any of the CAs involved.
リポジトリサーバーが認証局から更新を受信するたびに、1分以内に新しいスナップショットとデルタファイルを生成する必要があります。リポジトリサーバーが多数の認証局にサービスを提供する場合、複数のCAからの更新を組み合わせることを選択する場合があります。リポジトリサーバーが更新をこの方法で組み合わせる場合は、関係するCAのいずれかで公開が1分を超えて延期されないようにする必要があります。
Updates are processed as follows:
更新は次のように処理されます。
o The new repository serial number MUST be one greater than the current repository serial number.
o 新しいリポジトリのシリアル番号は、現在のリポジトリのシリアル番号より1つ大きくなければなりません。
o A new Delta File MUST be generated for this new serial. This Delta File MUST include all new, replaced, and withdrawn objects for multiple CAs, if applicable, as a single change set.
o この新しいシリアルに対して、新しいデルタファイルを生成する必要があります。この差分ファイルには、該当する場合、複数のCAのすべての新規、置換、および撤回されたオブジェクトを単一の変更セットとして含める必要があります。
o This Delta File MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely.
o このデルタファイルは、無期限にキャッシュできるように、現在のsession_idとシリアル番号に固有のURLで使用できるようにする必要があります。
o The format and caching concerns for Delta Files are explained in more detail in Section 3.5.3.
o Deltaファイルのフォーマットとキャッシングの問題については、セクション3.5.3で詳しく説明しています。
o The Repository Server MUST also generate a new Snapshot File for this new serial. This file MUST contain all "publish" elements for all current objects.
o リポジトリサーバーは、この新しいシリアルの新しいスナップショットファイルも生成する必要があります。このファイルには、現在のすべてのオブジェクトのすべての「publish」要素が含まれている必要があります。
o The Snapshot File MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely.
o スナップショットファイルは、このセッションと新しいシリアルに固有のURLで使用できるようにして、無期限にキャッシュできるようにする必要があります。
o The format and caching concerns for Snapshot Files are explained in more detail in Section 3.5.2.
o スナップショットファイルのフォーマットとキャッシングの問題については、セクション3.5.2で詳しく説明しています。
o Any older Delta Files that, when combined with all more recent Delta Files, will result in the total size of deltas exceeding the size of the snapshot MUST be excluded to avoid that Relying Parties download more data than necessary.
o 依拠当事者が必要以上のデータをダウンロードしないように、最新のすべてのデルタファイルと組み合わせると、デルタの合計サイズがスナップショットのサイズを超える古いデルタファイルは除外する必要があります。
o A new Update Notification File MUST now be created by the Repository Server. This new Update Notification File MUST include a reference to the new Snapshot File and all Delta Files selected in the previous steps.
o 新しい更新通知ファイルをリポジトリサーバーで作成する必要があります。この新しい更新通知ファイルには、前の手順で選択した新しいスナップショットファイルとすべてのデルタファイルへの参照を含める必要があります。
o The format and caching concerns for Update Notification Files are explained in more detail in Section 3.5.1.
o 更新通知ファイルの形式とキャッシュに関する問題については、セクション3.5.1で詳しく説明しています。
If the Repository Server is not capable of performing the above for some reason, then it MUST perform a full re-initialization, as explained above in Section 3.3.1.
リポジトリサーバーが何らかの理由で上記を実行できない場合、セクション3.3.1で説明したように、完全な再初期化を実行する必要があります。
When a Relying Party performs RPKI validation and learns about a valid certificate with an SIA entry for the RRDP protocol, it SHOULD use this protocol as follows.
証明書利用者がRPKI検証を実行し、RRDPプロトコルのSIAエントリを使用して有効な証明書について学習する場合、証明書利用者はこのプロトコルを次のように使用する必要があります（SHOULD）。
The Relying Party MUST download the Update Notification File, unless an Update Notification File was already downloaded and processed from the same location in this validation run or a polling strategy was used (see Section 3.4.4).
この検証実行で同じ場所から更新通知ファイルが既にダウンロードおよび処理されていたり、ポーリング戦略が使用されていたりしない限り、証明書利用者は更新通知ファイルをダウンロードする必要があります（セクション3.4.4を参照）。
It is RECOMMENDED that the Relying Party uses a "User-Agent" header explained in Section 5.5.3. of [RFC7231] to identify the name and version of the Relying Party software used. It is useful to track capabilities of Relying Parties in the event of changes to the RPKI standards.
証明書利用者は、セクション5.5.3で説明されている「User-Agent」ヘッダーを使用することをお勧めします。 [RFC7231]を使用して、使用されている証明書利用者ソフトウェアの名前とバージョンを識別します。 RPKI標準が変更された場合に、依拠当事者の機能を追跡することは有用です。
When the Relying Party downloads an Update Notification File, it MUST verify the file format and validation steps described in Section 3.5.1.3. If this verification fails, the file MUST be rejected and RRDP cannot be used. See Section 3.4.5 for considerations.
証明書利用者は、更新通知ファイルをダウンロードするときに、セクション3.5.1.3で説明されているファイル形式と検証手順を検証する必要があります。この検証が失敗した場合、ファイルは拒否されなければならず、RRDPは使用できません。考慮事項については、セクション3.4.5を参照してください。
The Relying Party MUST verify whether the session_id matches the last known session_id for this Update Notification File location. Note that even though the session_id is a random UUID value, it alone MUST NOT be used by a Relying Party as a unique identifier of a session but always together with the location of the Update Notification File. The reason for this is that a malicious server can use an existing session_id from another Repository Server.
証明書利用者は、session_idがこの更新通知ファイルの場所の最後の既知のsession_idと一致するかどうかを確認する必要があります。 session_idはランダムなUUID値ですが、それだけを依拠当事者がセッションの一意の識別子として使用してはならず、常に更新通知ファイルの場所と一緒に使用する必要があります。これは、悪意のあるサーバーが別のリポジトリサーバーの既存のsession_idを使用できるためです。
If the session_id matches the last known session_id, then a Relying Party MAY download and process missing Delta Files as described in Section 3.4.2, provided that all Delta Files for serial numbers between the last processed serial number and the current serial number in the Update Notification File can be processed this way.
session_idが最後の既知のsession_idと一致する場合、依存パーティはセクション3.4.2で説明されているように、欠落しているDeltaファイルをダウンロードして処理できます（ただし、最後に処理されたシリアル番号とアップデートの現在のシリアル番号の間のシリアル番号のすべてのデルタファイル）通知ファイルはこの方法で処理できます。
If the session_id matches the last known session_id, but Delta Files were not used, then the Relying Party MUST download and process the Snapshot File on the Update Notification File as described in Section 3.4.3.
session_idが最後の既知のsession_idと一致するが、Deltaファイルが使用されなかった場合、依存パーティは、セクション3.4.3で説明されているように、更新通知ファイルでスナップショットファイルをダウンロードして処理する必要があります。
If the session_id does not match the last known session_id, the Relying Party MUST update its last known session_id to the value specified in the downloaded Update Notification File. The Relying Party MUST then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3.
session_idが最後の既知のsession_idと一致しない場合、依存パーティは、最後の既知のsession_idを、ダウンロードした更新通知ファイルで指定された値に更新する必要があります。依存パーティは、セクション3.4.3で説明されているように、ダウンロードされた更新通知ファイルで指定されたスナップショットファイルをダウンロードして処理する必要があります。
If an Update Notification File contains a contiguous chain of links to Delta Files from the last processed serial number to the current serial number, then Relying Parties MUST attempt to download and process all Delta Files in order of serial number as follows.
更新通知ファイルに、最後に処理されたシリアル番号から現在のシリアル番号までのデルタファイルへのリンクの連続したチェーンが含まれている場合、依拠当事者は、次のようにシリアル番号順にすべてのデルタファイルをダウンロードして処理する必要があります。
When the Relying Party downloads a Delta File, it MUST verify the file format and perform validation steps described in Section 3.5.3.3. If this verification fails, the file MUST be rejected.
依拠当事者は、Deltaファイルをダウンロードするときに、ファイル形式を検証し、セクション3.5.3.3で説明されている検証手順を実行する必要があります。この検証が失敗した場合、ファイルは拒否される必要があります。
Furthermore, the Relying Party MUST verify that the hash of the contents of this file matches the hash on the Update Notification File that referenced it. In case of a mismatch of this hash, the file MUST be rejected.
さらに、依拠当事者は、このファイルのコンテンツのハッシュが、それを参照した更新通知ファイルのハッシュと一致することを確認する必要があります。このハッシュが一致しない場合は、ファイルを拒否する必要があります。
If a Relying Party retrieved a Delta File that is valid according to the above criteria, it performs the following actions:
証明書利用者が上記の基準に従って有効なデルタファイルを取得した場合、証明書利用者は次のアクションを実行します。
o The Relying Party MUST verify that the session_id matches the session_id of the Update Notification File. If the session_id values do not match, the file MUST be rejected.
o 証明書利用者は、session_idが更新通知ファイルのsession_idと一致することを確認する必要があります。 session_id値が一致しない場合、ファイルは拒否される必要があります。
o The Relying Party MUST verify that the serial number of this Delta File is exactly one greater than the last processed serial number for this session_id, and if not, this file MUST be rejected.
o 依拠当事者は、この差分ファイルのシリアル番号が、このsession_idで最後に処理されたシリアル番号よりも1つ大きいことを確認する必要があります。そうでない場合、このファイルは拒否する必要があります。
o The Relying Party SHOULD add all publish elements to a local storage and update its last processed serial number to the serial number of this Delta File.
o 証明書利用者は、すべての発行要素をローカルストレージに追加し、最後に処理されたシリアル番号をこのデルタファイルのシリアル番号に更新する必要があります（SHOULD）。
o When a Relying Party encounters a "withdraw" element, or a "publish" element where an object is replaced, in a delta that it retrieves from a Repository Server, it MUST verify that the object to be withdrawn or replaced was retrieved from this same Repository Server before applying the appropriate action. Failing to do so will leave the Relying Party vulnerable to malicious Repository Servers instructing it to delete or change arbitrary objects.
o 依拠当事者は、リポジトリサーバーから取得するデルタで、オブジェクトが置き換えられる「withdraw」要素または「publish」要素に遭遇すると、撤回または置換されるオブジェクトがこの同じ要素から取得されたことを確認する必要があります。適切なアクションを適用する前のリポジトリサーバー。そうしないと、依存パーティが悪意のあるリポジトリサーバーに対して脆弱となり、任意のオブジェクトを削除または変更するように指示されます。
If any Delta File is rejected, Relying Parties MUST process the current Snapshot File instead, as described in Section 3.4.3.
セクション3.4.3で説明されているように、Deltaファイルが拒否された場合、依拠当事者は代わりに現在のスナップショットファイルを処理する必要があります。
Snapshot Files MUST only be used if Delta Files are unavailable or were rejected; for a description of the process, see Section 3.4.1.
スナップショットファイルは、デルタファイルが使用できないか拒否された場合にのみ使用する必要があります。プロセスの説明については、セクション3.4.1を参照してください。
When the Relying Party downloads a Snapshot File, it MUST verify the file format and validation steps described in Section 3.5.2.3. If this verification fails, the file MUST be rejected.
証明書利用者は、スナップショットファイルをダウンロードするときに、セクション3.5.2.3で説明されているファイル形式と検証手順を検証する必要があります。この検証が失敗した場合、ファイルは拒否される必要があります。
Furthermore, the Relying Party MUST verify that the hash of the contents of this file matches the hash on the Update Notification File that referenced it. In case of a mismatch of this hash, the file MUST be rejected.
さらに、依拠当事者は、このファイルのコンテンツのハッシュが、それを参照した更新通知ファイルのハッシュと一致することを確認する必要があります。このハッシュが一致しない場合は、ファイルを拒否する必要があります。
If a Relying Party retrieved a Snapshot File that is valid according to the above criteria, it performs the following actions:
証明書利用者が上記の基準に従って有効なスナップショットファイルを取得した場合、証明書利用者は次のアクションを実行します。
o The Relying Party MUST verify that the session_id matches the session_id of the Update Notification File. If the session_id values do not match, the file MUST be rejected.
o 証明書利用者は、session_idが更新通知ファイルのsession_idと一致することを確認する必要があります。 session_id値が一致しない場合、ファイルは拒否される必要があります。
o The Relying Party MUST verify that the serial number of this Snapshot File is greater than the last processed serial number for this session_id. If this fails, the file MUST be rejected.
o 証明書利用者は、このスナップショットファイルのシリアル番号が、このsession_idで最後に処理されたシリアル番号より大きいことを確認する必要があります。これが失敗した場合、ファイルは拒否される必要があります。
o The Relying Party SHOULD then add all publish elements to a local storage and update its last processed serial number to the serial number of this Snapshot File.
o 依存パーティは、すべてのパブリッシュ要素をローカルストレージに追加し、最後に処理されたシリアル番号をこのスナップショットファイルのシリアル番号に更新する必要があります（SHOULD）。
If a Snapshot File is rejected, it means that RRDP cannot be used. See Section 3.4.5 for considerations.
スナップショットファイルが拒否された場合は、RRDPを使用できないことを意味します。考慮事項については、セクション3.4.5を参照してください。
Once a Relying Party has learned about the location, session_id, and last processed serial number of the repository that uses the RRDP protocol, the Relying Party MAY start polling the Repository Server for updates. However, the Relying Party MUST NOT poll for updates more often than once every 1 minute, and in order to reduce data usage, Relying Parties MUST use the "If-Modified-Since" header explained in Section 3.3 of [RFC7232] in requests.
証明書利用者がRRDPプロトコルを使用するリポジトリの場所、session_id、および最後に処理されたシリアル番号について学習すると、証明書利用者はリポジトリサーバーの更新のポーリングを開始できます（MAY）。ただし、依拠当事者は1分ごとに1回よりも頻繁に更新をポーリングしてはならず、データ使用を削減するために、依拠当事者はリクエストで[RFC7232]のセクション3.3で説明されている「If-Modified-Since」ヘッダーを使用する必要があります。
If a Relying Party finds that updates are available, it SHOULD download and process the file as described in Section 3.4.1 and initiate a new RPKI object validation process. However, a detailed description of the RPKI object validation process itself is out of scope of this document.
証明書利用者は、更新が利用可能であると判断した場合、セクション3.4.1で説明されているようにファイルをダウンロードして処理し、新しいRPKIオブジェクト検証プロセスを開始する必要があります。ただし、RPKIオブジェクト検証プロセス自体の詳細な説明は、このドキュメントの範囲外です。
If a Relying Party experiences any issues with retrieving or processing any of the files used in this protocol, it will be unable to retrieve new RPKI data from the affected Repository Server.
証明書利用者がこのプロトコルで使用されるファイルの取得または処理に問題を経験した場合、影響を受けるリポジトリサーバーから新しいRPKIデータを取得できません。
Relying Parties could attempt to use alternative repository access mechanisms, if they are available, according to the accessMethod element value(s) specified in the SIA of the associated certificate (see Section 4.8.8 of [RFC6487]).
証明書利用者は、利用可能な場合、関連する証明書のSIAで指定されているaccessMethod要素の値に従って、代替リポジトリアクセスメカニズムの使用を試みる可能性があります（[RFC6487]のセクション4.8.8を参照）。
Furthermore, Relying Parties may wish to employ re-try strategies while fetching RRDP files. Relying Parties are also advised to keep old objects in their local cache so that validation can be done using old objects.
さらに、依拠当事者は、RRDPファイルをフェッチする際に再試行戦略を採用したい場合があります。依拠当事者は、古いオブジェクトを使用して検証を実行できるように、古いオブジェクトをローカルキャッシュに保持することもお勧めします。
It is also recommendable that re-validation and retrieval is performed pro-actively before manifests or CRLs go stale, or certificates expire, to ensure that problems on the side of the Relying Party can be identified and resolved before they cause major concerns.
マニフェストやCRLが古くなる前、または証明書の期限が切れる前に再検証と取得をプロアクティブに実行して、証明書利用者側の問題が重大な問題を引き起こす前に特定および解決できるようにすることもお勧めします。
The Update Notification File is used by Relying Parties to discover whether any changes exist between the state of the repository and the Relying Party's cache. It describes the location of the files containing the snapshot and incremental deltas, which can be used by the Relying Party to synchronize with the repository.
更新通知ファイルは、リポジトリの状態と証明書利用者のキャッシュの間に変更が存在するかどうかを検出するために証明書利用者によって使用されます。依存パーティがリポジトリと同期するために使用できる、スナップショットと増分デルタを含むファイルの場所について説明します。
A Repository Server MAY use caching infrastructure to cache the Update Notification File and reduce the load of HTTPS requests. However, since this file is used by Relying Parties to determine whether any updates are available, the Repository Server SHOULD ensure that this file is not cached for longer than 1 minute. An exception to this rule is that it is better to serve a stale Update Notification File rather than no Update Notification File.
リポジトリサーバーは、キャッシュインフラストラクチャを使用して、更新通知ファイルをキャッシュし、HTTPS要求の負荷を軽減できます。ただし、このファイルは依存パーティによって更新が利用可能かどうかを判断するために使用されるため、リポジトリサーバーは、このファイルが1分以上キャッシュされないようにする必要があります。このルールの例外は、更新通知ファイルがないよりも、古い更新通知ファイルを提供するほうがよいことです。
How this is achieved exactly depends on the caching infrastructure used. In general, a Repository Server may find certain HTTP headers to be useful, such as: "Cache-Control: max-age=60" (see Section 5.2 of [RFC7234]). Another approach can be to have the Repository Server push out new versions of the Update Notification File to the caching infrastructure when appropriate.
これがどのように達成されるかは、使用されるキャッシングインフラストラクチャによって異なります。一般に、リポジトリサーバーは、「Cache-Control：max-age = 60」（[RFC7234]のセクション5.2を参照）など、特定のHTTPヘッダーが役立つと感じる場合があります。別のアプローチとして、適切な場合、リポジトリサーバーに新しいバージョンの更新通知ファイルをキャッシュインフラストラクチャにプッシュさせるという方法もあります。
In case of a high load on a Repository Server or its distribution network, the Cache-Control HTTP header, or a similar mechanism, MAY be used to suggest an optimal (for the Repository Server) poll interval for Relying Parties. However, setting it to an interval longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align the suggested interval with their operational practices and the expected update frequency of RPKI repository data and MAY discard the suggested value.
リポジトリサーバーまたはその配布ネットワークの負荷が高い場合、Cache-Control HTTPヘッダー、または同様のメカニズムを使用して、依拠当事者に最適な（リポジトリサーバーの）ポーリング間隔を提案できます。ただし、1時間より長い間隔に設定することはお勧めしません。依拠当事者は、提案された間隔を運用慣行およびRPKIリポジトリデータの予想される更新頻度に合わせ、提案された値を破棄する必要があります（SHOULD）。
Example Update Notification File:
更新通知ファイルの例：
<notification xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<snapshot uri="https://host/9d-8/3/snapshot.xml" hash="AB"/>
<delta serial="3" uri="https://host/9d-8/3/delta.xml" hash="CD"/>
<delta serial="2" uri="https://host/9d-8/2/delta.xml" hash="EF"/>
</notification>
Note: URIs and hash values in this example are shortened because of formatting.
注：この例のURIとハッシュ値は、フォーマットのために短縮されています。
The following validation rules MUST be observed when creating or parsing Update Notification Files:
更新通知ファイルを作成または解析するときは、次の検証ルールを遵守する必要があります。
o A Relying Party MUST reject any Update Notification File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 依拠当事者は、このドキュメントのセクション3.5.4で概説されているRELAX NGスキーマに準拠していない、または整形式でない更新通知ファイルを拒否する必要があります。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML名前空間は「http://www.ripe.net/rpki/rrdp」でなければなりません。
o The encoding MUST be "US-ASCII".
o エンコーディングは「US-ASCII」でなければなりません。
o The version attribute in the notification root element MUST be "1".
o 通知ルート要素のバージョン属性は「1」でなければなりません。
o The session_id attribute MUST be a random version 4 UUID [RFC4122], unique to this session.
o session_id属性は、このセッションに固有のランダムなバージョン4 UUID [RFC4122]でなければなりません。
o The serial attribute MUST be an unbounded, unsigned positive integer in decimal format indicating the current version of the repository.
o シリアル属性は、リポジトリの現在のバージョンを示す10進形式の無制限の符号なし正整数である必要があります。
o The Update Notification File MUST contain exactly one 'snapshot' element for the current repository version.
o 更新通知ファイルには、現在のリポジトリバージョンの「スナップショット」要素を1つだけ含める必要があります。
o If delta elements are included, they MUST form a contiguous sequence of serial numbers starting at a revision determined by the Repository Server, up to the serial number mentioned in the notification element. Note that the elements may not be ordered.
o デルタ要素が含まれている場合、それらは、通知要素で言及されているシリアル番号までの、リポジトリサーバーによって決定されたリビジョンから始まるシリアル番号の連続したシーケンスを形成する必要があります。要素は順序付けられない場合があることに注意してください。
o The hash attribute in snapshot and delta elements MUST be the hexadecimal encoding of the SHA-256 [SHS] hash of the referenced file. The Relying Party MUST verify this hash when the file is retrieved and reject the file if the hash does not match.
o スナップショットおよびデルタ要素のハッシュ属性は、参照されるファイルのSHA-256 [SHS]ハッシュの16進エンコーディングである必要があります。証明書利用者は、ファイルを取得するときにこのハッシュを検証し、ハッシュが一致しない場合はファイルを拒否する必要があります。
A snapshot is intended to reflect the complete and current contents of the repository for a specific session and version. Therefore, it MUST contain all objects from the repository current as of the time of the publication.
スナップショットは、特定のセッションとバージョンのリポジトリの完全で現在の内容を反映することを目的としています。したがって、公開時の最新のリポジトリからのすべてのオブジェクトを含める必要があります。
A snapshot reflects the content of the repository at a specific point in time; for that reason, it can be considered immutable data. Snapshot Files MUST be published at a URL that is unique to the specific session and serial.
スナップショットは、特定の時点でのリポジトリのコンテンツを反映しています。そのため、不変データと見なすことができます。スナップショットファイルは、特定のセッションおよびシリアルに固有のURLで公開する必要があります。
Because these files never change, they MAY be cached indefinitely. However, in order to prevent these files from using a lot of space in the caching infrastructure, it is RECOMMENDED that a limited interval is used in the order of hours or days.
これらのファイルは決して変更されないため、無期限にキャッシュされる場合があります。ただし、これらのファイルがキャッシングインフラストラクチャで多くのスペースを使用しないようにするために、時間または日単位で限られた間隔を使用することをお勧めします。
To avoid race conditions where a Relying Party downloads an Update Notification File moments before it's updated, Repository Servers SHOULD retain old Snapshot Files for at least 5 minutes after a new Update Notification File is published.
証明書利用者が更新通知ファイルを更新する直前にダウンロードするという競合状態を回避するために、リポジトリサーバーは、新しい更新通知ファイルが公開されてから少なくとも5分間、古いスナップショットファイルを保持する必要があります。
Example Snapshot File:
スナップショットファイルの例：
<snapshot xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="2">
<publish uri="rsync://rpki.ripe.net/Alice/Bob.cer">
ZXhhbXBsZTE=
</publish>
<publish uri="rsync://rpki.ripe.net/Alice/Alice.mft">
ZXhhbXBsZTI=
</publish>
<publish uri="rsync://rpki.ripe.net/Alice/Alice.crl">
ZXhhbXBsZTM=
</publish>
</snapshot>
The following rules MUST be observed when creating or parsing Snapshot Files:
スナップショットファイルを作成または解析するときは、次の規則を遵守する必要があります。
o A Relying Party MUST reject any Snapshot File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 証明書利用者は、このドキュメントのセクション3.5.4で概説されているRELAX NGスキーマに準拠していない、または整形式でないスナップショットファイルを拒否する必要があります。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML名前空間は「http://www.ripe.net/rpki/rrdp」でなければなりません。
o The encoding MUST be "US-ASCII".
o エンコーディングは「US-ASCII」でなければなりません。
o The version attribute in the notification root element MUST be "1".
o 通知ルート要素のバージョン属性は「1」でなければなりません。
o The session_id attribute MUST match the expected session_id in the reference in the Update Notification File.
o session_id属性は、更新通知ファイルの参照で予期されるsession_idと一致する必要があります。
o The serial attribute MUST match the expected serial in the reference in the Update Notification File.
o シリアル属性は、更新通知ファイルの参照で予期されるシリアルと一致する必要があります。
o Note that the publish element is similar to the publish element defined in the publication protocol [RFC8181]. However, the "tag" attribute is not used here because it is not relevant to Relying Parties. The "hash" attribute is not used here because this file represents a complete current state of the repository; therefore, it is not relevant to know which existing RPKI object (if any) is updated.
o publish要素は、公開プロトコル[RFC8181]で定義されているpublish要素に似ていることに注意してください。ただし、「タグ」属性は依拠当事者には関係がないため、ここでは使用しません。このファイルはリポジトリの完全な現在の状態を表すため、「ハッシュ」属性はここでは使用されません。したがって、更新されている既存のRPKIオブジェクト（存在する場合）を知ることは重要ではありません。
An incremental Delta File contains all changes for exactly one serial increment of the Repository Server. In other words, a single delta will typically include all the new objects, updated objects, and withdrawn objects that a Certification Authority sent to the Repository Server. In its simplest form, the update could concern only a single object, but it is RECOMMENDED that CAs send all changes for one of their key pairs (updated objects as well as a new manifest and CRL) as one atomic update message.
インクリメンタルデルタファイルには、リポジトリサーバーの1つのシリアルインクリメントに対するすべての変更が含まれます。つまり、単一のデルタには、通常、認証局がリポジトリサーバーに送信したすべての新しいオブジェクト、更新されたオブジェクト、および撤回されたオブジェクトが含まれます。最も単純な形式では、更新は単一のオブジェクトのみに関係しますが、CAはキーペアの1つに対するすべての変更（更新されたオブジェクトと新しいマニフェストおよびCRL）を1つのアトミック更新メッセージとして送信することをお勧めします。
Deltas reflect the difference between two consecutive versions of a repository for a given session. For that reason, deltas can be considered immutable data. Delta Files MUST be published at a URL that is unique to the specific session and serial.
デルタは、特定のセッションのリポジトリの2つの連続したバージョン間の違いを反映しています。そのため、デルタは不変のデータと見なすことができます。 Deltaファイルは、特定のセッションとシリアルに固有のURLで公開する必要があります。
Because these files never change, they MAY be cached indefinitely. However, in order to prevent these files from using a lot of space in the caching infrastructure, it is RECOMMENDED that a limited interval is used in the order of hours or days.
これらのファイルは決して変更されないため、無期限にキャッシュされる場合があります。ただし、これらのファイルがキャッシングインフラストラクチャで多くのスペースを使用しないようにするために、時間または日単位で限られた間隔を使用することをお勧めします。
To avoid race conditions where a Relying Party downloads an Update Notification File moments before it's updated, Repository Servers SHOULD retain old Delta Files for at least 5 minutes after they are no longer included in the latest Update Notification File.
証明書利用者が更新通知ファイルを更新する直前にダウンロードするという競合状態を回避するために、リポジトリサーバーは、最新の更新通知ファイルに含まれていない古いデルタファイルを少なくとも5分間保持する必要があります。
Example Delta File:
Deltaファイルの例：
<delta xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.mft"
hash="50d8...545c">
ZXhhbXBsZTQ=
</publish>
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.crl"
hash="5fb1...6a56">
ZXhhbXBsZTU=
</publish>
<withdraw uri="rsync://rpki.ripe.net/repo/Alice/Bob.cer"
hash="caeb...15c1"/>
</delta>
Note that a formal RELAX NG specification of this file format is included later in this document. A Relying Party MUST NOT process any Delta File that is incomplete or not well-formed.
このファイル形式の正式なRELAX NG仕様は、このドキュメントの後半に含まれています。依拠当事者は、不完全な、または整形式でないデルタファイルを処理してはなりません。
The following validation rules MUST be observed when creating or parsing Delta Files:
Deltaファイルを作成または解析するときは、次の検証ルールを遵守する必要があります。
o A Relying Party MUST reject any Delta File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 証明書利用者は、このドキュメントのセクション3.5.4で概説されているRELAX NGスキーマに準拠していない、または整形式でないDeltaファイルを拒否する必要があります。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML名前空間は「http://www.ripe.net/rpki/rrdp」でなければなりません。
o The encoding MUST be "US-ASCII".
o エンコーディングは「US-ASCII」でなければなりません。
o The version attribute in the delta root element MUST be "1".
o デルタルート要素のバージョン属性は「1」でなければなりません。
o The session_id attribute MUST be a random version 4 UUID unique to this session.
o session_id属性は、このセッションに固有のランダムなバージョン4 UUIDでなければなりません。
o The session_id attribute MUST match the expected session_id in the reference in the Update Notification File.
o session_id属性は、更新通知ファイルの参照で予期されるsession_idと一致する必要があります。
o The serial attribute MUST match the expected serial in the reference in the Update Notification File.
o シリアル属性は、更新通知ファイルの参照で予期されるシリアルと一致する必要があります。
o Note that the publish element is similar to the publish element defined in the publication protocol [RFC8181]. However, the "tag" attribute is not used here because it is not relevant to Relying Parties.
o publish要素は、公開プロトコル[RFC8181]で定義されているpublish要素に似ていることに注意してください。ただし、「タグ」属性は依拠当事者には関係がないため、ここでは使用しません。
The following is a RELAX NG compact form schema describing version 1 of this protocol.
以下は、このプロトコルのバージョン1を説明するRELAX NGコンパクトフォームスキーマです。
# # RELAX NG schema for the RPKI Repository Delta Protocol (RRDP). #
＃＃RPKIリポジトリデルタプロトコル（RRDP）のRELAX NGスキーマ。 ＃
default namespace = "http://www.ripe.net/rpki/rrdp"
version = xsd:positiveInteger { maxInclusive="1" }
serial = xsd:positiveInteger
uri = xsd:anyURI
uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" }
hash = xsd:string { pattern = "[0-9a-fA-F]+" }
base64 = xsd:base64Binary
# Notification File: lists current snapshots and deltas.
＃通知ファイル：現在のスナップショットとデルタを一覧表示します。
start |= element notification {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element snapshot {
attribute uri { uri },
attribute hash { hash }
},
element delta {
attribute serial { serial },
attribute uri { uri },
attribute hash { hash }
}*
}
# Snapshot segment: think DNS AXFR.
＃スナップショットセグメント：DNS AXFRと考えてください。
start |= element snapshot {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element publish {
attribute uri { uri },
base64
}*
}
# Delta segment: think DNS IXFR.
＃Deltaセグメント：DNS IXFRと考えてください。
start |= element delta {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
delta_element+
}
delta_element |= element publish {
attribute uri { uri },
attribute hash { hash }?,
base64
}
delta_element |= element withdraw {
attribute uri { uri },
attribute hash { hash }
}
# Local Variables: # indent-tabs-mode: nil # comment-start: "# " # comment-start-skip: "#[ \t]*" # End:
＃ローカル変数：＃indent-tabs-mode：nil＃コメント開始： "＃"＃コメント開始スキップ： "＃[\ t] *"＃終了：
This protocol has been designed to replace rsync as a distribution mechanism of an RPKI repository. However, it is also designed to coexist with existing implementations based on rsync, to enable smooth transition from one distribution mechanism to another.
このプロトコルは、RPKIリポジトリの配布メカニズムとしてrsyncを置き換えるように設計されています。ただし、1つの配布メカニズムから別の配布メカニズムへのスムーズな移行を可能にするために、rsyncに基づく既存の実装と共存するように設計されています。
For every repository object listed in the Snapshot and Delta Files, both the hash of the object's content and the rsync URI [RFC5781] of its location in the repository are listed. This makes it possible to distribute the same RPKI repository, represented by a set of files on a filesystem, using both rsync and RRDP. It also enables Relying Parties tools to query, combine, and consequently validate objects from repositories of different types.
スナップショットファイルとデルタファイルにリストされているすべてのリポジトリオブジェクトについて、オブジェクトのコンテンツのハッシュとリポジトリ内の場所のrsync URI [RFC5781]の両方がリストされます。これにより、rsyncとRRDPの両方を使用して、ファイルシステム上の一連のファイルで表される同じRPKIリポジトリを配布できます。また、依存パーティツールは、さまざまなタイプのリポジトリからオブジェクトを照会、結合、および検証できます。
One of the design goals of RRDP was to minimize load on a Repository Server while serving clients. To achieve this, neither the content nor the URLs of the Snapshot and Delta Files are modified after they have been published in the Update Notification File. This allows their effective distribution by using either a single HTTP server or a CDN.
RRDPの設計目標の1つは、クライアントにサービスを提供しながらリポジトリサーバーの負荷を最小限に抑えることでした。これを実現するために、スナップショットファイルとデルタファイルのコンテンツもURLも、更新通知ファイルで公開された後は変更されません。これにより、単一のHTTPサーバーまたはCDNを使用して効果的に配布できます。
The RECOMMENDED way for Relying Parties to keep up with the repository updates is to poll the Update Notification File for changes. The content of that file is updated with every new serial version of a repository (while its URL remains stable). To effectively implement distribution of the Update Notification File, an "If-Modified-Since" HTTP request header is required to be present in all requests for the Update Notification File (see Section 3.4.4). Therefore, it is RECOMMENDED that Relying Party tools implement a mechanism to keep track of a previous successful fetch of an Update Notification File.
依拠当事者がリポジトリの更新についていくための推奨される方法は、変更について更新通知ファイルをポーリングすることです。そのファイルのコンテンツは、リポジトリの新しいシリアルバージョンごとに更新されます（そのURLは安定したままです）。更新通知ファイルの配布を効果的に実装するには、「If-Modified-Since」HTTP要求ヘッダーが更新通知ファイルのすべての要求に存在する必要があります（セクション3.4.4を参照）。したがって、証明書利用者ツールが、更新通知ファイルの以前の正常なフェッチを追跡するメカニズムを実装することをお勧めします。
Implementations of RRDP should also take care of not producing new versions of the repository (and subsequently, new Update Notification, Snapshot, and Delta Files) too often. Usually the maintenance of the RPKI repository includes regular updates of manifest and CRL objects performed on a schedule. This often results in bursts of repository updates during a short period of time. Since the Relying Parties are required to poll for the Update Notification File not more often than once per minute (Section 3.4.4), it is not practical to generate new serial versions of the repository much more often than 1 per minute. It is allowed to combine multiple updates, possibly from different CAs, into a new serial repository version (Section 3.3.2). This will significantly shorten the size of the Update Notification File and total amount of data distributed to all Relying Parties.
RRDPの実装では、リポジトリの新しいバージョン（およびその後、新しい更新通知、スナップショット、デルタファイル）を頻繁に作成しないように注意する必要があります。通常、RPKIリポジトリのメンテナンスには、定期的に実行されるマニフェストとCRLオブジェクトの定期的な更新が含まれます。これにより、多くの場合、短期間でリポジトリ更新のバーストが発生します。依拠当事者は、更新通知ファイルをポーリングする頻度が1分に1回以下であるため（セクション3.4.4）、リポジトリの新しいシリアルバージョンを1分に1回よりも頻繁に生成することは現実的ではありません。異なるCAからの複数の更新を組み合わせて、新しいシリアルリポジトリバージョンにすることができます（セクション3.3.2）。これにより、更新通知ファイルのサイズとすべての依拠当事者に配布されるデータの総量が大幅に削減されます。
Note that a Man in the Middle (MITM) cannot produce validly signed RPKI data but can perform withhold or replay attacks targeting a Relying Party and keep the Relying Party from learning about changes in the RPKI. Because of this, Relying Parties SHOULD do TLS certificate and host name validation when they fetch from an RRDP Repository Server.
Man in the Middle（MITM）は、有効に署名されたRPKIデータを生成できませんが、依存パーティをターゲットとする保留またはリプレイ攻撃を実行し、依存パーティがRPKIの変更について学習できないようにすることができます。このため、証明書利用者は、RRDPリポジトリサーバーからフェッチするときに、TLS証明書とホスト名の検証を行う必要があります（SHOULD）。
Relying Party tools SHOULD log any TLS certificate or host name validation issues found, so that an operator can investigate the cause. However, such validation issues are often due to configuration errors or a lack of a common TLS trust anchor. In these cases, it is better if the Relying Party retrieves the signed RPKI data regardless and performs validation on it. Therefore, the Relying Party MUST continue to retrieve the data in case of errors. The Relying Party MAY choose to log encountered issues only when fetching the Update Notification File, but not when it subsequently fetches Snapshot or Delta Files from the same host. Furthermore, the Relying Party MAY provide a way for operators to accept untrusted connections for a given host, after the cause has been identified.
証明書利用者のツールは、見つかったTLS証明書またはホスト名検証の問題をログに記録して、オペレーターが原因を調査できるようにする必要があります。ただし、このような検証の問題は、多くの場合、構成エラーまたは一般的なTLSトラストアンカーの欠如が原因です。これらの場合、依拠当事者が署名付きRPKIデータを取得して検証を実行する方が良いでしょう。したがって、依存パーティは、エラーが発生した場合に引き続きデータを取得する必要があります。証明書利用者は、更新通知ファイルをフェッチするときにのみ、発生した問題をログに記録することを選択できますが、その後同じホストからスナップショットまたはデルタファイルをフェッチするときはログに記録しません。さらに、依拠当事者は、原因が特定された後、オペレーターが特定のホストの信頼できない接続を受け入れる方法を提供する場合があります。
It is RECOMMENDED that Relying Parties and Repository Servers follow the Best Current Practices outlined in [RFC7525] on the use of HTTP over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS certificate and host name validation using subjectAltName dNSName identities as described in [RFC6125]. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
証明書利用者とリポジトリサーバーは、HTTP over TLS（HTTPS）[RFC7230]の使用に関して、[RFC7525]で概説されている現在のベストプラクティスに従うことをお勧めします。依拠当事者は、[RFC6125]で説明されているように、subjectAltName dNSName IDを使用してTLS証明書とホスト名の検証を行う必要があります（SHOULD）。 [RFC6125]で定義されているルールとガイドラインは、次の点を考慮してここに適用されます。
o Relying Parties and Repository Servers SHOULD support the DNS-ID identifier type. The DNS-ID identifier type SHOULD be present in Repository Server certificates.
o 依存パーティとリポジトリサーバーは、DNS-ID識別子タイプをサポートする必要があります（SHOULD）。 DNS-ID識別子タイプは、リポジトリサーバー証明書に存在する必要があります（SHOULD）。
o DNS names in Repository Server certificates SHOULD NOT contain the wildcard character "*".
o リポジトリサーバー証明書のDNS名には、ワイルドカード文字「*」を含めないでください。
o A Common Name (CN) field may be present in a Repository Server certificate's subject name but SHOULD NOT be used for authentication within the rules described in [RFC6125].
o Common Name（CN）フィールドは、Repository Server証明書のサブジェクト名に存在する場合がありますが、[RFC6125]で説明されているルール内の認証には使用しないでください。
o This protocol does not require the use of SRV-IDs.
o このプロトコルでは、SRV-IDを使用する必要はありません。
o This protocol does not require the use of URI-IDs.
o このプロトコルでは、URI-IDを使用する必要はありません。
Note, however, that this validation is done on a best-effort basis and serves to highlight potential issues, but RPKI object security does not depend on this. Therefore, Relying Parties MAY deviate from the validation steps listed above.
ただし、この検証はベストエフォートベースで行われ、潜在的な問題を強調するのに役立ちますが、RPKIオブジェクトのセキュリティはこれに依存しないことに注意してください。したがって、依拠当事者は、上記の検証手順から逸脱する場合があります。
RRDP deals exclusively with the transfer of RPKI objects from a Repository Server to a Relying Party. The trust relation between a Certificate Authority and its Repository Server is out of scope for this document. However, it should be noted that from a Relying Party point of view, all RPKI objects (certificates, CRLs, and objects wrapped in Cryptographic Message Syntax (CMS)) are already covered by object security mechanisms including signed manifests. This allows validation of these objects even though the Repository Server itself is not trusted. This document makes no change to RPKI validation procedures per se.
RRDPは、リポジトリサーバーから証明書利用者へのRPKIオブジェクトの転送のみを扱います。認証局とそのリポジトリサーバー間の信頼関係は、このドキュメントの範囲外です。ただし、証明書利用者の観点からは、すべてのRPKIオブジェクト（証明書、CRL、および暗号化メッセージ構文（CMS）でラップされたオブジェクト）は、署名済みマニフェストを含むオブジェクトセキュリティメカニズムによってすでにカバーされていることに注意してください。これにより、Repository Server自体が信頼されていなくても、これらのオブジェクトを検証できます。このドキュメントでは、RPKI検証手順自体は変更されません。
The original RPKI transport protocol is rsync, which offers no channel security mechanism. RRDP replaces the use of rsync by HTTPS; while the channel security mechanism underlying RRDP (HTTPS) is not a cure-all, it does make some forms of denial-of-service attacks more difficult for the attacker. HTTPS issues are discussed in more detail in Section 4.3.
元のRPKIトランスポートプロトコルはrsyncで、チャネルセキュリティメカニズムを提供していません。 RRDPは、rsyncの使用をHTTPSに置き換えます。 RRDP（HTTPS）の基礎となるチャネルセキュリティメカニズムは万能薬ではありませんが、攻撃者にとって、サービス拒否攻撃のいくつかの形態がより困難になります。 HTTPSの問題については、セクション4.3で詳しく説明します。
Supporting both RRDP and rsync necessarily increases the number of opportunities for a malicious RPKI Certificate Authority to perform denial-of-service attacks on Relying Parties, by expanding the number of URIs which the Relying Party may need to contact in order to complete a validation run. However, other than the relative cost of HTTPS versus rsync, adding RRDP to the mix does not change this picture significantly: with either RRDP or rsync a malicious Certificate Authority can supply an effectively infinite series of URIs for the Relying Party to follow. The only real solution to this is for the Relying Party to apply some kind of bound to the amount of work it is willing to do. Note also that the attacker in this scenario must be an RPKI Certificate Authority; otherwise, the normal RPKI object security checks would reject the malicious URIs.
RRDPとrsyncの両方をサポートすると、検証の実行を完了するために証明書利用者が連絡する必要があるURIの数を拡大することにより、悪意のあるRPKI認証局が証明書利用者に対してサービス拒否攻撃を実行する機会の数が必然的に増加します。 。ただし、HTTPSとrsyncの相対的なコストを除いて、RRDPをミックスに追加しても、この状況は大きく変わりません。RRDPまたはrsyncのいずれかを使用すると、悪意のある認証局が依存する一連のURIを事実上無限に提供できます。これに対する唯一の真の解決策は、依拠当事者が、実行しようとする仕事の量にある種の制限を適用することです。このシナリオの攻撃者はRPKI認証局でなければならないことにも注意してください。そうしないと、通常のRPKIオブジェクトのセキュリティチェックで悪意のあるURIが拒否されます。
Processing costs for objects retrieved using RRDP may be somewhat different from the same objects retrieved using rsync: because RRDP treats an entire set of changes as a unit (one "delta"), it may not be practical to start processing any of the objects in the delta until the entire delta has been received. With rsync, by contrast, incremental processing may be easy, but the overall cost of transfer may be higher, as may be the number of corner cases in which the Relying Party retrieves some but not all of the updated objects. Overall, RRDP's behavior is closer to a proper transactional system, which (probably) leads to an overall reliability increase.
RRDPを使用して取得したオブジェクトの処理コストは、rsyncを使用して取得した同じオブジェクトとは多少異なる場合があります。RRDPは変更のセット全体を1つの単位（1つの「デルタ」）として扱うため、オブジェクトの処理を開始するのは現実的ではない場合がありますデルタ全体が受信されるまでデルタ。対照的に、rsyncを使用すると、増分処理は簡単になりますが、依存パーティが更新されたオブジェクトのすべてではなく一部を取得するコーナーケースの数と同様に、全体的な転送コストは高くなる可能性があります。全体として、RRDPの動作は適切なトランザクションシステムに近いため、（おそらく）全体的な信頼性が向上します。
RRDP is designed to scale much better than rsync. In particular, RRDP is designed to allow use of an HTTPS caching infrastructure to reduce load on primary Repository Servers and increase resilience against denial-of-service attacks on the RPKI publication service.
RRDPは、rsyncよりもはるかに優れた拡張性を持つように設計されています。特に、RRDPは、HTTPSキャッシングインフラストラクチャを使用してプライマリリポジトリサーバーの負荷を軽減し、RPKIパブリケーションサービスに対するサービス拒否攻撃に対する回復力を高めるように設計されています。
IANA has updated the reference for id-ad-rpkiNotify to point to this document in the "SMI Security for PKIX Access Descriptor" registry [IANA-AD-NUMBERS].
IANAは、id-ad-rpkiNotifyの参照を更新して、「PKIXアクセス記述子のSMIセキュリティ」レジストリ[IANA-AD-NUMBERS]でこのドキュメントを指すようにしました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「A Universally Unique Identifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<http：//www.rfc- editor.org/info/rfc4122>。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <http://www.rfc-editor.org/info/rfc5781>.
[RFC5781] Weiler、S.、Ward、D。、およびR. Housley、「The rsync URI Scheme」、RFC 5781、DOI 10.17487 / RFC5781、2010年2月、<http://www.rfc-editor.org/info / rfc5781>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <http://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<http：//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, <http://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<http：//www.rfc- editor.org/info/rfc6487>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[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, <http://www.rfc-editor.org/info/rfc7234>.
[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 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", DOI 10.17487/RFC8181, July 2017, <http://www.rfc-editor.org/info/rfc8181>.
[RFC8181] Weiler、S.、Sonalker、A。、およびR. Austein、「A Public Protocol for the Resource Public Key Infrastructure（RPKI）」、DOI 10.17487 / RFC8181、2017年7月、<http：//www.rfc- editor.org/info/rfc8181>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[SHS]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http://nvlpubs.nist.gov/ nistpubs / FIPS / NIST.FIPS.180-4.pdf>。
[IANA-AD-NUMBERS] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <http://www.iana.org/assignments/smi-numbers>.
[IANA-AD-NUMBERS] IANA、「Structure of Management Information（SMI）Numbers（MIB Module Registrations）」、<http://www.iana.org/assignments/smi-numbers>。
[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, <http://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「リソース公開鍵インフラストラクチャ（RPKI）のマニフェスト」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<http： //www.rfc-editor.org/info/rfc6486>。
[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, <http://www.rfc-editor.org/info/rfc6488>.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）の署名済みオブジェクトテンプレート」、RFC 6488、DOI 10.17487 / RFC6488、2012年2月、<http：// www .rfc-editor.org / info / rfc6488>。
[RSYNC] "rsync", <https://rsync.samba.org>.
[RSYNC] "rsync"、<https://rsync.samba.org>。
Acknowledgements
謝辞
The authors would like to thank David Mandelberg for reviewing this document.
この文書をレビューしてくれたDavid Mandelbergに感謝します。
Authors' Addresses
著者のアドレス
Tim Bruijnzeels RIPE NCC
Tim Bruijnzeels RIPE NCC
Email: tim@ripe.net
Oleg Muravskiy RIPE NCC
オレグムラフスキーRIPE NCC
Email: oleg@ripe.net
Bryan Weber Cobenian
ブライアンウェバーコベニアン
Email: bryan@cobenian.com
Rob Austein Dragon Research Labs
ロブオースタインドラゴン研究所
Email: sra@hactrn.net