[要約] RFC 8181は、RPKIのための公開プロトコルであり、RPKIのデータの公開と配布を効率的に行うことを目的としています。このRFCは、RPKIの運用とセキュリティを向上させるための標準化を提供します。
Internet Engineering Task Force (IETF) S. Weiler
Request for Comments: 8181 W3C / MIT
Category: Standards Track A. Sonalker
ISSN: 2070-1721 STEER Tech
R. Austein
Dragon Research Labs
July 2017
A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
Resource Public Key Infrastructure（RPKI）の公開プロトコル
Abstract
概要
This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs.
このドキュメントでは、リソース公開鍵インフラストラクチャ（RPKI）オブジェクトを公開するためのプロトコルを定義します。 RPKIには多くの参加者が証明書を発行し、他のオブジェクトを作成しますが、これらのオブジェクトの公開を統合することは運用上有用です。証明書発行者が独自のパブリケーションリポジトリを実行する場合でも、パブリケーションリポジトリとは別のマシンで証明書エンジン自体を実行すると便利です。このドキュメントでは、これらのニーズに対処するプロトコルを定義しています。
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/rfc8181.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8181で入手できます。
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
1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 5
2.1. Common XML Message Format . . . . . . . . . . . . . . . . 6
2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 7
2.3. Listing the Repository . . . . . . . . . . . . . . . . . 8
2.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 8
2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9
2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. <publish/> Query, No Existing Object . . . . . . . . . . 12
3.2. <publish/> Query, Overwriting Existing Object . . . . . . 12
3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 13
3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 13
3.5. <report_error/> with Optional Elements . . . . . . . . . 13
3.6. <report_error/> without Optional Elements . . . . . . . . 14
3.7. Error Handling with Multi-Element Queries . . . . . . . . 14
3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 14
3.7.2. Successful Multi-Element Response . . . . . . . . . . 15
3.7.3. Failure Multi-Element Response, First Error Only . . 15
3.7.4. Failure Multi-Element Response, All Errors . . . . . 16
3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 16
3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document assumes a working knowledge of the Resource Public Key Infrastructure (RPKI), which is intended to support improved routing security on the Internet. See [RFC6480] for an overview of the RPKI.
このドキュメントは、インターネットでのルーティングセキュリティの向上をサポートすることを目的としたリソース公開鍵インフラストラクチャ（RPKI）の実用的な知識があることを前提としています。 RPKIの概要については、[RFC6480]を参照してください。
In order to make participation in the RPKI easier, it is helpful to have a few consolidated repositories for RPKI objects, thus saving every participant from the cost of maintaining a new service. Similarly, relying parties using the RPKI objects will find it faster and more reliable to retrieve the necessary set from a smaller number of repositories.
RPKIへの参加を簡単にするために、RPKIオブジェクト用にいくつかの統合リポジトリを用意すると、すべての参加者が新しいサービスを維持するコストを節約できます。同様に、RPKIオブジェクトを使用する証明書利用者は、必要なセットを少数のリポジトリから取得する方が高速で信頼性が高いことがわかります。
These consolidated RPKI object repositories will in many cases be outside the administrative scope of the organization issuing a given RPKI object. In some cases, outsourcing operation of the repository will be an explicit goal: some resource holders who strongly wish to control their own RPKI private keys may lack the resources to operate a 24x7 repository or may simply not wish to do so.
これらの統合されたRPKIオブジェクトリポジトリは、多くの場合、特定のRPKIオブジェクトを発行する組織の管理範囲外になります。場合によっては、リポジトリのアウトソーシング操作が明確な目標になります。独自のRPKI秘密鍵を強く制御したい一部のリソースホルダーは、24時間365日のリポジトリを操作するためのリソースがないか、単にそうしたくない場合があります。
The operator of an RPKI publication repository may well be an Internet registry which issues certificates to its customers, but it need not be; conceptually, operation of an RPKI publication repository is separate from operation of an RPKI Certification Authority (CA).
RPKIパブリケーションリポジトリの運営者は、顧客に証明書を発行するインターネットレジストリである可能性がありますが、そうである必要はありません。概念的には、RPKI発行リポジトリの操作は、RPKI認証局（CA）の操作とは別です。
Even in cases where a resource holder operates both a certificate engine and a publication repository, it can be useful to separate the two functions, as they have somewhat different operational and security requirements.
リソースホルダーが証明書エンジンとパブリケーションリポジトリの両方を操作する場合でも、操作とセキュリティの要件が多少異なるため、2つの機能を分離すると便利です。
This document defines an RPKI publication protocol which allows publication either within or across organizational boundaries and which makes fairly minimal demands on both the CA engine and the publication service.
このドキュメントでは、組織の境界内または組織の境界を越えた公開を可能にし、CAエンジンと公開サービスの両方に対する要求を最小限に抑えるRPKI公開プロトコルを定義しています。
The authentication and message integrity architecture of the publication protocol is essentially identical to the architecture used in [RFC6492] because the participants in this protocol are the same CA engines as in RFC 6492; this allows reuse of the same "Business PKI" (BPKI) (see Section 1.2) infrastructure used to support RFC 6492. As in RFC 6492, authorization is a matter of external configuration: we assume that any given publication repository has some kind of policy controlling which certificate engines are allowed to publish, modify, or withdraw particular RPKI objects, most likely following the recommendation in [RFC6480],
このプロトコルの参加者はRFC 6492と同じCAエンジンであるため、公開プロトコルの認証およびメッセージ整合性アーキテクチャは、[RFC6492]で使用されるアーキテクチャと本質的に同じです。これにより、RFC 6492のサポートに使用されるものと同じ "ビジネスPKI"（BPKI）（セクション1.2を参照）インフラストラクチャの再利用が可能になります。RFC6492と同様に、承認は外部構成の問題です。特定のパブリケーションリポジトリには何らかのポリシーがあると想定しています特定のRPKIオブジェクトを公開、変更、または撤回することを許可される証明書エンジンを制御します。おそらく[RFC6480]の推奨に従います。
Section 4.4; the details of this policy are a private matter between the operator of a certificate engine and the operator of the chosen publication repository.
セクション4.4;このポリシーの詳細は、証明書エンジンのオペレーターと選択したパブリケーションリポジトリのオペレーターの間の私的な問題です。
The following diagram attempts to convey where this publication protocol fits into the overall data flow between the certificate issuers and relying parties:
次の図は、この発行プロトコルが証明書発行者と証明書利用者の間の全体的なデータフローのどこに適合するかを示しています。
+------+ +------+ +------+
| CA | | CA | | CA |
+------+ +------+ +------+
| | | Publication protocol
| | | business relationship
+-------+ | +--------+ perhaps set up by
| | | RFC 8183
+----v---v--v-----+
| |
| Publication |
| Repository |
| |
+-----------------+ Distribution protocols
| rsync or RRDP
+--------------+----------------+
| | |
+-------v-----+ +------v------+ +------v------+
| Relying | | Relying | | Relying |
| Party | | Party | | Party |
+-------------+ +-------------+ +-------------+
The publication protocol itself is not visible to relying parties: a relying party sees the public interface of the publication server, which is an rsync or RPKI Repository Delta Protocol (RRDP) [RFC8182] server.
公開プロトコル自体は証明書利用者には見えません。証明書利用者は、rsyncまたはRPKIリポジトリデルタプロトコル（RRDP）[RFC8182]サーバーである、公開サーバーのパブリックインターフェイスを参照します。
Operators of certificate engines and publication repositories may find [RFC8183] a useful tool in setting up the pairwise relationships between these servers, but they are not required to use it.
証明書エンジンと公開リポジトリのオペレーターは、これらのサーバー間のペアワイズ関係を設定するのに役立つツール[RFC8183]を見つけるかもしれませんが、それを使用する必要はありません。
This protocol started out as an informal collaboration between several of the early RPKI implementers, and while it was always the designers' intention that the resulting protocol end up on the IETF Standards Track, it took a few years to get there because standardization of other pieces of the overall RPKI protocol space was more urgent. The Standards Track version of this publication protocol preserves the original XML namespace and protocol version scheme in order to maintain backwards compatibility with running code implemented against older versions of the specification.
このプロトコルは、初期のRPKI実装者のいくつかの間の非公式なコラボレーションとして始まり、結果として得られるプロトコルがIETF標準トラックに終わることは常に設計者の意図でしたが、他の部分の標準化のため、そこに到達するには数年かかりました全体のRPKIプロトコルスペースのうち、より緊急でした。この公開プロトコルのStandards Trackバージョンは、仕様の古いバージョンに対して実装された実行中のコードとの下位互換性を維持するために、元のXML名前空間とプロトコルバージョンスキームを保持します。
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]で説明されているように解釈されます。
"Publication engine" and "publication server" are used interchangeably to refer to the server providing the service described in this document.
「パブリケーションエンジン」と「パブリケーションサーバー」は、このドキュメントで説明されているサービスを提供するサーバーを指すために互換的に使用されます。
"Business Public Key Infrastructure" ("Business PKI" or "BPKI") refers to a PKI, separate from the RPKI, used to authenticate clients to the publication engine. We use the term "Business PKI" here because an Internet registry might already have a PKI for authenticating its clients and might wish to reuse that PKI for this protocol. There is, however, no requirement to reuse such a PKI.
「ビジネス公開鍵インフラストラクチャ」（「ビジネスPKI」または「BPKI」）は、RPKIとは別の、公開エンジンに対してクライアントを認証するために使用されるPKIを指します。ここでは「ビジネスPKI」という用語を使用します。インターネットレジストリがクライアントを認証するためのPKIをすでに持っている場合があり、このPKIをこのプロトコルに再利用したい場合があるためです。ただし、そのようなPKIを再利用する必要はありません。
The publication protocol uses XML [XML] messages wrapped in signed Cryptographic Message Syntax (CMS) messages, carried over HTTP transport [RFC7230]. The CMS encapsulation is identical to that used in Section 3.1 (and subsections) of RFC 6492 [RFC6492].
公開プロトコルは、HTTPトランスポート[RFC7230]を介して伝送される、署名された暗号メッセージ構文（CMS）メッセージにラップされたXML [XML]メッセージを使用します。 CMSカプセル化は、RFC 6492 [RFC6492]のセクション3.1（およびサブセクション）で使用されているものと同じです。
The publication protocol uses a simple request/response interaction. The client passes a request to the server, and the server generates a corresponding response.
公開プロトコルは、単純な要求/応答相互作用を使用します。クライアントはリクエストをサーバーに渡し、サーバーは対応するレスポンスを生成します。
A message exchange commences with the client initiating an HTTP POST with a content type of "application/rpki-publication", with the message object as the body. The server's response will similarly be the body of the response with a content type of "application/ rpki-publication".
メッセージ交換は、クライアントが本文タイプとして「application / rpki-publication」のコンテンツタイプを使用してHTTP POSTを開始することから始まります。サーバーの応答も同様に、 "application / rpki-publication"のコンテンツタイプを持つ応答の本文になります。
The content of the POST and the server's response will be a well-formed CMS [RFC5652] object with OID = 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].
[RFC6492]のセクション3.1で説明されているように、POSTの内容とサーバーの応答は、OID = 1.2.840.113549.1.7.2の整形式CMS [RFC5652]オブジェクトになります。
The CMS signatures are used to protect the integrity of the protocol messages and to authenticate the client and server to each other. Authorization to perform particular operations is a local matter, perhaps determined by contractual agreements between the operators of any particular client-server pair, but in any case is beyond the scope of this specification.
CMS署名は、プロトコルメッセージの整合性を保護し、クライアントとサーバーを相互に認証するために使用されます。特定の操作を実行するための許可はローカルな問題であり、おそらく特定のクライアント/サーバーペアのオペレーター間の契約上の合意によって決定されますが、いずれの場合もこの仕様の範囲を超えています。
The XML schema for this protocol is below in Section 2.6. The basic XML message format looks like this:
このプロトコルのXMLスキーマはセクション2.6にあります。基本的なXMLメッセージ形式は次のようになります。
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- Zero or more PDUs -->
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- Zero or more PDUs -->
</msg>
As noted above, the outermost XML element is encapsulated in a signed CMS message. Query messages are signed by the client, and reply messages are signed by the server.
上記のように、最も外側のXML要素は、署名されたCMSメッセージにカプセル化されます。クエリメッセージはクライアントによって署名され、応答メッセージはサーバーによって署名されます。
Common attributes:
一般的な属性：
version: The value of this attribute is the version of this protocol. This document describes version 4.
version：この属性の値は、このプロトコルのバージョンです。このドキュメントでは、バージョン4について説明します。
type: The possible values of this attribute are "reply" and "query".
type：この属性の可能な値は「reply」と「query」です。
A query PDU may be one of three types: <publish/>, <withdraw/>, or <list/>.
クエリPDUは、<publish />、<withdraw />、または<list />の3つのタイプのいずれかになります。
A reply PDU may be one of three types: <success/>, <list/>, or <report_error/>.
応答PDUは、<success />、<list />、または<report_error />の3つのタイプのいずれかになります。
The <publish/> and <withdraw/> PDUs include a "tag" attribute to facilitate bulk operation. When performing bulk operations, a CA engine will probably find it useful to specify a distinct tag value for each <publish/> or <withdraw/> PDU, to simplify matching an error with the PDU which triggered it. The tag attribute is mandatory, to simplify parsing, but a CA engine which has no particular use for tagging MAY use any syntactically legal value, including simply using the empty string for all tag fields.
<publish />および<withdraw /> PDUには、一括操作を容易にするための「タグ」属性が含まれています。バルク操作を実行するとき、CAエンジンは、<publish />または<withdraw /> PDUごとに個別のタグ値を指定すると、エラーをトリガーしたPDUとエラーを簡単に照合できるため便利です。解析を簡略化するためにタグ属性は必須ですが、タグ付けに特に使用しないCAエンジンは、すべてのタグフィールドに空の文字列を単に使用するなど、構文的に正当な値を使用できます。
This document describes version 4 of this protocol. An implementation which understands only this version of the protocol MUST reject messages with a different protocol version attribute, signaling the error as described in Section 2.4. Since "4" is currently the only value allowed for the version attribute in the schema (Section 2.6), an incorrect protocol version can be detected either by checking the version attribute directly or as a schema validation error. Any future update to this protocol which is either syntactically or semantically incompatible with the current version will need to increment the protocol version number.
このドキュメントでは、このプロトコルのバージョン4について説明します。このバージョンのプロトコルのみを理解する実装は、セクション2.4で説明されているように、異なるプロトコルバージョン属性を持つメッセージを拒否し、エラーを通知する必要があります。 "4"は現在、スキーマ（セクション2.6）のバージョン属性に許可されている唯一の値であるため、バージョン属性を直接チェックするか、スキーマ検証エラーとして、不正なプロトコルバージョンを検出できます。現在のバージョンと構文的または意味的に互換性がないこのプロトコルへの将来の更新は、プロトコルのバージョン番号を増やす必要があります。
The publication protocol uses a common message format to request publication of any RPKI object. This format was chosen specifically to allow this protocol to accommodate new types of RPKI objects without needing changes to this protocol.
公開プロトコルは、一般的なメッセージ形式を使用して、RPKIオブジェクトの公開を要求します。このプロトコルは、このプロトコルを変更せずに新しいタイプのRPKIオブジェクトに対応できるようにするために特別に選択されました。
Both the <publish/> and <withdraw/> PDUs have a payload of a tag and an rsync URI [RFC3986] [RFC5781]. The <publish/> query also contains the DER object to be published, encoded in Base64 ([RFC4648], Section 4, with line breaks within the Base64 text permitted but not required).
<publish />と<withdraw />の両方のPDUには、タグのペイロードとrsync URI [RFC3986] [RFC5781]があります。 <publish />クエリには、公開するDERオブジェクトも含まれ、Base64でエンコードされています（[RFC4648]、セクション4、Base64テキスト内の改行は許可されていますが、必須ではありません）。
Both the <publish/> and <withdraw/> PDUs also have a "hash" attribute, which carries a hash of an existing object at the specified repository URI, encoded as a hexadecimal string. For <withdraw/> PDUs, the hash MUST be present, as this operation makes no sense if there is no existing object to withdraw. For <publish/> PDUs, the hash MUST be present if the publication operation is overwriting an existing object, and it MUST NOT be present if this publication operation is writing to a new URI where no prior object exists. Presence of an object when no "hash" attribute has been specified is an error, as is absence of an object or an incorrect hash value when a "hash" attribute has been specified. Any such errors MUST be reported using the <report_error/> PDU.
<publish />と<withdraw />の両方のPDUには、16進文字列としてエンコードされた、指定されたリポジトリURIにある既存のオブジェクトのハッシュを運ぶ「ハッシュ」属性もあります。 <withdraw /> PDUの場合、既存のオブジェクトを撤回する必要がない場合、この操作は意味をなさないため、ハッシュが存在する必要があります。 <publish /> PDUの場合、パブリッシュ操作が既存のオブジェクトを上書きする場合はハッシュが存在しなければならず、このパブリケーション操作が前のオブジェクトが存在しない新しいURIに書き込む場合は存在しない必要があります。 「ハッシュ」属性が指定されていないときにオブジェクトが存在するか、オブジェクトが存在しないか、「ハッシュ」属性が指定されているときに不正なハッシュ値が指定されている場合、オブジェクトが存在するとエラーになります。このようなエラーは、<report_error /> PDUを使用して報告する必要があります。
The hash algorithm is SHA-256 [SHS], to simplify comparison of publication protocol hashes with RPKI manifest hashes.
ハッシュアルゴリズムはSHA-256 [SHS]であり、公開プロトコルハッシュとRPKIマニフェストハッシュの比較を簡素化します。
The intent behind the "hash" attribute is to allow the client and server to detect any disagreements about the effect that a <publish/> or <withdraw/> PDU will have on the repository.
「ハッシュ」属性の背後にある意図は、クライアントとサーバーが<publish />または<withdraw /> PDUがリポジトリに及ぼす影響についての不一致を検出できるようにすることです。
Note that every publish and withdraw action requires a new manifest, thus every publish or withdraw action will involve at least two objects.
すべての発行および取り消しアクションには新しいマニフェストが必要であるため、すべての発行または取り消しアクションには少なくとも2つのオブジェクトが含まれることに注意してください。
Processing of a query message is handled atomically: either the entire query succeeds or none of it does. When a query message contains multiple PDUs, failure of any PDU may require the server to roll back actions triggered by earlier PDUs.
クエリメッセージの処理はアトミックに処理されます。クエリ全体が成功するか、成功しないかのどちらかです。クエリメッセージに複数のPDUが含まれている場合、いずれかのPDUに障害が発生すると、サーバーは以前のPDUによってトリガーされたアクションをロールバックする必要があります。
When a query message containing <publish/> or <withdraw/> PDUs succeeds, the server returns a single <success/> reply.
<publish />または<withdraw /> PDUを含むクエリメッセージが成功すると、サーバーは単一の<success />応答を返します。
When a query fails, the server returns one or more <report_error/> reply PDUs. Typically, a server will only generate one <report_error/> corresponding to the first query PDU that failed, but servers MAY return multiple <report_error/> PDUs at the implementer's discretion.
クエリが失敗すると、サーバーは1つ以上の<report_error />応答PDUを返します。通常、サーバーは、失敗した最初のクエリPDUに対応する1つの<report_error />のみを生成しますが、サーバーは実装者の裁量で複数の<report_error /> PDUを返す場合があります。
The <list/> operation allows the client to ask the server for a complete listing of objects which the server believes the client has published. This is intended primarily to allow the client to recover upon detecting (probably via use of the "hash" attribute; see Section 2.2) that they have somehow lost synchronization.
<list />オペレーションにより、クライアントはサーバーに、クライアントが公開したとサーバーが信じるオブジェクトの完全なリストを要求することができます。これは主に、クライアントが何らかの理由で同期を失ったことを（おそらく「ハッシュ」属性を使用して、セクション2.2を参照して）検出すると回復できるようにすることを目的としています。
The <list/> query consists of a single PDU. A <list/> query MUST be the only PDU in a query -- it may not be combined with any <publish/> or <withdraw/> queries.
<list />クエリは、単一のPDUで構成されています。 <list />クエリは、クエリ内の唯一のPDUである必要があります-これは、<publish />または<withdraw />クエリと組み合わせることはできません。
The <list/> reply consists of zero or more PDUs, one per object published in this repository by this client, each PDU conveying the URI and hash of one published object.
<list />応答は、このクライアントによってこのリポジトリで公開されたオブジェクトごとに1つずつ、0個以上のPDUで構成され、各PDUは1つの公開されたオブジェクトのURIとハッシュを伝達します。
Errors are handled at two levels.
エラーは2つのレベルで処理されます。
Errors that make it impossible to decode a query or encode a response are handled at the HTTP layer. 4xx and 5xx HTTP response codes indicate that something bad happened.
クエリのデコードや応答のエンコードを不可能にするエラーは、HTTPレイヤーで処理されます。 4xxおよび5xx HTTP応答コードは、何か問題が発生したことを示します。
In all other cases, errors result in an XML <report_error/> PDU. Like the rest of this protocol, <report_error/> PDUs are CMS-signed XML messages and thus can be archived to provide an audit trail.
他のすべての場合では、エラーはXML <report_error /> PDUになります。このプロトコルの他の部分と同様に、<report_error /> PDUはCMS署名付きXMLメッセージであるため、監査証跡を提供するためにアーカイブできます。
<report_error/> PDUs only appear in replies, never in queries.
<report_error /> PDUは返信にのみ表示され、クエリには表示されません。
The "tag" attribute of the <report_error/> PDU associated with a <publish/> or <withdraw/> PDU MUST be set to the same value as the "tag" attribute in the PDU which generated the error. A client can use the "tag" attribute to determine which PDU caused processing of an update to fail.
<publish />または<withdraw /> PDUに関連付けられた<report_error /> PDUの「タグ」属性は、エラーを生成したPDUの「タグ」属性と同じ値に設定する必要があります。クライアントは「タグ」属性を使用して、更新の処理が失敗した原因となったPDUを判別できます。
The error itself is conveyed in the "error_code" attribute. The value of this attribute is a token indicating the specific error that occurred.
エラー自体は「error_code」属性で伝えられます。この属性の値は、発生した特定のエラーを示すトークンです。
The body of the <report_error/> element contains two sub-elements:
<report_error />エレメントの本体には、2つのサブエレメントが含まれています。
1. An optional text element <error_text/>, which, if present, contains a text string with debugging information intended for human consumption.
1. オプションのテキスト要素<error_text />は、存在する場合、人間が使用することを目的としたデバッグ情報を含むテキスト文字列を含みます。
2. An optional element <failed_pdu/>, which, if present, contains a verbatim copy of the query PDU whose failure triggered the <report_error/> PDU. The quoted element must be syntactically valid.
2. オプションの要素<failed_pdu />。存在する場合、失敗によって<report_error /> PDUがトリガーされたクエリPDUの逐語的なコピーが含まれます。引用された要素は構文的に有効でなければなりません。
See Section 3.7 for examples of a multi-element query and responses.
複数要素のクエリと応答の例については、セクション3.7を参照してください。
These are the defined error codes as well as some discussion of each. Text similar to these descriptions may be sent in an <error_text/> element to help explain the error encountered.
これらは、定義されたエラーコードと、それぞれの説明です。これらの説明と同様のテキストが<error_text />要素で送信され、発生したエラーの説明に役立ちます。
xml_error: Encountered an XML problem. Note that some XML errors may be severe enough to require error reporting at the HTTP layer, instead. Implementations MAY choose to report any or all XML errors at the HTTP layer.
xml_error：XMLの問題が発生しました。代わりに、一部のXMLエラーは、HTTP層でのエラー報告を必要とするほど深刻な場合があることに注意してください。実装は、HTTP層でXMLエラーの一部またはすべてを報告することを選択できます。
permission_failure: Client does not have permission to update this URI.
permission_failure：クライアントには、このURIを更新する権限がありません。
bad_cms_signature: Bad CMS signature.
bad_cms_signature：不正なCMS署名。
object_already_present: An object is already present at this URI, yet a "hash" attribute was not specified. A "hash" attribute must be specified when overwriting or deleting an object. Perhaps client and server are out of sync?
object_already_present：オブジェクトはすでにこのURIに存在していますが、「ハッシュ」属性が指定されていませんでした。オブジェクトを上書きまたは削除するときは、「ハッシュ」属性を指定する必要があります。おそらくクライアントとサーバーが同期していませんか？
no_object_present: There is no object present at this URI, yet a "hash" attribute was specified. Perhaps client and server are out of sync?
no_object_present：このURIにはオブジェクトがありませんが、「ハッシュ」属性が指定されています。おそらくクライアントとサーバーが同期していませんか？
no_object_matching_hash: The "hash" attribute supplied does not match the "hash" attribute of the object at this URI. Perhaps client and server are out of sync?
no_object_matching_hash：指定された「ハッシュ」属性は、このURIにあるオブジェクトの「ハッシュ」属性と一致しません。おそらくクライアントとサーバーが同期していませんか？
consistency_problem: Server detected an update that looks like it will cause a consistency problem (e.g., an object was deleted, but the manifest was not updated). Note that a server is not required to make such checks. Indeed, it may be unwise for a server to do so. This error code just provides a way for the server to explain its (in-)action.
一貫性の問題：サーバーは、一貫性の問題を引き起こすと思われる更新を検出しました（たとえば、オブジェクトが削除されましたが、マニフェストは更新されていません）。サーバーはそのようなチェックを行う必要がないことに注意してください。実際、サーバーがそうするのは賢明ではないかもしれません。このエラーコードは、サーバーがその（イン）アクションを説明する方法を提供するだけです。
other_error: A meteor fell on the server.
other_error：流星がサーバーに落ちました。
The following is a [RELAX-NG] compact form schema describing the publication protocol.
以下は、公開プロトコルを説明する[RELAX-NG]コンパクトフォームスキーマです。
This schema is normative: in the event of a disagreement between this schema and the document text above, this schema is authoritative.
このスキーマは規範的です。このスキーマと上記のドキュメントテキストが一致しない場合、このスキーマは信頼できます。
# RELAX NG schema for RPKI publication protocol.
＃RPKI発行プロトコルのRELAX NGスキーマ。
default namespace =
"http://www.hactrn.net/uris/rpki/publication-spec/"
# This is version 4 of the protocol.
＃これはプロトコルのバージョン4です。
version = "4"
# Top-level PDU is either a query or a reply.
＃トップレベルPDUは、クエリまたは応答のいずれかです。
start |= element msg {
attribute version { version },
attribute type { "query" },
query_elt
}
start |= element msg {
attribute version { version },
attribute type { "reply" },
reply_elt
}
# Tag attributes for bulk operations.
＃一括操作のタグ属性。
tag = attribute tag { xsd:token { maxLength="1024" } }
# Base64-encoded DER stuff.
＃Base64でエンコードされたDERのもの。
base64 = xsd:base64Binary
base64 = xsd：base64Binary
# Publication URIs.
＃パブリケーションURI。
uri = attribute uri { xsd:anyURI { maxLength="4096" } }
# Digest of an existing object (hexadecimal).
＃既存のオブジェクトのダイジェスト（16進数）。
hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }
# Error codes.
＃エラーコード。
error |= "xml_error" error |= "permission_failure" error |= "bad_cms_signature" error |= "object_already_present" error |= "no_object_present" error |= "no_object_matching_hash" error |= "consistency_problem" error |= "other_error"
エラー| = "xml_error"エラー| = "permission_failure"エラー| = "bad_cms_signature"エラー| = "object_already_present"エラー| = "no_object_present"エラー| = "no_object_matching_hash"エラー| = "consistency_problem"エラー| = "other_error"
# <publish/> and <withdraw/> query elements
query_elt |= (
element publish { tag, uri, hash?, base64 } |
element withdraw { tag, uri, hash }
)*
# <success/> reply
reply_elt |= element success { empty }
# <list/> query and reply
query_elt |= element list { empty }
reply_elt |= element list { uri, hash }*
# <report_error/> reply
reply_elt |= element report_error {
tag?,
attribute error_code { error },
element error_text { xsd:string { maxLength="512000" }}?,
element failed_pdu { query_elt }?
}*
Following are examples of various queries and the corresponding replies for the RPKI publication protocol.
以下は、RPKI発行プロトコルのさまざまなクエリと対応する応答の例です。
Note that the authors have taken liberties with the Base64, hash, and URI text in these examples in the interest of making the examples fit nicely into RFC text format. Similarly, these examples do not show the CMS signature wrapper around the XML, just the XML payload.
著者がこれらの例のBase64、ハッシュ、URIテキストを自由に使用して、例をRFCテキスト形式にうまく適合させることに注意してください。同様に、これらの例ではXMLのCMS署名ラッパーではなく、XMLペイロードのみを示しています。
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- body is base64(new-object) -->
<publish
tag=""
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish>
</msg>
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- hash is hex(SHA-256(old-object)) -->
<!-- body is base64(new-object) -->
<publish
hash="01a97a70ac477f06"
tag="foo"
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish>
</msg>
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<!-- hash is hex(SHA-256(old-object)) -->
<withdraw
hash="01a97a70ac477f06"
tag="foo"
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<success/>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error
error_code="no_object_matching_hash"
tag="foo">
<error_text>
Can't delete an object I don't have
</error_text>
<failed_pdu>
<publish
hash="01a97a70ac477f06"
tag="foo"
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish>
</failed_pdu>
</report_error>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error
error_code="object_already_present"
tag="foo"/>
</msg>
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<publish
tag="Alice"
uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
</publish>
<withdraw
hash="f46a4198efa3070e"
tag="Bob"
uri="rsync://wombat.example/Bob/f46a4198efa3070e.cer"/>
<publish
tag="Carol"
uri="rsync://wombat.example/Carol/32e0544eeb510ec0.cer">
SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w=
</publish>
<withdraw
hash="421ee4ac65732d72"
tag="Dave"
uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
<publish
tag="Eve"
uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
SGVsbG8sIG15IG5hbWUgaXMgRXZl
</publish>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<success/>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error
error_code="no_object_matching_hash"
tag="Dave">
<failed_pdu>
<withdraw
hash="421ee4ac65732d72"
tag="Dave"
uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
</failed_pdu>
</report_error>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<report_error
error_code="no_object_matching_hash"
tag="Dave">
<failed_pdu>
<withdraw
hash="421ee4ac65732d72"
tag="Dave"
uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
</failed_pdu>
</report_error>
<report_error
error_code="object_already_present"
tag="Eve">
<failed_pdu>
<publish
tag="Eve"
uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
SGVsbG8sIG15IG5hbWUgaXMgRXZl
</publish>
</failed_pdu>
</report_error>
</msg>
<msg
type="query"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<list/>
</msg>
<msg
type="reply"
version="4"
xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
<list
hash="eb719b72f0648cf4"
uri="rsync://wombat.example/Fee/eb719b72f0648cf4.cer"/>
<list
hash="c7c50a68b7aa50bf"
uri="rsync://wombat.example/Fie/c7c50a68b7aa50bf.cer"/>
<list
hash="f222481ded47445d"
uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/>
<list
hash="15b94e08713275bc"
uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/>
</msg>
IANA has registered the "application/rpki-publication" media type as follows:
IANAは "application / rpki-publication"メディアタイプを次のように登録しています。
Type name: application
Subtype name: rpki-publication
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI publication protocol
message, as defined in RFC 8181.
Interoperability considerations: None
Published specification: RFC 8181
Applications which use this media type: HTTP
Additional information:
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information:
Rob Austein <sra@hactrn.net>
Intended usage: COMMON
Author/Change controller: IETF
The RPKI publication protocol and the data it publishes use entirely separate PKIs for authentication. The published data is authenticated within the RPKI, and this protocol has nothing to do with that authentication, nor does it require that the published objects be valid in the RPKI. The publication protocol uses a separate BPKI to authenticate its messages.
RPKI公開プロトコルとそれが公開するデータは、認証にまったく別のPKIを使用します。公開されたデータはRPKI内で認証され、このプロトコルはその認証とは何の関係もありません。また、公開されたオブジェクトがRPKIで有効である必要はありません。公開プロトコルは、別のBPKIを使用してメッセージを認証します。
Each RPKI publication protocol message is wrapped in a signed CMS message, which provides message integrity protection and an auditable form of message authentication. Because of these protections at the application layer, and because all the data being published are intended to be public information in any case, this protocol does not, strictly speaking, require the use of HTTPS or other transport security mechanisms. There may, however, be circumstances in which a particular publication operator may prefer HTTPS over HTTP anyway, as a matter of (BPKI) CA policy. Use of HTTP versus HTTPS here is, essentially, a private matter between the repository operator and its clients. Note, however, that even if a client/server pair uses HTTPS for this protocol, message authentication for this protocol is still based on the CMS signatures, not HTTPS.
各RPKIパブリケーションプロトコルメッセージは、署名されたCMSメッセージでラップされます。これにより、メッセージの整合性が保護され、監査可能な形式のメッセージ認証が提供されます。アプリケーション層でのこれらの保護のため、および公開されるすべてのデータはいかなる場合でも公開情報であることが意図されているため、厳密に言えば、このプロトコルはHTTPSまたは他のトランスポートセキュリティメカニズムの使用を必要としません。ただし、（BPKI）CAポリシーの問題として、特定の公開事業者がいずれにしてもHTTPS over HTTPを好む場合があります。ここでのHTTPとHTTPSの使用は、基本的に、リポジトリオペレーターとそのクライアントの間の私的な問題です。ただし、クライアント/サーバーのペアがこのプロトコルにHTTPSを使用する場合でも、このプロトコルのメッセージ認証は、HTTPSではなくCMS署名に基づいていることに注意してください。
Although the hashes used in the <publish/> and <withdraw/> PDUs are cryptographically strong, the digest algorithm was selected for convenience in comparing these hashes with the hashes that appear in RPKI manifests. The hashes used in the <publish/> and <withdraw/> PDUs are not particularly security sensitive because these PDUs are protected by the CMS signatures. Because of this, the most likely reason for a change to this digest algorithm would be to track a corresponding change in the digest algorithm used in RPKI manifests. If and when such a change happens, it will require incrementing the version number of this publication protocol, but given that the most likely implementation of a publication server uses these hashes as lookup keys in a database, bumping the protocol version number would be a relatively minor portion of the effort of changing the algorithm.
<publish />および<withdraw /> PDUで使用されるハッシュは暗号的に強力ですが、ダイジェストアルゴリズムは、これらのハッシュをRPKIマニフェストに表示されるハッシュと比較するのに便利なように選択されました。 <publish />および<withdraw /> PDUで使用されるハッシュは、これらのPDUがCMS署名によって保護されているため、特にセキュリティ上重要ではありません。このため、このダイジェストアルゴリズムが変更される最も可能性の高い理由は、RPKIマニフェストで使用されるダイジェストアルゴリズムの対応する変更を追跡することです。このような変更が発生した場合、この公開プロトコルのバージョン番号をインクリメントする必要がありますが、公開サーバーの最も可能性の高い実装では、これらのハッシュをデータベースのルックアップキーとして使用するため、プロトコルのバージョン番号を上げるのは比較的簡単です。アルゴリズムを変更する作業のマイナーな部分。
Compromise of a publication server, perhaps through mismanagement of BPKI private keys, could lead to a denial-of-service attack on the RPKI. An attacker gaining access to BPKI private keys could use this protocol to delete (withdraw) RPKI objects, leading to routing changes or failures. Accordingly, as in most PKIs, good key management practices are important.
おそらくBPKI秘密鍵の管理ミスによる公開サーバーの侵害は、RPKIに対するサービス拒否攻撃につながる可能性があります。攻撃者がBPKI秘密鍵にアクセスすると、このプロトコルを使用してRPKIオブジェクトを削除（撤回）し、ルーティングの変更や失敗を引き起こす可能性があります。したがって、ほとんどのPKIと同様に、適切なキー管理の実践が重要です。
[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002, <https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RELAX-NG]クラークJ。、「RELAX NGコンパクト構文」、OASIS委員会仕様、2002年11月、<https://www.oasis-open.org/committees/relax-ng/compact-20021121.html>。
[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>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。
[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>。
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, <http://www.rfc-editor.org/info/rfc6492>.
[RFC6492] Huston、G.、Loomans、R.、Ellacott、B。、およびR. Austein、「A Protocol for Provisioning Resource Certificates」、RFC 6492、DOI 10.17487 / RFC6492、2012年2月、<http：// www。 rfc-editor.org/info/rfc6492>。
[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>。
[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>。
[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>。
[XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C Consortium Recommendation REC-xml11-20060816, October 2002, <http://www.w3.org/TR/2002/CR-xml11-20021015>.
[XML] Cowan、J。、「Extensible Markup Language（XML）1.1」、W3C Consortium Recommendation REC-xml11-20060816、2002年10月、<http://www.w3.org/TR/2002/CR-xml11-20021015 >。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<http://www.rfc-editor.org/info/rfc6480> 。
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <http://www.rfc-editor.org/info/rfc8182>.
[RFC8182] Bruijnzeels、T.、Muravskiy、O.、Weber、B。、およびR. Austein、「The RPKI Repository Delta Protocol（RRDP）」、RFC 8182、DOI 10.17487 / RFC8182、2017年7月、<http：// www.rfc-editor.org/info/rfc8182>。
[RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services", RFC 8183, DOI 10.17487/RFC8183, July 2017, <http://www.rfc-editor.org/info/rfc8183>.
[RFC8183] Austein、R。、「リソース公開鍵インフラストラクチャ（RPKI）プロダクションサービスの帯域外セットアッププロトコル」、RFC 8183、DOI 10.17487 / RFC8183、2017年7月、<http：//www.rfc-editor .org / info / rfc8183>。
Acknowledgements
謝辞
The authors would like to thank: Geoff Huston, George Michaelson, Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped along the way but whose name(s) the authors have temporarily forgotten.
著者に感謝したい：ジェフ・ヒューストン、ジョージ・マイケルソン、オレグ・ムラブスキー、ポール・ウターズ、ランディ・ブッシュ、ロブ・ルーマンス、ロバート・キステレキ、ティム・ブライジンゼルス、トム・ペッチ、そして道に沿って助けてくれたが、著者の名前一時的に忘れてしまいました。
Authors' Addresses
著者のアドレス
Samuel Weiler W3C / MIT
サミュエルワイラーW3C / MIT
Email: weiler@csail.mit.edu
Anuja Sonalker STEER Tech
Anuja Sonalker STEER Tech
Email: anuja@steer-tech.com
Rob Austein Dragon Research Labs
ロブオースタインドラゴン研究所
Email: sra@hactrn.net