Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6480 S. Kent
Category: Informational BBN Technologies
ISSN: 2070-1721 February 2012
Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6480 S. Kent
Category: Informational BBN Technologies
ISSN: 2070-1721 February 2012
An Infrastructure to Support Secure Internet Routing
支持安全Internet路由的基础结构
Abstract
摘要
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.
本文档描述了支持改进的Internet路由安全性的基础设施的体系结构。该体系结构的基础是资源公共密钥基础设施（RPKI），它代表IP地址空间和自治系统（AS）号码的分配层次；以及分布式存储库系统，用于存储和分发组成RPKI的数据对象以及改进路由安全性所需的其他签名对象。作为该体系结构的初始应用，本文档描述了IP地址空间的合法持有人如何明确且可验证地授权一个或多个ASE发起到该地址空间的路由。例如，可以使用这种可验证授权来更安全地构造BGP路由过滤器。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc6480.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6480.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
1.1. Terminology ................................................4
2. Public Key Infrastructure for Internet Number Resources .........4
2.1. Role in the Overall Architecture ...........................5
2.2. CA Certificates ............................................6
2.3. End-Entity (EE) Certificates ...............................7
2.4. Trust Anchors ..............................................8
3. Route Origination Authorizations ................................9
3.1. Role in the Overall Architecture ...........................9
3.2. Syntax and Semantics ......................................10
4. Repositories ...................................................11
4.1. Role in the Overall Architecture ..........................12
4.2. Contents and Structure ....................................12
4.3. Access Protocols ..........................................14
4.4. Access Control ............................................15
5. Manifests ......................................................15
5.1. Syntax and Semantics ......................................15
6. Local Cache Maintenance ........................................16
7. Common Operations ..............................................17
7.1. Certificate Issuance ......................................17
7.2. CA Key Rollover ...........................................18
7.3. ROA Management ............................................19
7.3.1. Single-Homed Subscribers ...........................20
7.3.2. Multi-Homed Subscribers ............................20
7.3.3. Provider-Independent Address Space .................21
8. Security Considerations ........................................21
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Public Key Infrastructure for Internet Number Resources .........4
2.1. Role in the Overall Architecture ...........................5
2.2. CA Certificates ............................................6
2.3. End-Entity (EE) Certificates ...............................7
2.4. Trust Anchors ..............................................8
3. Route Origination Authorizations ................................9
3.1. Role in the Overall Architecture ...........................9
3.2. Syntax and Semantics ......................................10
4. Repositories ...................................................11
4.1. Role in the Overall Architecture ..........................12
4.2. Contents and Structure ....................................12
4.3. Access Protocols ..........................................14
4.4. Access Control ............................................15
5. Manifests ......................................................15
5.1. Syntax and Semantics ......................................15
6. Local Cache Maintenance ........................................16
7. Common Operations ..............................................17
7.1. Certificate Issuance ......................................17
7.2. CA Key Rollover ...........................................18
7.3. ROA Management ............................................19
7.3.1. Single-Homed Subscribers ...........................20
7.3.2. Multi-Homed Subscribers ............................20
7.3.3. Provider-Independent Address Space .................21
8. Security Considerations ........................................21
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
This document describes an architecture for an infrastructure to support improved security for BGP routing [RFC4271] for the Internet. The architecture encompasses three principle elements:
本文档描述了一种基础架构，该基础架构支持改进的互联网BGP路由[RFC4271]安全性。该体系结构包含三个主要元素：
o Resource Public Key Infrastructure (RPKI)
o 资源公钥基础设施（RPKI）
o digitally signed routing objects to support routing security
o 支持路由安全的数字签名路由对象
o a distributed repository system to hold the PKI objects and the signed routing objects
o 用于保存PKI对象和已签名路由对象的分布式存储库系统
The architecture described by this document enables an entity to verifiably assert that it is the legitimate holder of a set of IP addresses or a set of Autonomous System (AS) numbers. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. In addition to this initial application, the infrastructure defined by this architecture also is intended to provide future support for security protocols such as Secure BGP [S-BGP] or Secure Origin BGP [soBGP]. This architecture is applicable to the routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address families supported by this architecture. Thus, for example, use of this architecture with MPLS labels is beyond the scope of this document.
本文档描述的体系结构使实体能够以可验证的方式断言它是一组IP地址或一组自治系统（AS）号码的合法持有者。作为该体系结构的初始应用，本文档描述了IP地址空间的合法持有人如何明确且可验证地授权一个或多个ASE发起到该地址空间的路由。例如，可以使用这种可验证授权来更安全地构造BGP路由过滤器。除此初始应用程序外，此体系结构定义的基础设施还旨在为安全BGP[S-BGP]或安全源BGP[soBGP]等安全协议提供未来支持。该体系结构适用于IPv4和IPv6数据报的路由。IPv4和IPv6是此体系结构当前唯一支持的地址系列。因此，例如，将此体系结构与MPLS标签一起使用超出了本文档的范围。
In order to facilitate deployment, the architecture takes advantage of existing technologies and practices. The structure of the PKI element of the architecture corresponds to the existing resource allocation structure. Thus management of this PKI is a natural extension of the resource-management functions of the organizations that are already responsible for IP address and AS number resource allocation. Likewise, existing resource allocation and revocation practices have well-defined correspondents in this architecture. Note that while the initial focus of this architecture is routing security applications, the PKI described in this document could be used to support other applications that make use of attestations of IP address or AS number resource holdings.
为了便于部署，该体系结构利用了现有的技术和实践。体系结构的PKI元素的结构与现有的资源分配结构相对应。因此，该PKI的管理是已经负责IP地址和AS号码资源分配的组织的资源管理功能的自然扩展。同样，现有的资源分配和撤销实践在该体系结构中也有定义良好的对应关系。请注意，虽然此体系结构的最初重点是路由安全应用程序，但本文档中描述的PKI可用于支持使用IP地址证明或作为数字资源持有的其他应用程序。
To ease implementation, existing IETF standards are used wherever possible; for example, extensive use is made of the X.509 certificate profile defined by the Public Key Infrastructure using X.509 (PKIX) [RFC5280] working group and the extensions for IP addresses and AS numbers representation defined in RFC 3779 [RFC3779]. Also, Cryptographic Message Syntax (CMS) [RFC5652] is used as the syntax
为便于实施，尽可能使用现有的IETF标准；例如，广泛使用公钥基础设施使用X.509（PKIX）[RFC5280]工作组定义的X.509证书配置文件，以及RFC 3779[RFC3779]中定义的IP地址和AS数字表示的扩展。此外，还使用加密消息语法（CMS）[RFC5652]作为语法
for the newly defined signed objects [RFC6488] required by this infrastructure.
用于此基础结构所需的新定义的签名对象[RFC6488]。
As noted above, the architecture is comprised of three main components: an X.509 PKI in which certificates attest to holdings of IP address space and AS numbers; non-certificate signed objects (including route origination authorizations and manifests) used by the infrastructure; and a distributed repository system that makes all of these signed objects available for use by ISPs in making routing decisions. These three basic components enable several security functions; most notably the cryptographic validation that an autonomous system is authorized to originate routes to a given prefix [RFC6483].
如上所述，该体系结构由三个主要组件组成：一个X.509 PKI，其中证书证明持有IP地址空间和As号码；基础设施使用的非证书签名对象（包括路由发起授权和清单）；以及一个分布式存储库系统，它使所有这些签名对象都可供ISP在做出路由决策时使用。这三个基本组件支持多种安全功能；最值得注意的是加密验证，即授权自治系统发起到给定前缀的路由[RFC6483]。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
假设读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]和“IP地址和AS标识符的X.509扩展”[RFC3779]中描述的术语和概念。
Throughout this document, we use the terms "address space holder" or "holder of IP address space" interchangeably to refer to a legitimate holder of IP address space who has received this address space through the standard IP address allocation hierarchy. That is, the address space holder has either directly received the address space as an allocation from a Regional Internet Registry (RIR) or IANA; or else the address space holder has received the address space as a sub-allocation from a National Internet Registry (NIR) or Local Internet Registry (LIR). We use the term "resource holder" to refer to a legitimate holder of either IP address or AS number resources.
在本文档中，我们交替使用术语“地址空间持有人”或“IP地址空间持有人”来指通过标准IP地址分配层次结构接收该地址空间的合法IP地址空间持有人。也就是说，地址空间持有者直接从区域互联网注册中心（RIR）或IANA收到地址空间作为分配；或者地址空间持有人已从国家互联网注册中心（NIR）或本地互联网注册中心（LIR）收到地址空间作为子分配。我们使用术语“资源持有者”来指IP地址或作为资源编号的合法持有者。
Throughout this document, we use the terms "registry" and "ISP" to refer to an entity that has an IP address space and/or AS number allocation that it is permitted to sub-allocate.
在本文档中，我们使用术语“注册表”和“ISP”来指具有IP地址空间和/或作为允许再分配的号码分配的实体。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Because the holder of a block of IP address space is entitled to define the topological destination of IP datagrams whose destinations fall within that block, decisions about inter-domain routing are inherently based on knowledge of the allocation of the IP address space. Thus, a basic function of this architecture is to provide
由于IP地址空间块的持有者有权定义IP数据报的拓扑目的地，其目的地位于该块内，因此关于域间路由的决策本质上是基于IP地址空间分配的知识。因此，该体系结构的一个基本功能是提供
cryptographically verifiable attestations as to these allocations. In current practice, the allocation of IP addresses is hierarchical. The root of the hierarchy is IANA. Below IANA are five Regional Internet Registries (RIRs), each of which manages address and AS number allocation within a defined geopolitical region. In some regions, the third tier of the hierarchy includes National Internet Registries (NIRs) as well as Local Internet Registries (LIRs) and subscribers with so-called provider-independent ("portable") allocations. (The term "LIR" is used in some regions to refer to what other regions define as an ISP. Throughout the rest of this document, we will use the term "LIR/ISP" to simplify references to these entities.) In other regions, the third tier consists only of LIRs/ISPs and subscribers with provider-independent allocations.
关于这些分配的可加密验证的证明。在当前实践中，IP地址的分配是分层的。层次结构的根是IANA。IANA下面是五个区域互联网注册中心（RIR），每个注册中心管理一个特定地缘政治区域内的地址和AS号码分配。在一些地区，等级结构的第三层包括国家互联网注册中心（NIR）和地方互联网注册中心（LIR）以及具有所谓独立于提供商（“便携”）分配的订户。（在某些地区，术语“LIR”用于指代其他地区定义为ISP的内容。在本文档的其余部分，我们将使用术语“LIR/ISP”来简化对这些实体的引用。）在其他地区，第三层仅由具有独立于提供商分配的LIR/ISP和订户组成。
In general, the holder of a block of IP address space may sub-allocate portions of that block, either to itself (e.g., to a particular unit of the same organization), or to another organization, subject to contractual constraints established by the registries. Because of this structure, IP address allocations can be described naturally by a hierarchic public key infrastructure, in which each certificate attests to an allocation of IP addresses, and issuance of subordinate certificates corresponds to sub-allocation of IP addresses. The above reasoning holds true for AS number resources as well, with the difference that, by convention, AS numbers may not be sub-allocated except by RIRs or NIRs. Thus, allocations of both IP addresses and AS numbers can be expressed by the same PKI. Such a PKI, which is henceforth referred to as the "Resource Public Key Infrastructure (RPKI)", is a central component of this architecture.
一般来说，IP地址空间块的持有者可以将该块的部分再分配给自己（例如，分配给同一组织的特定单位），或者分配给另一组织，但须受注册中心确定的合同约束。由于这种结构，IP地址分配可以自然地由分层公钥基础结构来描述，其中每个证书证明IP地址的分配，并且从属证书的颁发对应于IP地址的子分配。上述推理同样适用于AS编号资源，不同之处在于，按照惯例，AS编号只能通过RIR或NIR进行分配。因此，IP地址和AS号码的分配可以用相同的PKI表示。这种公钥基础设施（PKI）被称为“资源公钥基础设施（RPKI）”，是该体系结构的核心组成部分。
Certificates in this PKI are called resource certificates, and conform to the certificate profile for such certificates [RFC6487]. Resource certificates attest to the allocation by the (certificate) issuer of IP addresses or AS numbers to the subject. They do this by binding the public key contained in the resource certificate to the IP addresses or AS numbers included in the certificate's IP Address Delegation or AS Identifier Delegation extensions, respectively, as defined in RFC 3779 [RFC3779].
此PKI中的证书称为资源证书，并符合此类证书的证书配置文件[RFC6487]。资源证书证明（证书）颁发者将IP地址或数字分配给主题。它们通过将资源证书中包含的公钥分别绑定到IP地址或证书的IP地址委派中包含的数字或标识符委派扩展（如RFC 3779[RFC3779]中的定义）来实现这一点。
An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate. Because issuers
此PKI的一个重要特性是证书不能证明主体的身份。因此，证书中使用的主题名称并不具有“描述性”。也就是说，资源PKI旨在提供授权，而不是身份验证。这与大多数PKI不同，在PKI中，颁发者确保证书中的描述性主体名称与持有与证书中公钥对应的私钥的实体正确关联。因为发行人
need not verify the right of an entity to use a subject name in a certificate, they avoid the costs and liabilities of such verification. This makes it easier for these entities to take on the additional role of Certification Authority (CA).
无需验证实体在证书中使用主体名称的权利，可避免此类验证的成本和责任。这使得这些实体更容易承担证书颁发机构（CA）的额外角色。
Most of the certificates in the PKI assert the basic facts on which the rest of the infrastructure operates. CA certificates within the PKI attest to IP address space and AS number holdings. End-entity (EE) certificates are issued by resource holder CAs to delegate the authority attested by their allocation certificates. The primary use for EE certificates is the validation of Route Origination Authorizations (ROAs), signed objects which provide an explicit authorization by an address holder that a given AS is permitted to originate routes to a set of addresses (see Section 3). End-entity certificates are also used to verify other signed objects, such as manifests, which will be used to help ensure the integrity of the repository system (see Section 5).
PKI中的大多数证书都声明了基础设施其余部分操作所依据的基本事实。PKI中的CA证书证明了IP地址空间和AS号码持有情况。终端实体（EE）证书由资源持有者CA颁发，以授权由其分配证书证明的权限。EE证书的主要用途是验证路由发起授权（ROA），即签名对象，该对象由地址持有人提供明确授权，允许给定AS发起到一组地址的路由（见第3节）。终端实体证书还用于验证其他已签名对象，如清单，清单将用于帮助确保存储库系统的完整性（请参见第5节）。
Any resource holder who is authorized to sub-allocate these resources must be able to issue resource certificates to correspond to these sub-allocations. Thus, for example, CA certificates will be associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. Also, a CA certificate is required to enable a resource holder to issue ROAs, because it must issue the corresponding end-entity certificate used to validate each ROA. Thus, some entities that do not sub-allocate their resources also will need to have CA certificates for their allocations, e.g., a multi-homed subscriber with a provider-independent allocation, to enable them to issue ROAs. (A subscriber who is not multi-homed, whose allocation comes from an LIR/ISP, and who has not moved to a different LIR/ISP, need not be represented in the PKI. Moreover, a multi-homed subscriber with an allocation from an LIR/ISP may or may not need to be explicitly represented, as discussed in Section 7.3.2).
任何有权再分配这些资源的资源持有者必须能够颁发资源证书，以与这些再分配相对应。因此，例如，CA证书将与IANA以及每个RIR、NIR和LIR/ISP相关联。此外，资源持有者需要CA证书才能颁发ROA，因为它必须颁发用于验证每个ROA的相应终端实体证书。因此，一些未分配其资源的实体也需要有CA证书来进行分配，例如，具有独立于提供商分配的多宿订户，以使其能够颁发ROA。（非多宿用户、其分配来自LIR/ISP且未移动到其他LIR/ISP的用户无需在PKI中表示。此外，具有LIR/ISP分配的多宿用户可能需要也可能不需要明确表示，如第7.3.2节所述）。
Unlike in most PKIs, the distinguished name of the subject in a CA certificate is chosen by the certificate issuer. The subject's distinguished name must not attempt to convey the identity of the subject in a descriptive fashion. The subject's distinguished name must include the CommonName attribute and may additionally include the serial attribute.
与大多数PKI不同，CA证书中主体的可分辨名称由证书颁发者选择。受试者的专有名称不得试图以描述性方式传达受试者的身份。受试者的可分辨名称必须包括CommonName属性，还可以包括serial属性。
In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the business of verifying the legal right of the subject to assert a particular identity. Therefore, selecting a distinguished name that does not convey the identity of the subject in a descriptive fashion minimizes the opportunity for the subject to
在该PKI中，作为RIR、NIR或LIR/ISP的证书颁发者不负责验证主体主张特定身份的合法权利。因此，选择一个不以描述性方式传达受试者身份的可分辨名称，可最大限度地减少受试者使用该名称的机会
misuse the certificate to assert an identity, and thus minimizes the legal liability of the issuer. Since all CA certificates are issued to subjects with whom the issuer has an existing relationship, it is recommended that the issuer select a subject name that enables the issuer to easily link the certificate to existing database records associated with the subject. For example, an authority may use internal database keys or subscriber IDs as the subject's common name in issued certificates.
滥用证书来维护身份，从而将发行人的法律责任降至最低。由于所有CA证书都颁发给与颁发者有现有关系的主体，因此建议颁发者选择一个主体名称，使颁发者能够轻松地将证书链接到与该主体关联的现有数据库记录。例如，授权机构可以在颁发的证书中使用内部数据库密钥或订户ID作为主体的通用名称。
Although the subject's common name in a certificate does not convey identity, it is still the case that the common name must be unique among all subjects to whom a certification authority issues certificates. That is, a CA must not issue certificates to two different entities that use the same common name for the subject.
尽管证书中主体的通用名称并不表示身份，但在证书颁发机构向其颁发证书的所有主体中，通用名称必须是唯一的。也就是说，CA不得向两个不同的实体颁发证书，这两个实体对主题使用相同的通用名称。
Each resource certificate attests to an allocation of resources to a resource holder, so entities that have allocations from multiple sources will have multiple CA certificates. Note that when an entity receives multiple certificates from different issuers, the subject names in these certificates will generally be different. A CA also may issue distinct certificates for each distinct allocation to the same entity, if the CA and the resource holder agree that such an arrangement will facilitate management and use of the certificates. For example, an LIR/ISP may have several certificates issued to it by one registry, each describing a distinct set of address blocks, because the LIR/ISP desires to treat the allocations as separate.
每个资源证书都证明资源分配给资源持有者，因此具有多个源分配的实体将具有多个CA证书。请注意，当一个实体收到来自不同发行人的多个证书时，这些证书中的主体名称通常会不同。如果CA和资源持有人同意这种安排将有助于证书的管理和使用，CA还可以为同一实体的每个不同分配颁发不同的证书。例如，一个LIR/ISP可能有多个由一个注册表颁发给它的证书，每个证书描述一组不同的地址块，因为LIR/ISP希望将分配视为单独的。
The private key corresponding to a public key contained in an EE certificate is not used to sign other certificates in a PKI. The primary function of end-entity certificates in this PKI is the verification of signed objects that relate to the usage of the resources described in the certificate, e.g., ROAs and manifests.
EE证书中包含的公钥对应的私钥不用于对PKI中的其他证书进行签名。此PKI中终端实体证书的主要功能是验证与证书中描述的资源使用相关的已签名对象，例如ROA和清单。
For ROAs and manifests, there will be a one-to-one correspondence between end-entity certificates and signed objects, i.e., the private key corresponding to each end-entity certificate is used to sign exactly one object, and each object is signed with only one key. This property allows the PKI to be used to revoke these signed objects, rather than creating a new revocation mechanism. When the end-entity certificate used to sign an object has been revoked, the signature on that object (and any corresponding assertions) will be considered invalid, so a signed object can be effectively revoked by revoking the end-entity certificate used to sign it.
对于ROA和清单，终端实体证书和已签名对象之间将存在一对一的对应关系，即，每个终端实体证书对应的私钥仅用于签名一个对象，每个对象仅使用一个密钥签名。此属性允许使用PKI撤销这些已签名对象，而不是创建新的撤销机制。当用于对对象进行签名的最终实体证书被吊销时，该对象上的签名（以及任何相应的断言）将被视为无效，因此可以通过吊销用于对其进行签名的最终实体证书来有效地吊销已签名的对象。
A secondary advantage to this one-to-one correspondence is that the private key corresponding to the public key in a certificate is used
这种一对一通信的第二个优点是使用与证书中的公钥对应的私钥
exactly once in its lifetime, and thus can be destroyed after it has been used to sign its one object. This fact should simplify key management, since there is no requirement to protect these private keys for an extended period of time.
在它的生命周期中只有一次，因此可以在它被用来为它的一个对象签名后被销毁。这一事实应该简化密钥管理，因为不需要长时间保护这些私钥。
The EE certificate used to verify a signed object appears in the Cryptographic Message Syntax (CMS) wrapper (see [RFC6488]) of the signed object. Therefore, it is not necessary to transmit the EE certificate separately from the signed object. Likewise, it is not necessary for the EE certificate to appear in the RPKI repository system except as part of the corresponding signed object.
用于验证签名对象的EE证书出现在签名对象的加密消息语法（CMS）包装（请参见[RFC6488]）中。因此，没有必要将EE证书与签名对象分开传输。同样，除了作为相应签名对象的一部分之外，EE证书不必出现在RPKI存储库系统中。
Although this document describes only two uses for end-entity certificates, additional uses will likely be defined in the future. For example, end-entity certificates could be used as a more general authorization for their subjects to act on behalf of the specified resource holder. This could facilitate authentication of inter-ISP interactions, or authentication of interactions with the repository system. These additional uses for end-entity certificates may require retention of the corresponding private keys, even though such retention is not required for keys used to sign ROAs and manifests.
尽管本文档仅描述了终端实体证书的两种用途，但将来可能会定义其他用途。例如，终端实体证书可以用作其主体代表指定资源持有者行事的更一般授权。这有助于验证ISP之间的交互，或验证与存储库系统的交互。终端实体证书的这些额外用途可能需要保留相应的私钥，即使用于签署ROA和清单的密钥不需要这样的保留。
In any PKI, each relying party (RP) chooses its own set of trust anchors (TAs). This general property of PKIs applies here as well. There is an extant IP address space and AS number allocation hierarchy, and thus IANA and/or the five RIRs are obvious candidates to be default TAs here. Nonetheless, each RP ultimately chooses the set of trust anchors it will use for certificate validation.
在任何PKI中，每个依赖方（RP）都选择自己的一组信任锚（TA）。PKIs的这一一般属性也适用于这里。存在现有的IP地址空间和AS号码分配层次结构，因此IANA和/或五个RIR显然是这里默认TA的候选。尽管如此，每个RP最终还是会选择一组用于证书验证的信任锚。
For example, an RP (e.g., an LIR/ISP) could create a trust anchor to which all address space and/or all AS numbers are assigned, and for which the RP knows the corresponding private key. The RP could then issue certificates under this trust anchor to whatever entities in the PKI it wishes, with the result that the certification paths terminating at this locally installed trust anchor will satisfy the validation requirements specified in RFC 3779. A large ISP that uses private IP address space (i.e., RFC 1918) and runs BGP internally will need to create this sort of trust anchor to accommodate a CA to which all private address space is assigned. The RP could then issue certificates under this CA that correspond to the RP's internal use of private address space.
例如，RP（例如，LIR/ISP）可以创建一个信任锚，所有地址空间和/或所有AS号都分配给该信任锚，并且RP知道相应的私钥。然后，RP可以向PKI中它希望的任何实体颁发该信任锚下的证书，其结果是终止于该本地安装的信任锚的证书路径将满足RFC 3779中规定的验证要求。使用专用IP地址空间（即RFC 1918）并在内部运行BGP的大型ISP需要创建这种信任锚，以容纳分配了所有专用地址空间的CA。RP然后可以在此CA下颁发证书，证书对应于RP对私有地址空间的内部使用。
Note that an RP who elects to create and manage its own set of trust anchors may fail to detect allocation errors that arise under such circumstances, but the resulting vulnerability is local to the RP.
请注意，选择创建和管理自己的信任锚集的RP可能无法检测到在这种情况下出现的分配错误，但由此产生的漏洞是RP的本地漏洞。
It is expected that some parties within the extant IP address space and AS number allocation hierarchy may wish to publish trust anchor material for possible use by relying parties. A standard profile for the publication of trust anchor material for this public key infrastructure can be found in [RFC6490].
预计现有IP地址空间和AS号码分配层次结构中的某些方可能希望发布信任锚材料，以供依赖方可能使用。可在[RFC6490]中找到发布此公钥基础结构的信任锚材料的标准配置文件。
The information on IP address allocation provided by the PKI is not, in itself, sufficient to guide routing decisions. In particular, BGP is based on the assumption that the AS that originates routes for a particular prefix is authorized to do so by the holder of that prefix (or an address block encompassing the prefix); the PKI contains no information about these authorizations. A Route Origination Authorization (ROA) makes such authorization explicit, allowing a holder of IP address space to create an object that explicitly and verifiably asserts that an AS is authorized to originate routes to a given set of prefixes.
PKI提供的IP地址分配信息本身不足以指导路由决策。特别地，BGP基于这样的假设，即为特定前缀发起路由的AS被该前缀的持有者（或包含该前缀的地址块）授权这样做；PKI不包含有关这些授权的信息。路由发起授权（ROA）使该授权明确，允许IP地址空间的持有者创建一个对象，该对象明确且可验证地断言AS被授权发起到给定前缀集的路由。
A ROA is an attestation that the holder of a set of prefixes has authorized an autonomous system to originate routes for those prefixes. A ROA is structured according to the format described in [RFC6482]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA; this fact is asserted by an end-entity certificate from the PKI, whose corresponding private key is used to sign the ROA.
ROA是一种证明，证明一组前缀的持有者已授权一个自治系统为这些前缀发起路由。根据[RFC6482]中描述的格式构造ROA。此授权的有效性取决于居留权的签署人是居留权前缀的持有人；这一事实由来自PKI的最终实体证书断言，其相应的私钥用于签署ROA。
ROAs may be used by relying parties to verify that the AS that originates a route for a given IP address prefix is authorized by the holder of that prefix to originate such a route. For example, an ISP might use validated ROAs as inputs to route filter construction for use by its BGP routers. (See [RFC6483] for information on the use of ROAs to validate the origination of BGP routes.)
依赖方可以使用ROA来验证为给定IP地址前缀发起路由的AS是否被该前缀的持有者授权发起该路由。例如，ISP可能使用已验证的ROA作为输入，以路由筛选器构造，供其BGP路由器使用。（有关使用ROA验证BGP路由发起的信息，请参见[RFC6483]）
Initially, the repository system will be the primary mechanism for disseminating ROAs, since these repositories will hold the certificates and CRLs needed to verify ROAs. In addition, ROAs also could be distributed in BGP UPDATE messages or via other communication paths, if needed to meet timeliness requirements.
最初，存储库系统将是传播ROA的主要机制，因为这些存储库将持有验证ROA所需的证书和CRL。此外，如果需要满足及时性要求，还可以在BGP更新消息中或通过其他通信路径分发ROA。
A ROA constitutes an explicit authorization for a single AS to originate routes to one or more prefixes, and is signed by the holder of those prefixes. Conceptually, the ROA syntax consists of two parts, a general CMS template common to all RPKI signed objects
ROA构成对单个AS发起路由到一个或多个前缀的明确授权，并由这些前缀的持有者签名。从概念上讲，ROA语法由两部分组成，即所有RPKI签名对象通用的通用CMS模板
[RFC6488] and an encapsulated content specific to the ROA that expresses the authorization [RFC6482].
[RFC6488]和表示授权的特定于ROA的封装内容[RFC6482]。
At a high level, the ROA's content contains (1) an AS number; (2) a list of IP address prefixes; and, optionally, (3) for each prefix, the maximum length of more specific (longer) prefixes that the AS is also authorized to advertise. (This last element facilitates a compact authorization to advertise, for example, any prefixes of length 20 to 24 bits contained within a given length 20 prefix.)
在高层次上，居留权的内容包括（1）一个AS编号；（2） IP地址前缀列表；并且，可选地，（3）对于每个前缀，AS也被授权发布的更具体（更长）前缀的最大长度。（最后一个元素有助于压缩授权，例如，公布给定长度20前缀中包含的任何长度为20到24位的前缀。）
Note that a ROA contains only a single AS number. Thus, if an ISP has multiple AS numbers that will be authorized to originate routes to the prefix(es) in the ROA, an address space holder will need to issue multiple ROAs to authorize the ISP to originate routes from any of these ASes.
请注意，ROA仅包含一个AS编号。因此，如果ISP有多个AS号码，这些号码将被授权发起到ROA中前缀的路由，则地址空间持有者将需要发出多个ROA，以授权ISP从这些ASE中的任何一个发起路由。
A ROA is signed using the private key corresponding to the public key in an end-entity (EE) certificate in the PKI. In order for a ROA to be valid, its corresponding end-entity certificate must be valid, and the IP address prefixes of the ROA must exactly match the IP address prefix(es) specified in the EE certificate's RFC 3779 extension. Therefore, the validity interval of the ROA is implicitly the validity interval of its corresponding certificate. A ROA is revoked by revoking the corresponding EE certificate. There is no independent method of revoking a ROA. One might worry that this revocation model could lead to long CRLs for the CA certification that is signing the EE certificates. However, routing announcements on the public Internet are generally quite long lived. Therefore, as long as the EE certificates used to verify a ROA are given a validity interval of several months, the likelihood that many ROAs would need to be revoked within that time is quite low.
使用与PKI中的最终实体（EE）证书中的公钥相对应的私钥对ROA进行签名。为了使ROA有效，其相应的终端实体证书必须有效，并且ROA的IP地址前缀必须与EE证书的RFC 3779扩展中指定的IP地址前缀完全匹配。因此，ROA的有效期间隔隐含地是其相应证书的有效期间隔。通过撤销相应的EE证书来撤销ROA。没有独立的方法撤销居留权。有人可能担心，这种撤销模型可能会导致签署EE证书的CA证书的CRL过长。然而，公共互联网上的路由公告通常是相当长的。因此，只要用于核实居留权的EE证书的有效期为几个月，许多居留权需要在这段时间内撤销的可能性就很低。
--------- ---------
| RIR | | NIR |
| CA | | CA |
--------- ---------
| |
| |
| |
--------- ---------
| ISP | | ISP |
| CA 1 | | CA 2 |
--------- ---------
| \ |
| ----- |
| \ |
---------- ---------- ----------
| ISP | | ISP | | ISP |
| EE 1a | | EE 1b | | EE 2 |
---------- ---------- ----------
| | |
| | |
| | |
---------- ---------- ----------
| ROA 1a | | ROA 1b | | ROA 2 |
---------- ---------- ----------
--------- ---------
| RIR | | NIR |
| CA | | CA |
--------- ---------
| |
| |
| |
--------- ---------
| ISP | | ISP |
| CA 1 | | CA 2 |
--------- ---------
| \ |
| ----- |
| \ |
---------- ---------- ----------
| ISP | | ISP | | ISP |
| EE 1a | | EE 1b | | EE 2 |
---------- ---------- ----------
| | |
| | |
| | |
---------- ---------- ----------
| ROA 1a | | ROA 1b | | ROA 2 |
---------- ---------- ----------
Figure 1: This figure illustrates an ISP with allocations from two sources (an RIR and an NIR). It needs two CA certificates due to the rules defined in RFC 3779.
图1：该图显示了一个ISP，其分配来自两个来源（RIR和NIR）。由于RFC 3779中定义的规则，它需要两个CA证书。
Because each ROA is associated with a single end-entity certificate, the set of IP prefixes contained in a ROA must be drawn from an allocation by a single source, i.e., a ROA cannot combine allocations from multiple sources. Address space holders who have allocations from multiple sources, and who wish to authorize an AS to originate routes for these allocations, must issue multiple ROAs to the AS.
由于每个ROA都与单个终端实体证书相关联，因此ROA中包含的IP前缀集必须从单个源的分配中提取，即ROA不能组合来自多个源的分配。拥有来自多个来源的分配的地址空间持有人，以及希望授权AS为这些分配发起路由的地址空间持有人，必须向AS颁发多个ROA。
Initially, an LIR/ISP will make use of the resource PKI by acquiring and validating every ROA, to create a table of the prefixes for which each AS is authorized to originate routes. To validate all ROAs, an LIR/ISP needs to acquire all the certificates and CRLs. The primary function of the distributed repository system described here is to store these signed objects and to make them available for download by LIRs/ISPs. Note that this repository system provides a mechanism by which relying parties can pull fresh data at whatever frequency they deem appropriate. However, it does not provide a mechanism for pushing fresh data to relying parties (e.g., by including resource
最初，LIR/ISP将通过获取和验证每个ROA来利用资源PKI，以创建一个前缀表，每个AS都有权发起路由。要验证所有ROA，LIR/ISP需要获取所有证书和CRL。这里描述的分布式存储库系统的主要功能是存储这些签名对象，并使它们可供LIRs/ISP下载。请注意，此存储库系统提供了一种机制，依赖方可以通过该机制以其认为合适的任何频率提取新数据。但是，它没有提供将新数据推送到依赖方的机制（例如，通过包含资源）
PKI objects in BGP or other protocol messages) and such a mechanism is beyond the scope of the current document.
PKI对象（在BGP或其他协议消息中），并且这种机制超出了当前文档的范围。
The digital signatures on all objects in the repository ensure that unauthorized modification of valid objects is detectable by relying parties. Additionally, the repository system uses manifests (see Section 5) to ensure that relying parties can detect the deletion of valid objects and the insertion of out-of-date, valid signed objects.
存储库中所有对象上的数字签名确保依赖方可以检测到对有效对象的未经授权的修改。此外，存储库系统使用清单（见第5节）来确保依赖方能够检测到有效对象的删除和过期有效签名对象的插入。
The repository system is also a point of enforcement for access controls for the signed objects stored in it, e.g., ensuring that records related to an allocation of resources can be manipulated only by authorized parties. The use of access controls prevents denial-of-service attacks based on deletion of or tampering with repository objects. Indeed, although relying parties can detect tampering with objects in the repository, it is preferable that the repository system prevent such unauthorized modifications to the greatest extent possible.
存储库系统也是对存储在其中的签名对象进行访问控制的实施点，例如，确保与资源分配相关的记录只能由授权方操作。使用访问控制可防止基于删除或篡改存储库对象的拒绝服务攻击。事实上，尽管依赖方可以检测到对存储库中对象的篡改，但存储库系统最好尽可能防止此类未经授权的修改。
The repository system is the untrusted clearing-house for all signed objects that must be globally accessible to relying parties. When certificates and CRLs are created, they are uploaded to this repository, and then downloaded for use by relying parties (primarily LIRs/ISPs). ROAs and manifests are additional examples of such objects, but other types of signed objects may be added to this architecture in the future. This document briefly describes the way signed objects (certificates, CRLs, ROAs, and manifests) are managed in the repository system. As other types of signed objects are added to the repository system, it will be necessary to modify the description, but it is anticipated that most of the design principles will still apply. The repository system is described in detail in [RFC6481].
存储库系统是所有已签名对象的不受信任的清算所，依赖方必须全局访问这些对象。创建证书和CRL时，它们将上载到此存储库，然后下载供依赖方（主要是LIR/ISP）使用。ROA和清单是此类对象的附加示例，但将来可能会将其他类型的签名对象添加到此体系结构中。本文档简要描述了在存储库系统中管理已签名对象（证书、CRL、ROA和清单）的方式。随着其他类型的签名对象添加到存储库系统中，有必要修改描述，但预计大多数设计原则仍将适用。[RFC6481]中详细描述了存储库系统。
Although there is a single repository system that is accessed by relying parties, it is comprised of multiple databases. These databases will be distributed among registries (RIRs, NIRs, LIRs/ISPs). At a minimum, the database operated by each registry will contain all CA and EE certificates, CRLs, and manifests signed by the CA(s) associated with that registry. Repositories operated by LIRs/ISPs also will contain ROAs. Registries are encouraged to maintain copies of repository data from their customers, and their customer's customers (etc.), to facilitate retrieval of the whole repository contents by relying parties. Ideally, each RIR will hold PKI data from all entities within its geopolitical scope.
尽管依赖方可以访问单个存储库系统，但它由多个数据库组成。这些数据库将分布在各登记处（RIR、NIR、LIR/ISP）。每个注册表操作的数据库至少将包含所有CA和EE证书、CRL以及由与该注册表相关联的CA签署的清单。LIRs/ISP运营的存储库也将包含ROA。鼓励登记处保存其客户及其客户的客户（等）提供的存储库数据副本，以便于依赖方检索整个存储库内容。理想情况下，每个RIR将保存其地缘政治范围内所有实体的PKI数据。
For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs, and manifests) verifiable via this certificate. A certificate's Subject Information Access (SIA) extension [RFC5280] contains a URI that references this directory. Additionally, a certificate's Authority Information Access (AIA) extension [RFC5280] contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued. That is, if certificate A is used to verify certificate B, then the AIA extension of certificate B points to certificate A, and the SIA extension of certificate A points to a directory containing certificate B (see Figure 2).
对于PKI中的每个证书，存储库中将有一个相应的文件系统目录，该目录是可通过此证书验证的所有对象（证书、CRL、ROA和清单）的权威发布点。证书的主题信息访问（SIA）扩展[RFC5280]包含引用此目录的URI。此外，证书的授权信息访问（AIA）扩展[RFC5280]包含一个URI，该URI引用颁发给定证书的CA证书的授权位置。也就是说，如果证书A用于验证证书B，那么证书B的AIA扩展指向证书A，证书A的SIA扩展指向包含证书B的目录（见图2）。
+--------+
+--------->| Cert A |<----+
| | CRLDP | |
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP ----+ | | CRLDP -+-+ |
+----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | |
| +--------+ | +--------+ | |
| V | |
| +---------+ | |
| | A's CRL |<-----------+ |
| +---------+ |
| A's Repository Publication Directory |
+--------------------------------------+
+--------+
+--------->| Cert A |<----+
| | CRLDP | |
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP ----+ | | CRLDP -+-+ |
+----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | |
| +--------+ | +--------+ | |
| V | |
| +---------+ | |
| | A's CRL |<-----------+ |
| +---------+ |
| A's Repository Publication Directory |
+--------------------------------------+
Figure 2: Use of SIA and AIA extensions in the RPKI
图2:RPKI中SIA和AIA扩展的使用
In Figure 2, certificates B and C are issued by CA A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A.
在图2中，证书B和C由CA A颁发。因此，证书B和C的AIA扩展指向（证书）A，证书A的SIA扩展指向CA A下属产品的存储库发布点，其中包括证书B和C，以及A颁发的CRL。CRL分发点证书B和C中的（CRLDP）扩展都指向A颁发的CRL。
If a CA certificate is reissued with the same public key, it should not be necessary to reissue (with an updated AIA URI) all certificates signed by the certificate being reissued. Therefore, a certification authority SHOULD use a persistent URI naming scheme for issued certificates. That is, reissued certificates should use the same publication point as previously issued certificates having the same subject and public key, and should overwrite such certificates.
如果CA证书使用相同的公钥重新颁发，则不必重新颁发（使用更新的AIA URI）由重新颁发的证书签名的所有证书。因此，证书颁发机构应该为已颁发的证书使用持久URI命名方案。也就是说，重新颁发的证书应使用与先前颁发的具有相同主题和公钥的证书相同的发布点，并应覆盖此类证书。
Repository operators will choose one or more access protocols that relying parties can use to access the repository system. These protocols will be used by numerous participants in the infrastructure (e.g., all registries, ISPs, and multi-homed subscribers) to maintain their respective portions of it. In order to support these activities, certain basic functionality is required of the suite of access protocols, as described below. No single access protocol needs to implement all of these functions (although that may be the case), but each function MUST be implemented by at least one access protocol deployed by a repository operator.
存储库操作员将选择依赖方可用于访问存储库系统的一个或多个访问协议。这些协议将被基础设施中的众多参与者（例如，所有注册中心、ISP和多址用户）用于维护其各自的部分。为了支持这些活动，访问协议套件需要某些基本功能，如下所述。没有一个访问协议需要实现所有这些功能（尽管可能是这样），但每个功能必须由存储库操作员部署的至少一个访问协议来实现。
Download: Access protocols must support the bulk download of repository contents and subsequent download of changes to the downloaded contents, since this will be the most common way in which relying parties interact with the repository system. Other types of download interactions (e.g., download of a single object) may also be supported.
下载：访问协议必须支持存储库内容的批量下载和下载内容更改的后续下载，因为这将是依赖方与存储库系统交互的最常见方式。还可以支持其他类型的下载交互（例如，下载单个对象）。
Upload/change/delete: Access protocols must also support mechanisms for the issuers of certificates, CRLs, and other signed objects to add them to the repository, and to remove them. Mechanisms for modifying objects in the repository may also be provided. All access protocols that allow modification to the repository (through addition, deletion, or modification of its contents) must support verification of the authorization of the entity performing the modification, so that appropriate access controls can be applied (see Section 4.4).
上载/更改/删除：访问协议还必须支持证书、CRL和其他已签名对象的颁发者将其添加到存储库并将其删除的机制。还可以提供用于修改存储库中对象的机制。允许修改存储库（通过添加、删除或修改其内容）的所有访问协议必须支持验证执行修改的实体的授权，以便可以应用适当的访问控制（参见第4.4节）。
To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via rsync (see [RFC5781] and [RSYNC]), although other download protocols MAY also be supported. A repository publication point may provide update/change/delete functionality via (set of) access protocols that it desires, provided that the supported protocols are clearly communicated to all certification authorities publishing data at a given publication point.
为确保所有依赖方能够获取所有RPKI签名对象，所有发布点都必须可以通过rsync访问（请参见[RFC5781]和[rsync]），尽管也可能支持其他下载协议。存储库发布点可通过其所需的（一组）访问协议提供更新/更改/删除功能，前提是支持的协议明确传达给在给定发布点发布数据的所有认证机构。
In order to maintain the integrity of information in the repository, controls must be put in place to prevent the addition, deletion, or modification of objects in the repository by unauthorized parties. The identities of parties attempting to make such changes can be authenticated through the relevant access protocols. Although specific access control policies are subject to the local control of repository operators, it is RECOMMENDED that repositories allow only the issuers of signed objects to add, delete, or modify them. Alternatively, it may be advantageous in the future to define a formal delegation mechanism to allow resource holders to authorize other parties to act on their behalf, as suggested in Section 2.3.
为了保持存储库中信息的完整性，必须实施控制措施，以防止未经授权的各方添加、删除或修改存储库中的对象。尝试进行此类更改的各方的身份可以通过相关访问协议进行身份验证。尽管特定的访问控制策略受存储库操作员的本地控制，但建议存储库只允许已签名对象的颁发者添加、删除或修改这些策略。或者，如第2.3节所建议的那样，今后可能有利于定义一个正式的授权机制，允许资源持有者授权其他各方代表其行事。
A manifest is a signed object listing of all of the signed objects (except for the manifest itself) issued by an authority responsible for a publication in the repository system. For each unexpired certificate, CRL, or ROA issued by the authority, the manifest contains both the name of the file containing the object, and a hash of the file content.
清单是由负责存储库系统中发布的机构发布的所有已签名对象（清单本身除外）的已签名对象列表。对于管理局颁发的每个未过期的证书、CRL或ROA，清单包含包含对象的文件名和文件内容的哈希。
As with ROAs, a manifest is signed by a private key, for which the corresponding public key appears in an end-entity certificate. This EE certificate, in turn, is signed by the CA in question. Since the private key in an EE certificate is used to sign only a single manifest, then the manifest can be revoked by revoking the EE certificate. In such a case, to avoid needless CRL growth, the EE certificate used to validate a manifest SHOULD expire at the same time that the manifest expires.
与ROA一样，清单由私钥签名，相应的公钥出现在最终实体证书中。该EE证书由相关CA签署。由于EE证书中的私钥仅用于对单个清单进行签名，因此可以通过撤销EE证书来撤销清单。在这种情况下，为了避免不必要的CRL增长，用于验证清单的EE证书应该在清单过期的同时过期。
Manifests may be used by relying parties when constructing a local cache (see Section 6) to mitigate the risk of an attacker who deletes files from a repository or replaces current signed objects with stale versions of the same object. Such protection is needed because, although all objects in the repository system are signed, the repository system itself is untrusted.
依赖方可在构建本地缓存时使用清单（请参见第6节），以降低攻击者从存储库中删除文件或用同一对象的过时版本替换当前已签名对象的风险。需要这样的保护是因为，尽管存储库系统中的所有对象都已签名，但存储库系统本身不受信任。
A manifest constitutes a list of (the hashes of) all the files in a repository point at a particular point in time. A detailed specification of the manifest's content is provided in [RFC6486] but, at a high level, a manifest consists of (1) a manifest number; (2) the time the manifest was issued; (3) the time of the next planned update; and (4) a list of filename and hash value pairs.
清单构成存储库中某个特定时间点的所有文件（哈希）的列表。[RFC6486]中提供了清单内容的详细说明，但在较高级别上，清单由（1）清单编号组成；（2） 舱单签发的时间；（3） 下一次计划更新的时间；和（4）文件名和散列值对的列表。
The manifest number is a sequence number that is incremented each time a manifest is issued by the authority. An authority is REQUIRED to issue a new manifest any time it alters any of its items in the repository, or when the specified time of the next update is reached. A manifest is thus valid until the specified time of the next update or until a manifest is issued with a greater manifest number, whichever comes first. (Note that when an EE certificate is used to sign only a single manifest, whenever the authority issues the new manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest. The revoked EE certificate for the old manifest will be removed from the CRL when it expires; thus, this procedure ought not to result in significant CRL growth.)
清单编号是一个序列号，每当管理局发布清单时，该序列号都会递增。授权机构在更改存储库中的任何项时，或在达到下一次更新的指定时间时，都需要发布新的清单。因此，在下一次更新的指定时间之前，或者在向清单发出更大的清单编号之前（以先到者为准），清单是有效的。（请注意，当EE证书仅用于签署单个舱单时，每当管理局发布新舱单时，CA还必须发布新CRL，其中包括与旧舱单对应的EE证书。旧舱单的已吊销EE证书将在到期时从CRL中删除；因此，此过程不应o导致CRL显著增长。）
In order to utilize signed objects issued under this PKI, a relying party must first obtain a local copy of the valid EE certificates for the PKI. To do so, the relying party performs the following steps:
为了利用在此PKI下颁发的签名对象，依赖方必须首先获得该PKI的有效EE证书的本地副本。为此，依赖方执行以下步骤：
1. Query the repository system to obtain a copy of all certificates, manifests, and CRLs issued under the PKI.
1. 查询存储库系统以获取根据PKI颁发的所有证书、清单和CRL的副本。
2. For each CA certificate in the PKI, verify the signature on the corresponding manifest. Additionally, verify that the current time is earlier than the time indicated in the nextUpdate field of the manifest.
2. 对于PKI中的每个CA证书，请验证相应清单上的签名。此外，请验证当前时间是否早于清单的nextUpdate字段中指示的时间。
3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted.
3. 对于每个清单，验证在相应CA证书下颁发的证书和CRL是否与清单中包含的哈希值匹配。此外，请验证存储库中没有缺少清单上列出的证书或清单。如果哈希值不匹配，或者缺少任何证书或CRL，请通知相应的存储库管理员存储库数据已损坏。
4. Validate each EE certificate by constructing and verifying a certification path for the certificate (including checking relevant CRLs) to the locally configured set of TAs. (See [RFC6487] for more details.)
4. 通过构造和验证证书到本地配置的TA集的证书路径（包括检查相关CRL），验证每个EE证书。（有关更多详细信息，请参阅[RFC6487]）
Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache.
请注意，由于依赖方将定期执行这些操作，因此依赖方只向存储库系统请求自依赖方上次更新其本地缓存以来已更改的对象更为有效。
Note also that by checking all issued objects against the appropriate manifest, the relying party can be certain that it is not missing an updated version of any object.
还请注意，通过对照适当的清单检查所有已发布的对象，依赖方可以确定它没有丢失任何对象的更新版本。
Creating and maintaining the infrastructure described above will entail additional operations as "side effects" of normal resource allocation and routing authorization procedures. For example, a subscriber with provider-independent ("portable") address space who enters a relationship with an ISP will need to issue one or more ROAs identifying that ISP, in addition to conducting any other necessary technical or business procedures. The current primary use of this infrastructure is for route filter construction; using ROAs, route filters can be constructed in an automated fashion with high assurance that the holder of the advertised prefix has authorized the origin AS to originate an advertised route.
创建和维护上述基础设施将需要额外的操作，作为正常资源分配和路由授权程序的“副作用”。例如，拥有独立于提供商（“便携”）地址空间的用户与ISP建立关系时，除了执行任何其他必要的技术或业务程序外，还需要发出一个或多个识别该ISP的ROA。目前，该基础设施的主要用途是建造路由过滤器；使用roa，可以以自动化的方式构造路由过滤器，并且高度保证广告前缀的持有者已经授权源站发起广告路由。
There are several operational scenarios that require certificates to be issued. Any allocation that may be sub-allocated requires a CA certificate, e.g., so that certificates can be issued as necessary for the sub-allocations. Holders of provider-independent IP address space allocations also must have certificates, so that a ROA can be issued to each ISP that is authorized to originate a route to the allocation (since the allocation does not come from any ISP). Additionally, multi-homed subscribers may require certificates for their allocations if they intend to issue the ROAs for their allocations (see Section 7.3.2). Other resource holders need not be issued CA certificates within the PKI.
有几个操作场景需要颁发证书。任何可能被子分配的分配都需要CA证书，例如，这样就可以根据需要为子分配颁发证书。独立于提供商的IP地址空间分配的持有者还必须拥有证书，以便可以向授权发起分配路由的每个ISP颁发ROA（因为分配不是来自任何ISP）。此外，如果多宿用户打算为其分配颁发ROA，则其分配可能需要证书（见第7.3.2节）。其他资源持有者不需要在PKI中获得CA证书。
In the long run, a resource holder will not request resource certificates, but rather receive a certificate as a side effect of the allocation process for the resource. However, initial deployment of the RPKI will entail issuance of certificates to existing resource holders as an explicit event. Note that in all cases, the authority issuing a CA certificate will be the entity who allocates resources to the subject. This differs from most PKIs in which a subject can request a certificate from any certification authority.
从长远来看，资源持有者不会请求资源证书，而是作为资源分配过程的副作用接收证书。然而，RPKI的初步部署将需要向现有资源持有者颁发证书，这是一项明确的活动。请注意，在所有情况下，颁发CA证书的机构都是向主体分配资源的实体。这与大多数PKI不同，在PKI中，主体可以向任何证书颁发机构申请证书。
If a resource holder receives multiple allocations over time, it may accrue a collection of resource certificates to attest to them. If a resource holder receives multiple allocations from the same source, the set of resource certificates may be combined into a single resource certificate, if both the issuer and the resource holder agree. This is accomplished by consolidating the IP Address Delegation and AS Identifier Delegation extensions into a single
如果一个资源持有者在一段时间内收到多个分配，它可能会累积一组资源证书来证明它们。如果资源持有者从同一来源收到多个分配，则如果颁发者和资源持有者都同意，则可以将资源证书集合并为单个资源证书。这是通过将IP地址委派和AS标识符委派扩展整合到单个
extension (of each type) in a new certificate. However, if these certificates attest to allocations that are valid for different periods of time, creating a certificate that combines them might create problems, as the combined certificate can express only a single validity interval.
新证书中的扩展（每种类型）。但是，如果这些证书证明分配在不同的时间段内有效，那么创建一个将它们组合在一起的证书可能会产生问题，因为组合的证书只能表示一个有效期间隔。
If a resource holder's allocations come from different sources, they will be signed by different CAs and cannot be combined. When a set of resources is no longer allocated to a resource holder, any certificates attesting to such an allocation MUST be revoked. A resource holder SHOULD NOT use the same public key in multiple CA certificates that are issued by the same or differing authorities, as reuse of a key pair complicates path construction. Note that since the subject's distinguished name is chosen by the issuer, a subject who receives allocations from two sources generally will receive certificates with different subject names.
如果资源持有者的分配来自不同的来源，则它们将由不同的CA签名，并且不能合并。当一组资源不再分配给资源持有者时，必须撤销证明此类分配的任何证书。资源持有者不应在由相同或不同机构颁发的多个CA证书中使用相同的公钥，因为密钥对的重用会使路径构造复杂化。请注意，由于主体的专有名称由发行人选择，因此从两个来源接收分配的主体通常会收到具有不同主体名称的证书。
Whenever a certification authority wishes to change the public key (and corresponding private key) associated with its RPKI CA certificate, it MUST perform a key rollover procedure. Key rollover is typically performed on a periodic basis, where the frequency of key rollovers is specified in the certification practice statement of the given CA. Additionally, unscheduled rollovers may be required in the event of suspected key compromises.
每当证书颁发机构希望更改与其RPKI CA证书关联的公钥（以及相应的私钥）时，它必须执行密钥翻转过程。钥匙翻车通常是定期进行的，其中在给定CA的认证实践声明中规定了钥匙翻车的频率。此外，如果怀疑钥匙泄漏，可能需要进行非计划翻车。
Note that rollover is only required when the CA's key actually changes; it is not required in cases where a new CA certificate is issued with the same key as the previous certificate for this CA. For example, a new CA certificate must be issued if the CA gains or relinquishes a resource, or if the validity period of the resource allocation is extended. However, in such cases, the new certificate will generally use the same public (and private) key as the previous certificate; thus, key rollover is not required.
请注意，仅当CA的密钥实际发生更改时才需要翻转；如果颁发的新CA证书的密钥与此CA的上一个证书的密钥相同，则不需要该证书。例如，如果CA获得或放弃资源，或者如果资源分配的有效期延长，则必须颁发新CA证书。但是，在这种情况下，新证书通常将使用与以前证书相同的公钥（和私钥）；因此，不需要键翻转。
The document [RFC6489] specifies a conservative key rollover procedure that should be used by a certification authority when it changes the public (and private) keys associated with its RPKI CA certificate. At a high level, the two key properties of the rollover procedure are as follows. First, as data from RPKI signed objects may be used in routing operations, the procedure ensures that at any point in the rollover procedure, a relying party will never reach incorrect conclusions about the validity of a signed object. Note in particular, that the CA cannot assume that a relying party will use any particular algorithm for constructing a certificate path from an EE certificate to (one of) the relying party's trust anchor(s); therefore, the key rollover procedure is designed to preserve the
文档[RFC6489]指定了一个保守的密钥滚动过程，证书颁发机构在更改与其RPKI CA证书关联的公钥（和私钥）时应使用该过程。在较高级别上，滚动过程的两个关键属性如下所示。首先，由于来自RPKI签名对象的数据可用于路由操作，该过程确保在滚动过程的任何时候，依赖方都不会对签名对象的有效性得出错误结论。特别注意，CA不能假设依赖方将使用任何特定算法来构造从EE证书到（其中一个）依赖方信任锚的证书路径；因此，钥匙翻转程序旨在保持
integrity of the SIA and AIA points within the RPKI hierarchy to the greatest extent possible. Second, the key rollover procedure is designed so that the reissuance of all certificates below the CA in the RPKI hierarchy is not required. Of course, it is necessary to re-sign all certificates issued directly under the CA whose key is changing. However, the SIA and AIA pointers within the certificates are populated so that no further reissuance is required.
尽可能保持RPKI层级中SIA和AIA点的完整性。其次，密钥翻转过程的设计不需要重新颁发RPKI层次结构中CA之下的所有证书。当然，有必要重新签署直接在CA下颁发的、其密钥正在更改的所有证书。但是，证书中的SIA和AIA指针已填充，因此无需进一步重新颁发。
Whenever a holder of IP address space wants to authorize an AS to originate routes for a prefix within his holdings, he MUST issue an end-entity certificate containing that prefix in an IP Address Delegation extension. He then uses the corresponding private key to sign a ROA containing the designated prefix and the AS number for the AS. The resource holder MAY include more than one prefix in the EE certificate and corresponding ROA if desired. As a prerequisite, then, any address space holder that issues ROAs for a prefix must have a resource certificate for an allocation containing that prefix. The standard procedure for issuing a ROA is as follows:
每当IP地址空间的持有人想要授权AS为其持有的前缀发起路由时，他必须在IP地址委派扩展中颁发包含该前缀的终端实体证书。然后，他使用相应的私钥签署包含指定前缀和AS编号的ROA。如果需要，资源持有者可以在EE证书和相应的ROA中包括多个前缀。因此，作为一个先决条件，任何为前缀颁发ROA的地址空间持有者必须拥有包含该前缀的分配的资源证书。签发居留权的标准程序如下：
1. Create an end-entity certificate containing the prefix(es) to be authorized in the ROA.
1. 创建包含要在ROA中授权的前缀的最终实体证书。
2. Construct the payload of the ROA, including the prefixes in the end-entity certificate and the AS number to be authorized.
2. 构造ROA的有效负载，包括终端实体证书中的前缀和要授权的AS编号。
3. Sign the ROA using the private key corresponding to the end-entity certificate (the ROA is comprised of the payload encapsulated in a CMS signed message [RFC5652]).
3. 使用与终端实体证书对应的私钥对ROA进行签名（ROA由封装在CMS签名消息[RFC5652]中的有效负载组成）。
4. Upload the end-entity certificate and the ROA to the repository system.
4. 将最终实体证书和ROA上载到存储库系统。
The standard procedure for revoking a ROA is to revoke the corresponding end-entity certificate by creating an appropriate CRL and uploading it to the repository system. The revoked ROA and end-entity certificate SHOULD be removed from the repository system.
撤销ROA的标准过程是通过创建适当的CRL并将其上载到存储库系统来撤销相应的最终实体证书。应从存储库系统中删除已吊销的ROA和最终实体证书。
Care must be taken when revoking ROAs in that revoking a ROA may cause a relying party to treat routing advertisements corresponding to the prefixes and origin AS number in the ROA as unauthorized (and potentially even change routing behavior to no longer forward packets based on those advertisements). In particular, resource holders should adhere to the principle of "make before break" as follows. Before revoking a ROA corresponding to a prefix that the resource holder wishes to be routable on the Internet, it is very important for the resource holder to ensure that there exists another valid
在撤销ROA时必须小心，因为撤销ROA可能会导致依赖方将与前缀和来源相对应的路由广告视为ROA中的数字，视为未经授权（甚至可能更改路由行为，不再基于这些广告转发数据包）。特别是，资源持有者应遵循以下“先创造后破坏”的原则。在撤销与资源持有者希望在Internet上可路由的前缀相对应的ROA之前，资源持有者必须确保存在另一个有效的前缀
alternative ROA that lists the same prefix (possibly indicating a different AS number). Additionally, the resource holder should ensure that the AS indicated in the valid alternative ROA is actually originating routing advertisements to the prefixes in question. Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation.
列出相同前缀的可选ROA（可能表示不同的AS编号）。此外，资源持有者应确保有效备选ROA中指示的路由实际上是针对所讨论的前缀发起路由播发。此外，依赖方必须在采取任何路由操作响应ROA撤销之前从存储库系统获取新的ROA。
In BGP, a single-homed subscriber with Provider Aggregatable (PA) address space does not need to explicitly authorize routes to be originated for the prefix(es) it is using, since its ISP will already advertise a more general prefix and route traffic for the subscriber's prefix as an internal function. Since no routes are originated specifically for prefixes held by these subscribers, no ROAs need to be issued under their allocations; rather, the subscriber's ISP will issue any necessary ROAs for its more general prefixes under resource certificates from its own allocation. Thus, a single-homed subscriber with an IP address allocation from his service provider is not included in the RPKI, i.e., it does not receive a CA certificate, nor issue EE certificates or ROAs.
在BGP中，具有提供商可聚合（PA）地址空间的单宿订户不需要明确授权为其使用的前缀发起路由，因为其ISP已经将为订户的前缀播发更通用的前缀和路由流量作为内部功能。由于没有专门为这些订户持有的前缀发起路由，因此不需要在其分配下颁发ROA；相反，订户的ISP将从其自身分配的资源证书下为其更通用的前缀颁发任何必要的ROA。因此，具有来自其服务提供商的IP地址分配的单个归属订户不包括在RPKI中，即，它不接收CA证书，也不颁发EE证书或roa。
Here we consider a subscriber who receives Provider Aggregatable (PA) IP address space from a primary ISP (i.e., the IP addresses used by the subscriber are a subset of ISP A's IP address space allocation) and receives redundant upstream connectivity from one or more secondary ISPs, in addition to the primary ISP. The preferred option for such a multi-homed subscriber is for the subscriber to obtain an AS number and run BGP with each of its upstream providers. In such a case, there are two RECOMMENDED ways for ROA management to be handled. The first is that the primary ISP issues a CA certificate to the subscriber, and the subscriber issues a ROA to containing the subscriber's AS number and the subscriber's IP address prefixes. The second possibility is that the primary ISP does not issue a CA certificate to the subscriber, and instead issues a ROA on the subscriber's behalf that contains the subscriber's AS number and the subscriber's IP address prefixes.
在这里，我们考虑从主ISP接收提供商聚合（PA）IP地址空间的用户（即，用户使用的IP地址是ISP A的IP地址空间分配的子集），并且除了主ISP之外，从一个或多个次级ISP接收冗余的上行连接。这种多宿用户的首选选项是，用户获得AS号码并与其每个上游提供商一起运行BGP。在这种情况下，建议采用两种方式处理居留权管理。第一种是主ISP向订户颁发CA证书，订户颁发包含订户AS号码和订户IP地址前缀的ROA。第二种可能性是，主ISP不向订户颁发CA证书，而是代表订户颁发包含订户AS号码和订户IP地址前缀的ROA。
If the subscriber is unable or unwilling to obtain an AS number and run BGP, the another option is that the multi-homed subscriber can request that the primary ISP create a ROA for each secondary ISP that authorizes the secondary ISP to originate routes to the subscriber's prefixes. The primary ISP will also create a ROA containing its own AS number and the subscriber's prefixes, as it is likely in such a case that the primary ISP wishes to advertise precisely the
如果用户无法或不愿意获得AS号码并运行BGP，另一个选项是多宿用户可以请求主ISP为每个辅助ISP创建ROA，授权辅助ISP发起到用户前缀的路由。主ISP还将创建一个ROA，其中包含其自己的AS号码和订户的前缀，因为在这种情况下，主ISP很可能希望准确地宣传该用户
subscriber's prefixes and not an encompassing aggregate. Note that this approach results in inconsistent origin AS numbers for the subscriber's prefixes that are considered undesirable on the public Internet; thus, this approach is NOT RECOMMENDED.
订阅者的前缀，而不是包含的聚合。注意，这种方法会导致用户前缀的来源不一致，这在公共互联网上是不受欢迎的；因此，不建议采用这种方法。
A resource holder is said to have provider-independent (portable) address space if the resource holder received its allocation directly from a RIR or NIR. Because the prefixes represented in such allocations are not taken from an allocation held by an ISP, there is no ISP that holds and advertises a more general prefix. A holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes. Thus, the resource holder MUST generate one or more EE certificates and associated ROAs to enable the AS(es) to originate routes for the prefix(es) in question. This ROA is required because none of the ISP's existing ROAs authorize it to originate routes to the subscriber's provider-independent allocation.
如果资源持有者直接从RIR或NIR接收其分配，则资源持有者被称为具有独立于提供者（可移植）的地址空间。由于此类分配中表示的前缀不是从ISP持有的分配中获取的，因此没有ISP持有并播发更通用的前缀。便携式IP地址空间分配的持有者必须授权一个或多个ASE发起到这些前缀的路由。因此，资源持有者必须生成一个或多个EE证书和相关联的roa，以使AS（es）能够为所讨论的前缀发起路由。此ROA是必需的，因为ISP的现有ROA均未授权其发起到订户的独立于提供商的分配的路由。
The focus of this document is security; hence, security considerations permeate this specification.
本文件的重点是安全；因此，安全考虑贯穿于本规范中。
The security mechanisms provided by and enabled by this architecture depend on the integrity and availability of the infrastructure it describes. The integrity of objects within the infrastructure is ensured by appropriate controls on the repository system, as described in Section 4.4. Likewise, because the repository system is structured as a distributed database, it should be inherently resistant to denial-of-service attacks; nonetheless, appropriate precautions should also be taken, both through replication and backup of the constituent databases and through the physical security of database servers.
此体系结构提供和启用的安全机制取决于它所描述的基础结构的完整性和可用性。如第4.4节所述，通过对存储库系统的适当控制来确保基础架构中对象的完整性。同样，由于存储库系统的结构是一个分布式数据库，因此它本身就应该能够抵御拒绝服务攻击；尽管如此，也应采取适当的预防措施，包括复制和备份组成数据库，以及确保数据库服务器的物理安全。
Instructions for IANA's participation in the RPKI are provided in [RFC6491].
[RFC6491]中提供了IANA参与RPKI的说明。
The architecture described in this document is derived from the collective ideas and work of a large group of individuals. This work would not have been possible without the intellectual contributions of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim Christensen and Cathy Murphy of ARIN, Rob Austein of ISC, and Randy Bush of IIJ.
本文档中描述的体系结构来源于大量个人的集体想法和工作。如果没有乔治·迈克尔森（George Michaelson）、罗伯特·卢曼斯（Robert Loomans）、APNIC的桑加亚（Sanjaya）和杰夫·休斯顿（Geoff Huston）、成熟的NCC的罗伯特·基斯特莱基（Robert Kisteleki）和亨克·尤杰特瓦尔尔（Henk Uijterwaal）、ARIN的蒂姆·克里斯滕森（Tim Christensen）和凯西·墨菲（Cathy Murphy）、ISC的罗布·奥斯汀（Ro。
Although we are indebted to everyone who has contributed to this architecture, we would like to especially thank Rob Austein for the concept of a manifest, Geoff Huston for the concept of managing object validity through single-use EE certificate key pairs, and Richard Barnes for help in preparing an early version of this document.
尽管我们要感谢所有对此体系结构做出贡献的人，但我们要特别感谢Rob Austein提出的清单概念，Geoff Huston提出的通过一次性EE证书密钥对管理对象有效性的概念，以及Richard Barnes在准备本文档早期版本时提供的帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[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, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 57812010年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 64812012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的配置文件”，RFC 64822012年2月。
[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", RFC 6486, February 2012.
[RFC6486]Austein，R.，Huston.，G.，Kent，S.，和M.Lepinski，“资源公钥基础设施的清单”，RFC 64862012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", RFC 6488, February 2012.
[RFC6488]Lepinski，M.，Chi，A.，和S.Kent，“资源公钥基础设施的签名对象模板”，RFC 6488，2012年2月。
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012.
[RFC6491]Manderson，T.，Vegoda，L.，和S.Kent，“IANA发布的资源公钥基础设施（RPKI）对象”，RFC 64912012年2月。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483]Huston，G.和G.Michaelson，“使用资源证书公钥基础设施（PKI）和路由起源授权（ROA）验证路由起源”，RFC 6483，2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489]Huston，G.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）中的证书颁发机构（CA）密钥滚动”，BCP 174，RFC 6489，2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490]Huston，G.，Weiler，S.，Michaelson，G.，和S.Kent，“资源公钥基础设施（RPKI）信任锚定位器”，RFC 64902012年2月。
[RSYNC] rsync web pages, <http://rsync.samba.org/>.
[RSYNC]RSYNC网页<http://rsync.samba.org/>.
[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000.
[S-BGP]Kent，S.，Lynn，C.，和Seo，K.，“安全边界网关协议（安全BGP）”，IEEE通信杂志第18卷，第4期，2000年4月。
[soBGP] White, R., "soBGP", May 2005,
<ftp://ftp-eng.cisco.com/sobgp/index.html>
[soBGP] White, R., "soBGP", May 2005,
<ftp://ftp-eng.cisco.com/sobgp/index.html>
Authors' Addresses
作者地址
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138
Matt Lepinski BBN Technologies马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: mlepinski@bbn.com
EMail: mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138
Stephen Kent BBN Technologies马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: kent@bbn.com
EMail: kent@bbn.com