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
资源公钥基础设施 (RPKI) 生产服务的带外设置协议
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.
本说明描述了一种简单的带外协议，可简化双方之间资源公钥基础设施（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.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 7841 第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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.
版权所有 (c) 2017 IETF 信托基金会和文件作者。保留所有权利。
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) 的约束。请仔细阅读这些文件，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中所述的简化 BSD 许可文本，并且不提供简化 BSD 许可中所述的担保。
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].
本说明描述了一个基于 XML 的小型带外协议，用于在 RPKI 供应协议 [RFC6492] 中建立父协议和子协议之间的关系，以及在 RPKI 发布协议 [RFC8181] 中建立发布者和存储库之间的关系。
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 加密的网络界面、PGP 签名的电子邮件、印有快速反应（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", "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.
本设置协议所配置的所有协议都有自己的术语来描述其参与者，但在本协议中，这些术语变得有些混乱。本设置协议中的所有参与者都会签发证书、成为其他证书的主体、操作服务器，而且在大多数情况下，还会充当某个协议的客户端。因此，本说明使用自己的术语来描述本协议中的参与者。
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.
需要注意的是，某个实体可能扮演多个角色；例如，在一种最简单的情况下，子实体与发布者是同一个实体，而父实体与存储库是同一个实体。
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 配置协议并没有规定 BPKI 的特定结构，但有一个基本要求，即一方可以签署 CMS 信息，另一方可以验证 CMS 信息。这样就有了一定的灵活性，允许互联网注册机构重新使用现有的 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 采用了一个略有限制的模型。本协议的前两个操作是在子协议和父协议之间交换公钥，以便在供应协议中使用；本协议的后两个操作是在发布协议中交换公钥，以便在发布协议中使用。在每个操作中，发送方都会以自签 X.509 认证机构（CA）证书的形式提供自己的公钥。与交换的证书相对应的私钥不直接用于签署 CMS 信息；相反，交换的 CA 证书是 BPKI 终端实体 (EE) 证书的签发者，这些证书将包含在 CMS 信息中，可与交换的证书一起用于验证 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 的细节由实现自行决定，但建议的方法是在自己的 BPKI 下交叉认证收到的公开密钥和主体名，使用基本约束扩展 cA = TRUE，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:
例如，假设 Alice 和 Bob 各自拥有自己的自签 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:
Alice 向 Bob 发送自己签名的 BPKI 证书，Bob 在 Bob 自己签名的 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.
对允许使用的证书的完整描述超出了本文件的范围，因为这主要是由本协议处理设置的其他几个协议所接受的证书决定的。此外，我们预计这些要求会随着时间的推移而改变，以跟踪加密算法、所需密钥长度等方面的变化。最后，由于本协议仅限于建立成对关系，因此真正需要的是参与特定对话的双方就可接受证书的构成达成一致。
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 证书。这些证书用 XML 元素表示，其文本值是对 X.509 证书的 DER 表示进行编码的 Base64 文本（[RFC4648]，第 4 节，允许但不要求在 Base64 文本中换行）。
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.
该协议的核心由四种消息类型组成，分别代表配置 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.
版本：版本属性指定协议版本。本说明介绍协议版本 1。
tag: The child MAY include a "tag" attribute in the request message.
tag：子节点可以在请求信息中包含一个 "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/> 元素是子节点的 BPKI 标识，即以 Base64 编码的自签名 X.509 BPKI 证书。
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.
版本：版本属性指定协议版本。本说明介绍协议版本 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.
tag：如果 <child_request/> 消息包含 "tag "属性，则父节点必须在 <parent_response/> 消息中包含相同的 "tag "属性；如果请求不包含 tag 属性，则响应也不得包含 tag 属性。
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 属性包含一个 HTTP 或 HTTPS URL [RFC7230]，子节点应联系该 URL 以获得上行下行 [RFC6492] 服务。
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.
父_bpki_ta：<parent_bpki_ta/> 元素是父节点的 BPKI 标识，即自签名 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/>元素，它们会建议儿童使用第三方发布服务，并包含以下内容：
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> 元素，但严格来说，它们并不相互排斥，因此父节点如果确实需要表达它既向子节点提供版本库服务，又愿意将子节点转介到一个或多个其他版本库服务器，就可以这样做。
---------------------------------------------------------------------
<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.
版本：版本属性指定协议版本。本说明介绍协议版本 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.
发布者_bpki_ta：<publisher_bpki_ta/> 元素是发布者的 BPKI 标识，即自签名的 X.509 BPKI 证书。该证书是与私钥相对应的 BPKI EE 证书的签发者，发布者将使用该证书签署发布协议消息到版本库。
referral: If a <referral/> element is present, it contains:
推荐：如果存在 <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.
版本：版本属性指定协议版本。本说明介绍协议版本 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 "属性；如果请求不包含 tag 属性，那么响应也不得包含 tag 属性。
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 属性包含一个 HTTP 或 HTTPS URL [RFC7230]，发布者应联系该 URL 以获取发布服务 [RFC8181]。
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_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.
版本库_bpki_ta：<repository_bpki_ta/> 元素是版本库的 BPKI 标识，即自签名 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 信息的电子内容类型是 id-ct-xml [RFC6492]。
Fields in the <authorization/> element:
<authorization/> 元素中的字段：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
版本：版本属性指定协议版本。本说明介绍协议版本 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/> 元素的文本是转发者将 authorized_sia_base 属性中指定的命名空间部分委托给的实体的身份，以 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/> 元素是否是向协议信息发送者发出错误信号的适当方式，取决于实施的细节，而这些细节并不在本规范的范围之内。例如，如果该协议被嵌入到一个门户网站界面中，而该界面的设计目的是让人通过上传和下载表单上传和下载这些信息，那么人可读的错误信息可能更合适。另一方面，由机器人客户端驱动的门户网站可能更适合使用 <error/> 消息来提示错误。类似的论点也适用于非网络封装（如电子邮件或 U 盘）；主要因素可能是实现过程希望由人工还是程序来处理错误。
Fields in the <error/> message:
<error/> 消息中的字段：
version: The version attribute specifies the protocol version. This note describes protocol version 1.
版本：版本属性指定协议版本。本说明介绍协议版本 1。
reason: The reason attribute contains a code indicating what was wrong with the message. This version of the protocol defines the following codes:
原因：原因属性包含一个代码，说明报文出错的原因。该版本的协议定义了以下代码：
syntax-error: Receiver could not parse the offending message.
语法错误：接收器无法解析违规信息。
authentication-failure: Receiver could not authenticate the offending message.
身份验证失败：接收方无法验证违规信息。
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.
本节将举几个简单的例子来说明协议的使用情况，主角是我们的老朋友 Alice、Bob 和 Carol。在这个例子中，Alice 是一棵 RPKI 树的根，Bob 希望从 Alice 处获取地址和自治系统编号 (ASN) 资源，而 Carol 则希望从 Bob 处获取其中的一些资源。Alice 提供发布服务，三者都使用该服务。
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/> 消息，但爱丽丝已经有另外 41 个名叫鲍勃的孩子，所以她称这个孩子为 "鲍勃-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/> 是 Alice 自签的 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:
Bob 收到 Alice 的 <parent_response/>，并提取 Bob 的 RPKI 引擎需要知道的字段（child_handle、parent_handle、service_uri 和 <parent_bpki_ta/>）。Bob 也看到了版本库的提议，决定接受 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.
Alice 收到 Bob 使用 Alice 发布服务的请求后，决定履行自己的提议，并回发了一条 <repository_response/> 消息作为回应。Alice 认出 Bob 是自己的孩子，因为她已经看到了 Bob 自签名的 BPKI 证书，所以她在自己的发布空间下为 Bob 分配了发布空间，这样 rsync 她的产品的依赖方就会自动获取 Bob 的产品，而不需要额外的获取操作。
---------------------------------------------------------------------
<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/> 也很像爱丽丝给鲍勃的回复，只是鲍勃包含了一个 <referral/> 元素，而不是 <offer/> 元素。卡罗尔是独生子女，所以鲍勃只留下了她的名字：
---------------------------------------------------------------------
<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.
鲍勃的响应包括一个 <referrral/> 元素，其 referrer 属性为 "Alice/Bob-42"，因为这是鲍勃在 Alice 资源库中的名字。Base64 编码的授权令牌是 CMS 消息中的 <authorization/> 元素，可以使用 CMS 封装器中的 BPKI EE 证书，根据鲍勃的自签名 BPKI 证书进行验证。<authorization/> 文本是 Carol 的自签名 BPKI 证书；Bob 在该元素上的签名表示 Bob 允许 Carol 使用 Bob 的发布空间的指定部分。
---------------------------------------------------------------------
<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/>:
Alice 查看 Bob 交给 Carol 的签名授权令牌，检查其签名并解压缩。当签名证明有效且所含 BPKI 信任锚 (TA) 与 Carol 的相匹配时，Alice 就知道 Bob 愿意让 Carol 使用 Bob 命名空间的一部分。有鉴于此，Alice 愿意在 Bob 为此目的分配的子树上为 Carol 提供发布服务，因此 Alice 发回了 <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.
一旦收到回复，Carol 就可以开始工作了。
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] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002, <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., "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>.
[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, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <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., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, <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] Fielding, R., Ed. 和 J. Reschke, Ed., "超文本传输协议（HTTP/1.1）：消息语法和路由"，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., "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>。
[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., 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>。
[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., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <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., 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>.
[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, September 2009, <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/"
默认命名空间 = "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
授权令牌 = 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 }* }
attribute referrer { handle }, 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.
作者在此表示感谢：拜伦-埃拉考特（Byron Ellacott）、乔治-迈克尔逊（George Michaelson）、莱夫-约翰森（Leif Johansson）、松崎义信（Matsuzaki Yoshinobu）、迈克尔-埃尔金斯（Michael Elkins）、兰迪-布什（Randy Bush）、川村诚一（Seiichi Kawamura）、蒂姆-布鲁因泽斯（Tim Bruijnzeels），以及其他曾提供过帮助但作者暂时忘记其姓名的人。
Author's Address
作者地址
Rob Austein Dragon Research Labs
Rob Austein 龙研究实验室
Email: [email protected]