Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 8183 Dragon Research Labs
Category: Standards Track July 2017
ISSN: 2070-1721
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
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.
故意未指定此协议的底层传输。它可能是一个U盘，一个用传统HTTPS保护的web界面，一封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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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].
Repository：在[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消息的基本要求。这允许一定程度的灵活性，允许Internet注册中心将现有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
为了使该协议保持简单，我们采用了一个有一定约束的BPKI模型。此协议中的前两个操作是在子级和父级之间交换公钥，以便在配置协议中使用；此协议中的后两个操作是发布服务器和存储库之间的公钥交换，以在发布协议中使用。在这些操作中，发送方以自签名的X.509证书颁发机构（CA）证书的形式包括其公钥。这个
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.
交换证书对应的私钥不用于直接对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的详细信息留给实现，但建议的方法是使用基本约束扩展cA=TRUE，pathLenConstraint=0，在自己的BPKI下交叉认证收到的公钥和使用者名称，指示交叉认证证书是CA证书，允许颁发EE证书，但不允许颁发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 = 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
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
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:
稍后，当Bob从Alice收到CMS消息时，Bob可以通过信任链将此消息验证回Bob自己的信任锚：
Issuer: CN = Alice CA
Subject: CN = Alice EE
Public Key: [Alice EE Public Key]
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名称空间。
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元素，其文本值为Base64文本（[RFC4648]，第4节，Base64文本中允许但不需要换行符），编码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
许多属性包含“句柄”。本协议中的句柄是US-ASCII字符集中的文本字符串，由字母、数字和特殊字符“/”、“-”和“"组成。该协议没有在这些句柄的结构上放置特殊的语义，尽管实现可能会。句柄是协议元素，而不是
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.
因此，受限字符集的简单性比国际化文本所需的复杂规则更有意义。
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\u request/>消息是从配置协议子级到其配置协议父级的初始设置请求。
Fields in the <child_request/> message:
<child\u 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.
标记：子级可以在请求消息中包含“标记”属性。
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\u handle：child\u 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标识，一个自签名的X.509 bpki证书，用Base64编码。
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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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\u response/>消息是从设置协议父级到之前发送了<child\u request/>消息的设置协议子级的响应。
Fields in the <parent_response/> message:
<parent\u 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.
标记：如果<child\u request/>消息包含“tag”属性，则父级必须在<parent\u response/>消息中包含相同的“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\u handle：child\u handle属性是子级的父级名称。这可能与<child\u request/>消息中的child\u句柄相匹配。如果它们不匹配，则父级将获胜，因为父级可以在配置协议中指定名称。此值是设置协议请求消息中的发件人字段和设置协议响应消息中的收件人字段。
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_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标识，是一个自签名的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,
referer：一个referer属性，包含发布存储库知道父级的句柄，
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.
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>和<reflection>元素，但严格来说它们并不是相互排斥的，因此真正需要表示同时向其子级提供存储库服务并愿意将其子级引用到一个或多个其他存储库服务器的父级可以这样做。
---------------------------------------------------------------------
<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://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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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\u request/>消息是发布者向存储库发出的安装请求。通常，只有在发布者通过<child\u request/>/<parent\u response/>交换设置了设置协议之后，才会发生这种情况：特别是，这里的<reference>子元素需要设置协议交换提供的<authorization/>令牌。
Fields in the <publisher_request/> message:
<publisher\u 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\u handle：publisher\u 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标识，一个自签名的X.509 bpki证书。此证书是BPKI EE证书的颁发者，对应于发布者将用于向存储库签署发布协议消息的私钥。
referral: If a <referral/> element is present, it contains:
引用：如果存在<reflection/>元素，则它包含：
referrer: A referrer attribute containing the publication handle of the referring parent, and
referer：包含引用父级的发布句柄的referer属性，以及
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节）。referer属性用于帮助存储库查找相应的证书。请注意，存储库操作员对是否向潜在发布者授予发布服务做出最终决定。<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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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\u response/>消息是存储库对先前发送了<publisher\u request/>消息的发布者的响应。
Fields in the <repository_response/> message:
<repository\u 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\u request/>消息包含“tag”属性，则存储库必须在<repository\u response/>消息中包含相同的“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属性包含发布者应联系以获取发布服务[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\u handle：publisher\u handle属性是发布服务器的存储库名称。这可能与发布者的<publisher\u request/>消息中的publisher\u 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标识，一个自签名的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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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.
版本：版本属性指定协议版本。本说明描述了协议版本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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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封装（如电子邮件或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.
拒绝：接收方拒绝执行请求的操作。
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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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.
Alice、Bob和Carol各自生成自己的自签名BPKI证书。
Bob constructs a <child_request/> message and sends it to Alice:
Bob构造一条<child\u 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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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 Bob首选的句柄是“Bob”，因此Bob在设置child_句柄时使用该句柄。
o <child_bpki_ta/> is Bob's self-signed BPKI certificate.
o <child\u bpki\u ta/>是Bob的自签名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.
Alice回复了一条<parent\u response/>消息，但是Alice已经有41个孩子叫Bob，所以她称这一个为“Bob-42”。Alice的provisioning protocol server碰巧使用了RESTful URL方案，因此它可以通过查看URL找到provisioning protocol CMS消息的预期验证上下文，因此她提供给Bob的服务URL包括她的姓名和Bob的姓名。爱丽丝提供出版服务，所以她愿意让鲍勃使用它；Alice不必这样做，她可以省略这个，让Bob自己去找出版服务，但是Alice正在努力帮助她的客户Bob。鲍勃不必接受爱丽丝的提议，但可以选择接受。
---------------------------------------------------------------------
<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://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\u response/>并提取Bob的RPKI引擎需要知道的字段（子句柄、父句柄、服务uri和<parent\u bpki\u ta/>）。Bob还看到了存储库的提议，决定接受Alice的提议，并相应地构造了一条<publisher\u 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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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\u 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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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.
Bob现在应该拥有与Alice进行资源调配和发布所需的一切。
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.
一个更有趣的例子是鲍勃的孩子卡罗尔。卡罗尔想从鲍勃那里得到她的资源，和鲍勃一样，她并不特别想经营出版服务。Bob没有自己的发布服务，但他可以将Carol推荐给Alice，同时允许Carol使用Alice提供给他的部分命名空间。
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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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:
Bob对Carol的<parent_response/>也很像Alice对Bob的反应，只是Bob包含了<reflection/>元素而不是<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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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的响应包含一个<reference/>元素，该元素的referer属性为“Alice/Bob-42”，因为这是Alice存储库中Bob的名字。Base64编码的授权令牌是CMS消息中的<authorization/>元素，可以使用CMS包装中包含的BPKI EE证书根据Bob的自签名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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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:
卡罗尔不想经营出版服务，将鲍勃的推荐信提交给爱丽丝，希望爱丽丝能让卡罗尔使用爱丽丝的出版服务。因此，Carol构建了一条<publisher\u request/>消息，包括从Bob收到的推荐信息，并将其全部发送给Alice：
---------------------------------------------------------------------
<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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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\u 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>
---------------------------------------------------------------------
---------------------------------------------------------------------
<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.
理论上，出版物推荐机制可以无限期地扩展（例如，Carol可以将她的孩子Dave推荐给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/>或<reference/>。一般来说，拥有较少数量的大型发布存储库可能有利于整体系统性能，因为这将减少每个依赖方需要从中获取的不同存储库的数量，但发布位置的决定取决于各个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紧凑语法”，绿洲委员会规范，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.，“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，“资源证书供应协议”，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]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.，“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，“资源公钥基础设施（RPKI）的发布协议”，RFC 8181，DOI 10.17487/RFC8181812017年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，“RPKI存储库增量协议（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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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.，“加密消息语法（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/"
default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"
version = "1"
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" }
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
授权\u令牌=base64 bpki\u ta=base64
start |= element child_request {
attribute version { version },
attribute child_handle { handle },
attribute tag { tag }?,
element child_bpki_ta { bpki_ta }
}
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 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 {
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 }* }
属性引用者{handle}，授权{u令牌}*}
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 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 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?
}
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
Rob Austein Dragon研究实验室
Email: sra@hactrn.net
Email: sra@hactrn.net