[要約] RFC 8183は、RPKIプロダクションサービスのためのオフバンドセットアッププロトコルに関するものです。このRFCの目的は、RPKIのセキュリティと信頼性を向上させるために、セキュアなセットアッププロセスを提供することです。
Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 8183 Dragon Research Labs
Category: Standards Track July 2017
ISSN: 2070-1721
An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
Resource Public Key Infrastructure（RPKI）Production Servicesのアウトオブバンドセットアッププロトコル
Abstract
概要
This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.
このノートでは、2つのパーティ間のリソース公開鍵インフラストラクチャ（RPKI）のプロビジョニングおよび公開プロトコルのセットアップを容易にするための単純な帯域外プロトコルについて説明します。プロトコルは少数のXMLメッセージにエンコードされており、許容可能なデータの整合性と認証を提供する相互に合意できる手段によってやり取りできます。
This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.
このセットアッププロトコルは、プロビジョニングまたは公開プロトコルの一部ではありません。むしろ、関係を設定し、それらの関係の認証に使用されるキー情報を交換することにより、これらのプロトコルの構成を簡素化することを目的としています。
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/rfc8183.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8183で入手できます。
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Common Protocol Elements . . . . . . . . . . . . . . . . 6
5.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 7
5.2.1. <child_request/> . . . . . . . . . . . . . . . . . . 7
5.2.2. <parent_response/> . . . . . . . . . . . . . . . . . 8
5.2.3. <publisher_request/> . . . . . . . . . . . . . . . . 10
5.2.4. <repository_response/> . . . . . . . . . . . . . . . 11
5.3. <authorization/> . . . . . . . . . . . . . . . . . . . . 12
5.4. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. RELAX NG Schema . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
This note describes a small XML-based out-of-band protocol used to set up relationships between parents and children in the RPKI provisioning protocol [RFC6492] and between publishers and repositories in the RPKI publication protocol [RFC8181].
このノートでは、RPKIプロビジョニングプロトコル[RFC6492]で親と子の間、およびRPKIパブリケーションプロトコル[RFC8181]でパブリッシャーとリポジトリの間の関係を設定するために使用される、XMLベースの小さなアウトオブバンドプロトコルについて説明します。
The basic function of this protocol is public key exchange, in the form of self-signed X.509 certificates, but workshop experience has demonstrated that it's simpler for the user if we also bundle the other configuration information needed to bring up a new player into the messages used in the key exchange.
このプロトコルの基本的な機能は、自己署名X.509証明書の形式の公開鍵交換ですが、ワークショップの経験では、新しいプレーヤーを起動するために必要な他の構成情報もバンドルすると、ユーザーにとってより簡単になることが実証されています鍵交換で使用されるメッセージ。
The underlying transport for this protocol is deliberately unspecified. It might be a USB stick, a web interface secured with conventional HTTPS, PGP-signed email, a T-shirt printed with a Quick Response (QR) code, or a carrier pigeon.
このプロトコルの基になるトランスポートは、意図的に指定されていません。 USBスティック、従来のHTTPSで保護されたWebインターフェイス、PGP署名付き電子メール、Quick Response（QR）コードが印刷されたTシャツ、またはキャリアピジョンの可能性があります。
Since much of the purpose of this protocol is key exchange, authentication and integrity of the key exchange MUST be ensured via external means. Typically, such means will tie directly to a new or existing business relationship.
このプロトコルの目的の大部分はキー交換であるため、キー交換の認証と整合性は、外部手段を介して保証する必要があります。通常、このような手段は、新規または既存のビジネス関係に直接結びつきます。
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]で説明されているように解釈されます。
All of the protocols configured by this setup protocol have their own terminology for their actors, but in the context of this protocol that terminology becomes somewhat confusing. All of the players in this setup protocol issue certificates, are the subjects of other certificates, operate servers, and, in most cases, act as clients for one protocol or another. Therefore, this note uses its own terms for the actors in this protocol.
このセットアッププロトコルによって構成されたすべてのプロトコルには、アクターの独自の用語がありますが、このプロトコルのコンテキストでは、その用語はやや混乱します。このセットアッププロトコルのすべてのプレーヤーは証明書を発行し、他の証明書の対象となり、サーバーを操作し、ほとんどの場合、1つのプロトコルまたは別のプロトコルのクライアントとして機能します。したがって、このノートでは、このプロトコルのアクターに独自の用語を使用しています。
Child: An entity acting in the client ("subject") role of the provisioning protocol defined in [RFC6492].
子：[RFC6492]で定義されているプロビジョニングプロトコルのクライアント（「サブジェクト」）の役割で機能するエンティティ。
Parent: An entity acting in the server ("issuer") role of the provisioning protocol defined in [RFC6492].
親：[RFC6492]で定義されているプロビジョニングプロトコルのサーバー（「発行者」）の役割で機能するエンティティ。
Publisher: An entity acting in the client role of the publication protocol defined in [RFC8181].
パブリッシャー：[RFC8181]で定義された公開プロトコルのクライアントの役割で行動するエンティティ。
Repository: An entity acting in the server role of the publication protocol defined in [RFC8181].
リポジトリ：[RFC8181]で定義されている公開プロトコルのサーバーの役割で機能するエンティティ。
Note that a given entity might act in more than one of these roles; for example, in one of the simplest cases, the child is the same entity as the publisher, while the parent is the same entity as the repository.
特定のエンティティがこれらの役割の複数で機能する可能性があることに注意してください。たとえば、最も単純なケースの1つでは、子はパブリッシャーと同じエンティティであり、親はリポジトリと同じエンティティです。
The protocol described in this document grew out of a series of workshops held starting in 2010, at which it became clear that manual configuration of keying material and service URLs was both error prone and unnecessarily confusing. The basic mechanism and semantics have been essentially unchanged since the earliest versions of the protocol, but there were several workshop-driven syntax changes and simplifications before the protocol made its way into the IETF, and a few more simplifications and minor extensions have occurred since that time.
このドキュメントで説明されているプロトコルは、2010年に開催された一連のワークショップから生まれました。このワークショップでは、鍵情報とサービスURLの手動設定はエラーが発生しやすく、不必要に混乱することが明らかになりました。基本的なメカニズムとセマンティクスは、プロトコルの初期のバージョンから本質的に変更されていませんが、プロトコルがIETFに移行する前に、ワークショップ主導の構文の変更と簡略化がいくつか行われ、それ以降、いくつかの簡略化と小さな拡張が行われました時間。
Several protocols related to RPKI provisioning use signed Cryptographic Message Syntax (CMS) messages [RFC5652] to authenticate the underlying XML-based protocols. Verification of these CMS messages requires X.509 certificates. The PKI that holds these certificates is distinct from the RPKI and contains no RFC 3779 resources. We refer to this as the "Business PKI" (BPKI), to distinguish it from the RPKI. The "B" is a hint that the certificate relationships in the BPKI are likely to follow and become part of existing contractual relationships between the issuers and subjects of this PKI.
RPKIプロビジョニングに関連するいくつかのプロトコルは、署名された暗号メッセージ構文（CMS）メッセージ[RFC5652]を使用して、基盤となるXMLベースのプロトコルを認証します。これらのCMSメッセージの検証には、X.509証明書が必要です。これらの証明書を保持するPKIはRPKIとは異なり、RFC 3779リソースを含みません。これを「ビジネスPKI（BPKI）」と呼び、RPKIと区別します。 「B」は、BPKIの証明書の関係が、このPKIの発行者とサブジェクトの間の既存の契約関係に従い、その一部になる可能性が高いというヒントです。
The RPKI provisioning protocol does not dictate a particular structure for the BPKI, beyond the basic requirement that it be possible for one party to sign and the other party to verify the CMS messages. This allows a certain amount of flexibility to allow an Internet registry to reuse an existing PKI as the BPKI if that makes sense in their context.
RPKIプロビジョニングプロトコルは、一方の当事者が署名し、もう一方の当事者がCMSメッセージを検証できるという基本的な要件を超えて、BPKIの特定の構造を規定していません。これにより、ある程度の柔軟性が得られ、インターネットレジストリが既存のPKIをBPKIとして再利用できるようになります。
In order to keep this protocol simple, we adopt a somewhat constrained model of the BPKI. The first two operations in this protocol are an exchange of public keys between child and parent for use in the provisioning protocol; the latter two operations in this protocol are an exchange of public keys between publisher and repository for use in the publication protocol. In each of these operations, the sending party includes its public key, in the form of a self-signed X.509 Certification Authority (CA) certificate. The private keys corresponding to the exchanged certificates are not used to sign CMS messages directly; instead, the exchanged CA certificates are the issuers of the BPKI end-entity (EE) certificates which will be included in the CMS messages and can be used, along with the exchanged certificates, to verify the CMS messages.
このプロトコルをシンプルに保つために、BPKIのやや制約のあるモデルを採用しています。このプロトコルの最初の2つの操作は、プロビジョニングプロトコルで使用するための子と親の間の公開鍵の交換です。このプロトコルの後半の2つの操作は、公開プロトコルで使用するためのパブリッシャーとリポジトリの間の公開鍵の交換です。これらの各操作で、送信者は、自己署名X.509証明機関（CA）証明書の形式で公開鍵を含めます。交換された証明書に対応する秘密鍵は、CMSメッセージに直接署名するためには使用されません。代わりに、交換されたCA証明書は、CMSメッセージに含まれるBPKIエンドエンティティ（EE）証明書の発行者であり、交換された証明書と共に、CMSメッセージを検証するために使用できます。
Details of how to tie the exchanged certificates into an implementation's local BPKI are left to the implementation, but the recommended approach is to cross-certify the received public key and subject name under one's own BPKI, using a Basic Constraints extension with cA = TRUE, pathLenConstraint = 0, indicating that the cross-certified certificate is a CA certificate which is allowed to issue EE certificates but is not allowed to issue CA certificates. See Section 4.2.1.9 of [RFC5280] for more information about the Basic Constraints extension.
交換された証明書を実装のローカルBPKIに関連付ける方法の詳細は実装に委ねられますが、推奨されるアプローチは、cA = TRUEの基本制約拡張を使用して、受信した公開鍵とサブジェクト名を自分のBPKIで相互認証することです。 pathLenConstraint =0。相互認証された証明書が、EE証明書の発行は許可されているが、CA証明書の発行は許可されていないCA証明書であることを示します。基本制約拡張の詳細については、[RFC5280]のセクション4.2.1.9を参照してください。
For example, suppose that Alice and Bob each have their own self-signed BPKI certificates:
たとえば、アリスとボブがそれぞれ独自の自己署名BPKI証明書を持っているとします。
Issuer: CN = Alice CA
Subject: CN = Alice CA
Public Key: [Alice CA Public Key]
BasicConstraints: cA = TRUE
Issuer: CN = Bob CA
Subject: CN = Bob CA
Public Key: [Bob CA Public Key]
BasicConstraints: cA = TRUE
Alice sends Bob her self-signed BPKI certificate, and Bob cross certifies its public key and subject name under Bob's own self-signed BPKI certificate:
アリスはボブに自己署名BPKI証明書を送信し、ボブはその公開鍵とサブジェクト名をボブ自身の自己署名BPKI証明書の下で相互認証します。
Issuer: CN = Bob CA
Subject: CN = Alice CA
Public Key: [Alice CA Public Key]
BasicConstraints: cA = TRUE, pathLenConstraint = 0
Later, when Bob receives a CMS message from Alice, Bob can verify this message via a trust chain back to Bob's own trust anchor:
その後、ボブがアリスからCMSメッセージを受信すると、ボブはボブ自身のトラストアンカーへの信頼チェーンを介してこのメッセージを確認できます。
Issuer: CN = Alice CA
Subject: CN = Alice EE
Public Key: [Alice EE Public Key]
A complete description of the certificates allowed here is beyond the scope of this document, as it is determined primarily by what is acceptable to the several other protocols for which this protocol is handling setup. Furthermore, we expect the requirements to change over time to track changes in cryptographic algorithms, required key length, and so forth. Finally, since this protocol is restricted to setting up pairwise relationships, all that's really required is that the two parties involved in a particular conversation agree on what constitutes an acceptable certificate.
ここで許可されている証明書の完全な説明は、このプロトコルの設定を処理する他のいくつかのプロトコルが許容できるものによって主に決定されるため、このドキュメントの範囲を超えています。さらに、暗号化アルゴリズム、必要なキーの長さなどの変化を追跡するために、要件は時間とともに変化することが予想されます。最後に、このプロトコルはペアワイズ関係の設定に限定されているため、実際に必要なのは、特定の会話に関与する2つのパーティが、許容できる証明書の構成について合意することだけです。
All of that said, in practice, the certificates currently exchanged by this protocol at the time this document was written are what a reader familiar with the technology would probably expect: RSA keys with lengths in the 2048-4096 bit range, SHA-2 digests, and a few common X.509v3 extensions (principally Basic Constraints, Authority Key Identifier, and Subject Key Identifier). Since the most likely usage is a cross-certification operation in which the recipient simply extracts the subject name and public key after checking the self-signature and discards the rest of the incoming certificate, the practical value of esoteric X.509v3 extensions is somewhat limited.
つまり、実際には、このドキュメントが書かれたときにこのプロトコルによって現在交換されている証明書は、テクノロジに精通している読者がおそらく期待するものです：2048〜4096ビット範囲の長さのRSAキー、SHA-2ダイジェスト、およびいくつかの一般的なX.509v3拡張機能（主に基本的な制約、権限キー識別子、およびサブジェクトキー識別子）。最も可能性の高い使用法は、受信者が自己署名を確認した後でサブジェクト名と公開鍵を抽出し、残りの受信証明書を破棄する相互認証操作であるため、難解なX.509v3拡張の実用的な値は多少制限されます。
Each message in the protocol is a distinct XML element in the <http://www.hactrn.net/uris/rpki/rpki-setup/> XML namespace.
プロトコルの各メッセージは、<http://www.hactrn.net/uris/rpki/rpki-setup/> XML名前空間の個別のXML要素です。
The outermost XML element of each message contains a version attribute. This document describes version 1 of the protocol.
各メッセージの最も外側のXML要素には、バージョン属性が含まれています。このドキュメントでは、プロトコルのバージョン1について説明します。
Appendix A is a [RELAX-NG] schema for this protocol. The schema is normative: in the event of a disagreement between the schema and the following textual description, the schema is authoritative.
付録Aは、このプロトコルの[RELAX-NG]スキーマです。スキーマは規範的です。スキーマと次のテキストの説明の間に不一致がある場合、スキーマは信頼できます。
Since "1" is currently the only value allowed for the version attribute in the schema, an incorrect protocol version can be detected either by checking the version attribute directly or as a schema validation error.
現在、スキーマのバージョン属性に許可されている値は「1」だけなので、バージョン属性を直接チェックするか、スキーマ検証エラーとして、不正なプロトコルバージョンを検出できます。
Most messages contain, among other things, a self-signed BPKI X.509 certificate. These certificates are represented as XML elements whose text value is the Base64 text ([RFC4648], Section 4, with line breaks within the Base64 text permitted but not required) encoding the DER representation of the X.509 certificate.
ほとんどのメッセージには、特に自己署名入りのBPKI X.509証明書が含まれています。これらの証明書は、テキスト値がBase64テキスト（[RFC4648]、セクション4、Base64テキスト内での改行が許可されているが必須ではない）であるXML要素として表され、X.509証明書のDER表現をエンコードします。
A number of attributes contain "handles". A handle in this protocol is a text string in the US-ASCII character set consisting of letters, digits, and the special characters "/", "-", and "_". This protocol places no special semantics on the structure of these handles, although implementations might. Handles are protocol elements, not necessarily meaningful to humans, thus the simplicity of a restricted character set makes more sense than the complex rules which would be needed for internationalized text.
多くの属性には「ハンドル」が含まれています。このプロトコルのハンドルは、文字、数字、および特殊文字「/」、「-」、「_」で構成されるUS-ASCII文字セットのテキスト文字列です。このプロトコルは、実装によっては可能ですが、これらのハンドルの構造に特別なセマンティクスを設定しません。ハンドルはプロトコル要素であり、必ずしも人間にとって意味があるわけではないため、制限された文字セットの単純さは、国際化されたテキストに必要な複雑な規則よりも意味があります。
Most messages allow an optional "tag" attribute. This is an opaque cookie supplied by the client in a particular exchange and echoed by the server; the intent is to simplify the process of matching a response received by the client with an outstanding request.
ほとんどのメッセージでは、オプションの「タグ」属性を使用できます。これは、特定の交換でクライアントによって提供され、サーバーによってエコーされる不透明なCookieです。その目的は、クライアントが受信した応答を未処理の要求と照合するプロセスを簡略化することです。
The core of this protocol consists of four message types, representing the basic request and response semantics needed to configure an RPKI engine to talk to its parent and its repository via the provisioning and publication protocols, respectively.
このプロトコルのコアは4つのメッセージタイプで構成され、プロビジョニングプロトコルとパブリケーションプロトコルを介してそれぞれ親とリポジトリと通信するようにRPKIエンジンを構成するために必要な基本的な要求と応答のセマンティクスを表します。
The <child_request/> message is an initial setup request from a provisioning protocol child to its provisioning protocol parent.
<child_request />メッセージは、プロビジョニングプロトコルの子からそのプロビジョニングプロトコルの親への初期セットアップ要求です。
Fields in the <child_request/> message:
<child_request />メッセージのフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
tag: The child MAY include a "tag" attribute in the request message.
tag：子はリクエストメッセージに「タグ」属性を含めることができます。
child_handle: The child_handle attribute is what the child calls itself. This is just a hint from the child to the parent, and the parent need not honor it.
child_handle：child_handle属性は、子がそれ自体を呼び出すものです。これは子から親への単なるヒントであり、親はそれを尊重する必要はありません。
child_bpki_ta: The <child_bpki_ta/> element is the child's BPKI identity, a self-signed X.509 BPKI certificate, encoded in Base64.
child_bpki_ta：<child_bpki_ta />要素は、Base64でエンコードされた、自己署名されたX.509 BPKI証明書である子のBPKI IDです。
This CA certificate will be the issuer of the BPKI EE certificates corresponding to private keys that the child will use when sending provisioning protocol messages to the parent.
このCA証明書は、子が親にプロビジョニングプロトコルメッセージを送信するときに使用する秘密鍵に対応するBPKI EE証明書の発行者になります。
---------------------------------------------------------------------
<child_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
child_handle="Bob">
<child_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
The <parent_response/> message is a response from a provisioning protocol parent to a provisioning protocol child that had previously sent a <child_request/> message.
<parent_response />メッセージは、以前に<child_request />メッセージを送信したプロビジョニングプロトコルの親からプロビジョニングプロトコルの子への応答です。
Fields in the <parent_response/> message:
<parent_response />メッセージのフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
tag: If the <child_request/> message included a "tag" attribute, the parent MUST include an identical "tag" attribute in the <parent_response/> message; if the request did not include a tag attribute, the response MUST NOT include a tag attribute either.
タグ：<child_request />メッセージに「タグ」属性が含まれている場合、親は<parent_response />メッセージに同じ「タグ」属性を含める必要があります。リクエストにタグ属性が含まれていない場合、応答にもタグ属性を含めてはなりません（MUST NOT）。
service_uri: The service_uri attribute contains an HTTP or HTTPS URL [RFC7230] that the child should contact for up-down [RFC6492] service.
service_uri：service_uri属性には、子がアップダウン[RFC6492]サービスのために連絡する必要があるHTTPまたはHTTPS URL [RFC7230]が含まれています。
child_handle: The child_handle attribute is the parent's name for the child. This MAY match the child_handle from the <child_request/> message. If they do not match, the parent wins, because the parent gets to dictate the names in the provisioning protocol. This value is the sender field in provisioning protocol request messages and the recipient field in provisioning protocol response messages.
child_handle：child_handle属性は、子の親の名前です。これは、<child_request />メッセージのchild_handleと一致する場合があります。一致しない場合は、親が勝ちます。親がプロビジョニングプロトコルで名前を指示するためです。この値は、プロビジョニングプロトコル要求メッセージの送信者フィールドと、プロビジョニングプロトコル応答メッセージの受信者フィールドです。
parent_handle: The parent_handle attribute is the parent's name for itself. This value is the recipient field in provisioning protocol request messages and the sender field in provisioning protocol response messages.
parent_handle：parent_handle属性は、それ自体の親の名前です。この値は、プロビジョニングプロトコル要求メッセージの受信者フィールドと、プロビジョニングプロトコル応答メッセージの送信者フィールドです。
parent_bpki_ta: The <parent_bpki_ta/> element is the parent's BPKI identity, a self-signed X.509 BPKI certificate.
parent_bpki_ta：<parent_bpki_ta />要素は、親のBPKI ID、自己署名X.509 BPKI証明書です。
This certificate is the issuer of the BPKI EE certificates corresponding to private keys that the parent will use to sign provisioning protocol messages to the child.
この証明書は、親が子へのプロビジョニングプロトコルメッセージの署名に使用する秘密鍵に対応するBPKI EE証明書の発行者です。
offer: If an <offer/> element is present, the parent is offering publication service to the child. The <offer/> element, if present, is empty.
offer：<offer />要素が存在する場合、親は子にパブリケーションサービスを提供しています。 <offer />要素が存在する場合、それは空です。
referral: If <referral/> elements are present, they suggest third-party publication services which the child might use, and contain:
referral：<referral />要素が存在する場合、それらは子供が使用する可能性のあるサードパーティの公開サービスを提案し、以下を含みます：
referrer: A referrer attribute, containing the handle by which the publication repository knows the parent,
referrer：パブリケーションリポジトリが親を認識するためのハンドルを含むreferrer属性。
contact_uri: An optional contact_uri attribute that the child may be able to follow for more information, and
contact_uri：オプションのcontact_uri属性。子は詳細情報を追跡できます。
Authorization token: The text of the <referral/> element is the Base64 encoding of a signed authorization token granting the child the right to use a portion of the parent's namespace at the publication repository in question. See Section 5.3 for details on the authorization token.
承認トークン：<referral />要素のテキストは、署名された承認トークンのBase64エンコーディングで、問題のパブリケーションリポジトリで親の名前空間の一部を使用する権利を子に付与します。認証トークンの詳細については、セクション5.3を参照してください。
A parent is unlikely to need to send both <offer> and <referral> elements, but strictly speaking they are not mutually exclusive, so a parent which really needs to express that it both offers repository service to its child and is also willing to refer its child to one or more other repository servers can do so.
親は<offer>要素と<referral>要素の両方を送信する必要はほとんどありませんが、厳密に言えば、これらは相互に排他的ではないため、親が子にリポジトリサービスを提供し、参照することも望んでいることを本当に表現する必要があります。 1つまたは複数の他のリポジトリサーバーの子がそれを行うことができます。
---------------------------------------------------------------------
<parent_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
service_uri="http://a.example/up-down/Alice/Bob-42"
child_handle="Bob-42"
parent_handle="Alice">
<parent_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</parent_bpki_ta>
<offer/>
</parent_response>
---------------------------------------------------------------------
---------------------------------------------------------------------
<parent_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
service_uri="http://bob.example/up-down/Bob/Carol"
child_handle="Carol"
parent_handle="Bob">
<parent_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</parent_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</parent_response>
---------------------------------------------------------------------
The <publisher_request/> message is a setup request from a publisher to a repository. Generally, this will not take place until after the publisher has set up the provisioning protocol via a <child_request/> / <parent_response/> exchange: in particular, the <referral> sub-element here requires an <authorization/> token provided by the provisioning protocol exchange.
<publisher_request />メッセージは、パブリッシャーからリポジトリーへのセットアップ要求です。通常、これは、パブリッシャーが<child_request /> / <parent_response />交換を介してプロビジョニングプロトコルを設定するまで行われません。特に、ここでの<referral>サブ要素には、提供される<authorization />トークンが必要ですプロビジョニングプロトコル交換。
Fields in the <publisher_request/> message:
<publisher_request />メッセージのフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
tag: The publisher MAY include a "tag" attribute in the request message.
タグ：パブリッシャーは、リクエストメッセージに「タグ」属性を含めることができます。
publisher_handle: The publisher_handle attribute is the publisher's name for itself. This is just a hint; the repository need not honor it.
publisher_handle：publisher_handle属性は、それ自体の発行者の名前です。これは単なるヒントです。リポジトリはそれを尊重する必要はありません。
publisher_bpki_ta: The <publisher_bpki_ta/> element is the publisher's BPKI identity, a self-signed X.509 BPKI certificate. This certificate is the issuer of the BPKI EE certificates corresponding to private keys that the publisher will use to sign publication protocol messages to the repository.
publisher_bpki_ta：<publisher_bpki_ta />要素は、発行者のBPKI ID、つまり自己署名X.509 BPKI証明書です。この証明書は、発行者が公開プロトコルメッセージをリポジトリに署名するために使用する秘密鍵に対応するBPKI EE証明書の発行者です。
referral: If a <referral/> element is present, it contains:
referral：<referral />要素が存在する場合は、以下が含まれます：
referrer: A referrer attribute containing the publication handle of the referring parent, and
referrer：参照する親のパブリケーションハンドルを含むreferrer属性、および
Authorization token: The text of the <referral/> element is the Base64 encoding of a signed authorization token granting the publisher the right to use a portion of its parent's namespace at this repository. See Section 5.3 for details on the authorization token.
承認トークン：<referral />要素のテキストは、署名された承認トークンのBase64エンコードで、このリポジトリで親の名前空間の一部を使用する権利を発行者に付与します。認証トークンの詳細については、セクション5.3を参照してください。
These fields are copies of values that a parent provided to the child in the <parent_response/> message (see Section 5.2.2). The referrer attribute is present to aid lookup of the corresponding certificate by the repository. Note that the repository operator makes the final decision on whether to grant publication service to the prospective publisher. The <referral/> element just conveys a parent's grant of permission to use a portion of that parent's namespace.
これらのフィールドは、親が<parent_response />メッセージで子に提供した値のコピーです（セクション5.2.2を参照）。リファラー属性は、リポジトリーによる対応する証明書の検索を支援するために存在します。リポジトリオペレータは、発行予定者に発行サービスを許可するかどうかの最終決定を行うことに注意してください。 <referral />要素は、親の名前空間の一部を使用するための親の許可の付与を伝えるだけです。
---------------------------------------------------------------------
<publisher_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0001"
publisher_handle="Bob">
<publisher_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</publisher_bpki_ta>
</publisher_request>
---------------------------------------------------------------------
The <repository_response/> message is a repository's response to a publisher which has previously sent a <publisher_request/> message.
<repository_response />メッセージは、以前に<publisher_request />メッセージを送信したパブリッシャーに対するリポジトリの応答です。
Fields in the <repository_response/> message:
<repository_response />メッセージのフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
tag: If the <publisher_request/> message included a "tag" attribute, the repository MUST include an identical "tag" attribute in the <repository_response/> message; if the request did not include a tag attribute, the response MUST NOT include a tag attribute either.
タグ：<publisher_request />メッセージに「tag」属性が含まれている場合、リポジトリは<repository_response />メッセージに同一の「tag」属性を含める必要があります。リクエストにタグ属性が含まれていない場合、応答にもタグ属性を含めてはなりません（MUST NOT）。
service_uri: The service_uri attribute contains an HTTP or HTTPS URL [RFC7230] that the publisher should contact for publication service [RFC8181].
service_uri：service_uri属性には、パブリッシャーがパブリケーションサービス[RFC8181]のために連絡する必要があるHTTPまたはHTTPS URL [RFC7230]が含まれています。
publisher_handle: The publisher_handle attribute is the repository's name for the publisher. This may or may not match the publisher_handle attribute in the publisher's <publisher_request/> message.
publisher_handle：publisher_handle属性は、パブリッシャーのリポジトリの名前です。これは、パブリッシャーの<publisher_request />メッセージのpublisher_handle属性と一致する場合と一致しない場合があります。
sia_base: The sia_base attribute is the rsync:// URI for the base of the publication space allocated to the publisher.
sia_base：sia_base属性は、パブリッシャーに割り当てられたパブリケーションスペースのベースのrsync：// URIです。
rrdp_notification_uri: The optional rrdp_notification_uri attribute is the URI for the RPKI Repository Delta Protocol (RRDP) notification file covering the publication space allocated to the publisher [RFC8182].
rrdp_notification_uri：オプションのrrdp_notification_uri属性は、パブリッシャーに割り当てられたパブリケーションスペースをカバーするRPKIリポジトリデルタプロトコル（RRDP）通知ファイルのURIです[RFC8182]。
repository_bpki_ta: The <repository_bpki_ta/> element is the repository's BPKI identity, a self-signed X.509 BPKI certificate.
repository_bpki_ta：<repository_bpki_ta />要素は、リポジトリのBPKI ID、自己署名X.509 BPKI証明書です。
---------------------------------------------------------------------
<repository_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0001"
service_uri="http://a.example/publication/Alice/Bob-42"
publisher_handle="Alice/Bob-42"
sia_base="rsync://a.example/rpki/Alice/Bob-42/"
rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
The <authorization/> element is a separate message which is signed with CMS and then included as the Base64 content of <referral/> elements in other messages.
<authorization />要素は、CMSで署名され、他のメッセージの<referral />要素のBase64コンテンツとして含まれる個別のメッセージです。
The eContentType for the signed CMS message is id-ct-xml [RFC6492].
署名付きCMSメッセージのeContentTypeはid-ct-xml [RFC6492]です。
Fields in the <authorization/> element:
<authorization />要素のフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
authorized_sia_base: The value of the authorized_sia_base attribute is the rsync:// URI of the base of the namespace which the referrer is delegating.
authorized_sia_base：authorized_sia_base属性の値は、参照元が委任している名前空間のベースのrsync：// URIです。
BPKI TA: The text of the <authorization/> element is the identity of the entity to whom the referrer is delegating the portion of the namespace named in the authorized_sia_base attribute, represented as a Base64-encoded self-signed X.509 BPKI certificate.
BPKI TA：<authorization />要素のテキストは、referrerがauthorized_sia_base属性で指定された名前空間の一部を委任しているエンティティのIDであり、Base64でエンコードされた自己署名X.509 BPKI証明書として表されます。
---------------------------------------------------------------------
<authorization
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>
---------------------------------------------------------------------
The <error/> element is an optional message which can be used in response to any of the core protocol messages described in Section 5.2.
<error />要素は、セクション5.2で説明されているコアプロトコルメッセージのいずれかに応答して使用できるオプションのメッセージです。
Whether an <error/> element is an appropriate way to signal errors back to the sender of a protocol message depends on details of the implementation, which are outside this specification. For example, if this protocol is embedded in a web portal interface which is designed to let a human being upload and download these messages via upload and download forms, a human-readable error message may be more appropriate. On the other hand, a portal intended to be driven by a robotic client might well want to use an <error/> message to signal errors. Similar arguments apply to non-web encapsulations (such as email or a USB stick); the primary factor is likely to be whether the implementation expects the error to be handled by a human being or by a program.
<error />要素がプロトコルメッセージの送信者にエラーを通知する適切な方法であるかどうかは、この仕様外の実装の詳細に依存します。たとえば、人間がこれらのメッセージをアップロードおよびダウンロードフォームを介してアップロードおよびダウンロードできるように設計されたWebポータルインターフェースにこのプロトコルが埋め込まれている場合、人間が読めるエラーメッセージがより適切な場合があります。一方、ロボットクライアントによって駆動されるように意図されたポータルは、エラーを通知するために<error />メッセージを使用したい場合があります。 Web以外のカプセル化（電子メールやUSBスティックなど）にも同様の引数が適用されます。主な要因は、実装がエラーを人間またはプログラムのどちらで処理することを期待しているかであると考えられます。
Fields in the <error/> message:
<error />メッセージのフィールド：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
version：version属性は、プロトコルのバージョンを指定します。このノートでは、プロトコルバージョン1について説明します。
reason: The reason attribute contains a code indicating what was wrong with the message. This version of the protocol defines the following codes:
reason：reason属性には、メッセージの何が問題であったかを示すコードが含まれています。このバージョンのプロトコルは、次のコードを定義します。
syntax-error: Receiver could not parse the offending message.
syntax-error：レシーバーが問題のメッセージを解析できませんでした。
authentication-failure: Receiver could not authenticate the offending message.
authentication-failure：受信側は問題のメッセージを認証できませんでした。
refused: Receiver refused to perform the requested action.
refused：レシーバーは要求されたアクションの実行を拒否しました。
Offending message: The <error/> element contains a verbatim copy of the message to which this error applies.
問題のあるメッセージ：<error />要素には、このエラーが適用されるメッセージの逐語的なコピーが含まれています。
---------------------------------------------------------------------
<error
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
reason="refused">
<child_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
child_handle="Carol">
<child_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</child_bpki_ta>
</child_request>
</error>
---------------------------------------------------------------------
This section walks through a few simple examples of the protocol in use and stars our old friends, Alice, Bob, and Carol. In this example, Alice is the root of an RPKI tree, Bob wants to get address and Autonomous System Number (ASN) resources from Alice, and Carol wants to get some of those resources in turn from Bob. Alice offers publication service, which is used by all three.
このセクションでは、使用されているプロトコルの簡単な例をいくつか紹介し、旧友のアリス、ボブ、キャロルにスターを付けます。この例では、アリスはRPKIツリーのルートであり、ボブはアドレスと自律システム番号（ASN）リソースをアリスから取得し、キャロルはこれらのリソースの一部をボブから取得したいと考えています。アリスは、3つすべてで使用される公開サービスを提供しています。
Alice, Bob, and Carol each generate his or her own self-signed BPKI certificate.
アリス、ボブ、キャロルは、それぞれ自分の自己署名BPKI証明書を生成します。
Bob constructs a <child_request/> message and sends it to Alice:
Bobは<child_request />メッセージを作成し、それをAliceに送信します。
---------------------------------------------------------------------
<child_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
child_handle="Bob">
<child_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
o Bob's preferred handle is "Bob", so Bob uses that when setting
child_handle.
o <child_bpki_ta/> is Bob's self-signed BPKI certificate.
o <child_bpki_ta />は、ボブの自己署名BPKI証明書です。
Alice replies with a <parent_response/> message, but Alice already has 41 other children named Bob, so she calls this one "Bob-42". Alice's provisioning protocol server happens to use a RESTful URL scheme so that it can find the expected validation context for the provisioning protocol CMS message just by looking at the URL, so the service URL she provides to Bob includes both her name and Bob's. Alice offers publication service, so she offers to let Bob use it; Alice doesn't have to do this, she could just omit this and leave Bob to find publication service on his own, but Alice is trying to be helpful to her customer Bob. Bob doesn't have to accept Alice's offer, but may choose to do so.
アリスは<parent_response />メッセージで応答しますが、アリスはすでにBobという名前の41人の子を持っているため、これを「Bob-42」と呼びます。アリスのプロビジョニングプロトコルサーバーはたまたまRESTful URLスキームを使用しているため、URLを見ただけでプロビジョニングプロトコルCMSメッセージに期待される検証コンテキストを見つけることができるため、ボブに提供するサービスURLには名前とボブの両方が含まれます。アリスは出版サービスを提供しているので、ボブにそれを使用させることを提案します。アリスはこれを行う必要はありません。これを省略して、ボブに任せて自分で出版サービスを見つけることができますが、アリスは顧客のボブに役立つように努めています。ボブはアリスの申し出を受け入れる必要はありませんが、受け入れることを選択できます。
---------------------------------------------------------------------
<parent_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
service_uri="http://a.example/up-down/Alice/Bob-42"
child_handle="Bob-42"
parent_handle="Alice">
<parent_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</parent_bpki_ta>
<offer/>
</parent_response>
---------------------------------------------------------------------
o <parent_bpki_ta/> is Alice's own self-signed BPKI certificate.
o <parent_bpki_ta />は、アリス自身の自己署名BPKI証明書です。
Bob receives Alice's <parent_response/> and extracts the fields Bob's RPKI engine will need to know about (child_handle, parent_handle, service_uri, and <parent_bpki_ta/>). Bob also sees the repository offer, decides to take Alice up on this offer, and constructs a <publisher_request/> message accordingly:
ボブはアリスの<parent_response />を受け取り、ボブのRPKIエンジンが知る必要があるフィールド（child_handle、parent_handle、service_uri、および<parent_bpki_ta />）を抽出します。ボブはリポジトリの提案も確認し、この提案についてAliceを取り上げることを決定し、それに応じて<publisher_request />メッセージを作成します。
---------------------------------------------------------------------
<publisher_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0001"
publisher_handle="Bob">
<publisher_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</publisher_bpki_ta>
</publisher_request>
---------------------------------------------------------------------
Alice receives Bob's request to use Alice's publication service, decides to honor the offer she made, and sends back a <repository_response/> message in response. Alice recognizes Bob as one of her own children, because she's already seen Bob's self-signed BPKI certificate, so she allocates publication space to Bob under her own publication space, so that relying parties who rsync her products will pick up Bob's products automatically without needing an additional fetch operation.
アリスは、アリスの公開サービスを使用するボブの要求を受け取り、彼女が行った提案を尊重することを決定し、応答として<repository_response />メッセージを送り返します。アリスは、ボブの自己署名BPKI証明書をすでに見ているので、ボブを自分の子供の1人として認識し、自分のパブリケーションスペースの下でボブにパブリケーションスペースを割り当てます。追加のフェッチ操作。
---------------------------------------------------------------------
<repository_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0001"
service_uri="http://a.example/publication/Alice/Bob-42"
publisher_handle="Alice/Bob-42"
sia_base="rsync://a.example/rpki/Alice/Bob-42/"
rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
Bob should now have everything he needs to talk to Alice for both provisioning and publication.
これで、ボブはプロビジョニングと公開の両方でアリスと話すのに必要なすべてのものが揃うはずです。
A more interesting case is Bob's child, Carol. Carol wants to get her resources from Bob and, like Bob, does not particularly want to operate a publication service. Bob doesn't have a publication service of his own to offer, but he can refer Carol to Alice, along with his permission for Carol to use a portion of the namespace that Alice gave him.
より興味深いケースはボブの子供、キャロルです。キャロルはボブからリソースを取得したいと考えており、ボブと同様に、特に出版サービスを運営することを望んでいません。ボブには提供する独自の発行サービスはありませんが、アリスが彼に与えた名前空間の一部を使用することをキャロルに許可するとともに、キャロルをアリスに紹介することができます。
Carol's <child_request/> to Bob looks very similar to Bob's earlier request to Alice:
キャロルのボブへの<child_request />は、ボブの以前のアリスへのリクエストと非常によく似ています。
---------------------------------------------------------------------
<child_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
child_handle="Carol">
<child_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
Bob's <parent_response/> to Carol also looks a lot like Alice's response to Bob, except that Bob includes a <referral/> element instead of an <offer/> element. Carol is an only child, so Bob leaves her name alone:
キャロルへのボブの<parent_response />も、ボブへのアリスの応答によく似ていますが、ボブには<offer />要素ではなく<referral />要素が含まれている点が異なります。キャロルは一人っ子なので、ボブは自分の名前をそのままにしておきます。
---------------------------------------------------------------------
<parent_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
service_uri="http://bob.example/up-down/Bob/Carol"
child_handle="Carol"
parent_handle="Bob">
<parent_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</parent_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</parent_response>
---------------------------------------------------------------------
Bob's response includes a <referral/> element with a referrer attribute of "Alice/Bob-42", since that's Bob's name in Alice's repository. The Base64-encoded authorization token is an <authorization/> element in a CMS message that can be verified against Bob's self-signed BPKI certificate, using a BPKI EE certificate included in the CMS wrapper. The <authorization/> text is Carol's self-signed BPKI certificate; Bob's signature over this element indicates Bob's permission for Carol to use the indicated portion of Bob's publication space.
Bobの応答には、 "Alice / Bob-42"のリファラー属性を持つ<referral />要素が含まれています。これは、Aliceのリポジトリー内のBobの名前だからです。 Base64でエンコードされた認証トークンはCMSメッセージの<authorization />要素であり、CMSラッパーに含まれているBPKI EE証明書を使用して、ボブの自己署名BPKI証明書に対して検証できます。 <authorization />テキストはCarolの自己署名BPKI証明書です。この要素に対するボブの署名は、キャロルがボブの公開スペースの指定された部分を使用するボブの許可を示しています。
---------------------------------------------------------------------
<authorization
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>
---------------------------------------------------------------------
Carol, not wanting to have to run a publication service, presents Bob's referral to Alice in the hope that Alice will let Carol use Alice's publication service. So Carol constructs a <publisher_request/> message, including the referral information received from Bob, and sends it all to Alice:
キャロルは、パブリケーションサービスを実行する必要がないため、アリスがキャロルにアリスのパブリケーションサービスを使用することを期待して、アリスへのボブの紹介を提示します。したがって、キャロルはボブから受け取った紹介情報を含む<publisher_request />メッセージを作成し、それをすべてアリスに送信します。
---------------------------------------------------------------------
<publisher_request
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0002"
publisher_handle="Carol">
<publisher_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</publisher_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</publisher_request>
---------------------------------------------------------------------
Alice sees the signed authorization token Bob gave to Carol, checks its signature, and unpacks it. When the signature proves valid and the contained BPKI trust anchor (TA) matches Carol's, Alice knows that Bob is willing to let Carol use a portion of Bob's namespace. Given this, Alice is willing to provide publication service to Carol in the subtree allocated by Bob for this purpose, so Alice sends back a <repository_response/>:
アリスは、ボブがキャロルに与えた署名済みの認証トークンを確認し、その署名をチェックして、それを解凍します。署名が有効で、含まれているBPKIトラストアンカー（TA）がキャロルと一致すると、アリスはボブがキャロルにボブの名前空間の一部を使用することを許可する意思があることを認識します。このため、アリスはボブがこの目的のために割り当てたサブツリーでキャロルにパブリケーションサービスを提供する用意があるので、アリスは<repository_response />を送り返します。
---------------------------------------------------------------------
<repository_response
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
version="1"
tag="A0002"
service_uri="http://a.example/publication/Alice/Bob-42/Carol"
publisher_handle="Alice/Bob-42/Carol"
sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
Once Carol receives this response, Carol should be good to go.
キャロルがこの応答を受け取ったら、キャロルは準備完了です。
In theory, the publication referral mechanism can extend indefinitely (for example, Carol can refer her child Dave to Alice for publication service, and it should all work). In practice, this has not yet been implemented, much less tested. In order to keep the protocol relatively simple, we've deliberately ignored perverse cases such as Bob being willing to refer Carol to Alice but not wanting Carol to be allowed to refer Dave to Alice.
理論的には、公開紹介メカニズムは無期限に拡張できます（たとえば、キャロルは彼女の子供であるデイブを公開サービスのためにアリスに紹介することができ、すべて正常に機能するはずです）。実際には、これはまだ実装されておらず、はるかにテストされていません。プロトコルを比較的シンプルに保つために、ボブがキャロルをアリスに参照することをいとわないがキャロルがデイブをアリスに参照することを許可されたくないなど、私たちは意図的に間違ったケースを無視しました。
Any RPKI operator is free to run their own publication service should they feel a need to do so, and a child need not accept any particular <offer/> or <referral/>. In general, having a smaller number of larger publication repositories is probably good for overall system performance, because it will tend to reduce the number of distinct repositories from which each relying party will need to fetch, but the decision on where to publish is up to individual RPKI CA operators and out of scope for this protocol.
RPKIオペレーターは必要に応じて自由に独自のパブリケーションサービスを実行でき、子供は特定の<offer />または<referral />を受け入れる必要はありません。一般に、少数の大きなパブリケーションリポジトリがあることは、システム全体のパフォーマンスにとっておそらく良いことです。これは、各依存パーティがフェッチする必要がある個別のリポジトリの数を減らす傾向があるためですが、パブリッシュする場所の決定は個々のRPKI CAオペレーター、およびこのプロトコルの範囲外。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
As stated in Section 1, the basic function of this protocol is an exchange of public keys to be used as BPKI trust anchors. Integrity and authentication of these exchanges MUST be ensured via external mechanisms deliberately left unspecified in this protocol.
セクション1で述べたように、このプロトコルの基本的な機能は、BPKIトラストアンカーとして使用される公開鍵の交換です。これらの交換の完全性と認証は、このプロトコルで意図的に未指定のままにされた外部メカニズムを介して保証されなければなりません。
[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>。
[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>。
[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>。
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", RFC 8181, 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）」、RFC 8181、DOI 10.17487 / RFC8181、2017年7月、<http：// www .rfc-editor.org / info / rfc8181>。
[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>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[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>。
Here is a [RELAX-NG] schema describing the protocol elements.
これは、プロトコル要素を説明する[RELAX-NG]スキーマです。
This schema is normative: in the event of a disagreement between this schema and the document text above, this schema is authoritative.
このスキーマは規範的です。このスキーマと上記のドキュメントテキストが一致しない場合、このスキーマは信頼できます。
default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"
version = "1"
base64 = xsd:base64Binary { maxLength="512000" }
handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" }
uri = xsd:anyURI { maxLength="4096" }
any = element * { attribute * { text }*, ( any | text )* }
tag = xsd:token { maxLength="1024" }
authorization_token = base64 bpki_ta = base64
あうてょりざちおん＿とけん ＝ ばせ６４ ｂｐき＿た ＝ ばせ６４
start |= element child_request {
attribute version { version },
attribute child_handle { handle },
attribute tag { tag }?,
element child_bpki_ta { bpki_ta }
}
start |= element parent_response {
attribute version { version },
attribute service_uri { uri },
attribute child_handle { handle },
attribute parent_handle { handle },
attribute tag { tag }?,
element parent_bpki_ta { bpki_ta },
element offer { empty }?,
element referral {
attribute referrer { handle },
attribute contact_uri { uri }?,
authorization_token
}*
}
start |= element publisher_request {
attribute version { version },
attribute publisher_handle { handle },
attribute tag { tag }?,
element publisher_bpki_ta { bpki_ta },
element referral {
attribute referrer { handle }, authorization_token }* }
属性参照元{ハンドル}、authorization_token} *}
start |= element repository_response {
attribute version { version },
attribute service_uri { uri },
attribute publisher_handle { handle },
attribute sia_base { uri },
attribute rrdp_notification_uri { uri }?,
attribute tag { tag }?,
element repository_bpki_ta { bpki_ta }
}
start |= element authorization {
attribute version { version },
attribute authorized_sia_base { uri },
bpki_ta
}
start |= element error {
attribute version { version },
attribute reason {
"syntax-error" |
"authentication-failure" |
"refused"
},
any?
}
Acknowledgements
謝辞
The author would like to thank: Byron Ellacott, George Michaelson, Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush, Seiichi Kawamura, Tim Bruijnzeels, and anybody else who helped along the way but whose name the author has temporarily forgotten.
著者に感謝します：バイロンエラコット、ジョージマイケルソン、レイフヨハンソン、松崎吉信、マイケルエルキンズ、ランディブッシュ、川村誠一、ティムブライジンゼルス、および途中で手伝ったが著者の名前を一時的に忘れていた人。
Author's Address
著者のアドレス
Rob Austein Dragon Research Labs
ロブオースタインドラゴン研究所
Email: sra@hactrn.net