Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6481 R. Loomans
Category: Standards Track G. Michaelson
ISSN: 2070-1721 APNIC
February 2012
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6481 R. Loomans
Category: Standards Track G. Michaelson
ISSN: 2070-1721 APNIC
February 2012
A Profile for Resource Certificate Repository Structure
资源证书存储库结构的配置文件
Abstract
摘要
This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction.
本文档定义了资源公钥基础设施（RPKI）分布式存储库结构的概要文件。每个单独的存储库发布点都是一个目录，其中包含与X.509/PKIX资源证书、证书吊销列表和签名对象相对应的文件。此概要文件定义了对象（文件）命名方案、存储库发布点（目录）的内容以及本地存储库缓存的建议内部结构，旨在促进存储库发布点的分布式集合之间的同步，并促进认证路径的构建。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6481.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6481.
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 ................................................3
2. RPKI Repository Publication Point Content and Structure .........4
2.1. Manifests ..................................................5
2.2. CA Repository Publication Points ...........................6
3. Resource Certificate Publication Repository Considerations ......8
4. Certificate Reissuance and Repositories ........................10
5. Synchronizing Repositories with a Local Cache ..................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................12
7.1. Media Types ...............................................12
7.1.1. application/rpki-manifest ..........................12
7.1.2. application/rpki-roa ...............................13
7.2. RPKI Repository Name Scheme Registry ......................13
8. Acknowledgements ...............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. RPKI Repository Publication Point Content and Structure .........4
2.1. Manifests ..................................................5
2.2. CA Repository Publication Points ...........................6
3. Resource Certificate Publication Repository Considerations ......8
4. Certificate Reissuance and Repositories ........................10
5. Synchronizing Repositories with a Local Cache ..................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................12
7.1. Media Types ...............................................12
7.1.1. application/rpki-manifest ..........................12
7.1.2. application/rpki-roa ...............................13
7.2. RPKI Repository Name Scheme Registry ......................13
8. Acknowledgements ...............................................13
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
To validate attestations made in the context of the Resource Public Key Infrastructure (RPKI) [RFC6480], relying parties (RPs) need access to all the X.509/PKIX Resource Certificates, Certificate Revocation Lists (CRLs), and signed objects that collectively define the RPKI.
为了验证在资源公钥基础设施（RPKI）[RFC6480]上下文中进行的认证，依赖方（RP）需要访问所有X.509/PKIX资源证书、证书吊销列表（CRL）和共同定义RPKI的签名对象。
Each issuer of a certificate, CRL, or a signed object makes it available for download to RPs through the publication of the object in an RPKI repository.
证书、CRL或签名对象的每个颁发者都可以通过在RPKI存储库中发布对象来将其下载到RPs。
The repository system is a collection of all signed objects that MUST be globally accessible to all RPs. When certificates, CRLs and signed objects are created, they are uploaded to a repository publication point, from whence they can be downloaded for use by RPs.
存储库系统是所有已签名对象的集合，所有RP都必须全局访问这些对象。创建证书、CRL和签名对象时，它们将上载到存储库发布点，从该发布点可以下载它们以供RPs使用。
This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction.
此概要文件定义了推荐的对象（文件）命名方案、存储库发布点（目录）的推荐内容，以及本地存储库缓存的建议内部结构，旨在促进存储库发布点的分布式集合之间的同步，并促进认证路径的构建。
A resource certificate attests to a binding of an entity's public key to a set of IP address blocks and AS numbers. The subject of a resource certificate can demonstrate that it is the holder of the resources enumerated in the certificate by using its private key to generate a digital signature (that can be verified using the public key from the certificate).
资源证书证明实体的公钥绑定到一组IP地址块和数字。资源证书的主体可以通过使用其私钥生成数字签名（可以使用证书中的公钥进行验证）来证明其是证书中列举的资源的持有者。
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]中描述的术语和概念。
In addition, the following terms are used in this document:
此外，本文件中使用了以下术语：
Repository Object (or Object): This refers to a terminal object in a repository publication point. A terminal object is conventionally implemented as a file in a publicly accessible directory, where the file is not a directory itself, although another form of object that has an analogous public appearance to a file is encompassed by this term.
存储库对象（或对象）：指存储库发布点中的终端对象。终端对象通常被实现为公共可访问目录中的文件，其中该文件本身不是目录，尽管该术语包含与文件具有类似公共外观的另一种形式的对象。
Repository Publication Point: This refers to a collection of Repository Objects that are published at a common publication point. This is conventionally implemented as a directory in a publicly accessible filesystem that is identified by a URI [RFC3986], although another form of local storage that has an analogous public appearance to a simple directory of files is also encompassed by this term.
存储库发布点：这是指在公共发布点发布的存储库对象的集合。这通常被实现为由URI[RFC3986]标识的可公开访问的文件系统中的目录，尽管该术语还包括另一种具有类似于简单文件目录的公开外观的本地存储形式。
Repository Instance: This refers to a collection of one or more Repository Publication Points that share a common publication instance. This conventionally is implemented as a collection of filesystem directories that share a common URI prefix, where each directory is also identifiable by its own unique URI.
存储库实例：这是指共享公共发布实例的一个或多个存储库发布点的集合。这通常被实现为共享一个公共URI前缀的文件系统目录的集合，其中每个目录也可以通过其自己的唯一URI来识别。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The RPKI does not require that a single repository instance contain all published RPKI objects. Instead, the RPKI repository system is comprised of multiple repository instances. Each individual repository instance is composed of one or more repository publication points. Each repository publication point is used by one or more entities referenced in RPKI certificates, as defined in the certificate's Subject Information Access (SIA) extension.
RPKI不要求单个存储库实例包含所有已发布的RPKI对象。相反，RPKI存储库系统由多个存储库实例组成。每个单独的存储库实例都由一个或多个存储库发布点组成。每个存储库发布点由RPKI证书中引用的一个或多个实体使用，如证书的主题信息访问（SIA）扩展中所定义。
This section describes the collection of objects (RPKI certificates, CRLs, manifests, and signed objects) held in repository publication points.
本节描述存储库发布点中的对象集合（RPKI证书、CRL、清单和签名对象）。
For every Certification Authority (CA) certificate in the RPKI, there is a corresponding repository publication point that is the authoritative publication point for all current certificates and CRLs issued by this CA. The certificate's SIA extension contains a URI [RFC3986] that references this repository publication point and identifies the repository access mechanisms. Additionally, a certificate's Authority Information Access (AIA) extension contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued.
对于RPKI中的每个证书颁发机构（CA）证书，都有一个相应的存储库发布点，该发布点是该CA颁发的所有当前证书和CRL的权威发布点。该证书的SIA扩展包含一个URI[RFC3986]它引用此存储库发布点并标识存储库访问机制。此外，证书的授权信息访问（AIA）扩展包含一个URI，该URI引用颁发给定证书的CA证书的授权位置。
For example, if the subject of certificate A has issued certificates B and C, then the AIA extensions of certificates B and C both point to the publication point for the certificate A object, and the SIA extension of certificate A points to a repository publication point (directory) containing certificates B and C (see Figure 1).
例如，如果证书A的主体发布了证书B和C，那么证书B和C的AIA扩展都指向证书A对象的发布点，证书A的SIA扩展指向包含证书B和C的存储库发布点（目录）（见图1）。
+--------+
+--------->| Cert A |<----+
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP-------+ | | CRLDP-----+ |
+----------- AIA | | +----- AIA | | |
| | SIA------+ | | SIA------------+
| +--------+ | | +--------+ | | |
| | V V | |
| | +-----------------+ | |
| | | CRL issued by A | | |
| A's Repository| +-----------------+ | |
| Directory | | |
+---------------|----------------------+ |
| |
+----------------+ | +----------------+ |
| B's Repository |<-------+ | C's Repository |<--+
| Directory | | Directory |
+----------------+ +----------------+
+--------+
+--------->| Cert A |<----+
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP-------+ | | CRLDP-----+ |
+----------- AIA | | +----- AIA | | |
| | SIA------+ | | SIA------------+
| +--------+ | | +--------+ | | |
| | V V | |
| | +-----------------+ | |
| | | CRL issued by A | | |
| A's Repository| +-----------------+ | |
| Directory | | |
+---------------|----------------------+ |
| |
+----------------+ | +----------------+ |
| B's Repository |<-------+ | C's Repository |<--+
| Directory | | Directory |
+----------------+ +----------------+
Figure 1. Use of AIA and SIA Extensions in the RPKI
图1。在RPKI中使用AIA和SIA扩展
In Figure 1, 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.
在图1中，证书B和C由CA A颁发。因此，证书B和C的AIA扩展指向（证书）A，证书A的SIA扩展指向CA A的附属产品的存储库发布点，其中包括证书B和C，以及A颁发的CRL。CRL分发点证书B和C中的（CRLDP）扩展都指向A颁发的CRL。
In this distributed repository structure, an instance of a CA's repository publication point contains all published certificates issued by that CA, and the CRL issued by that CA. This repository also contains all published digitally signed objects that are verified by an end-entity (EE) certificate issued by this CA.
在此分布式存储库结构中，CA的存储库发布点的实例包含该CA颁发的所有已发布证书以及该CA颁发的CRL。此存储库还包含所有已发布的数字签名对象，这些对象由该CA颁发的最终实体（EE）证书验证。
Every repository publication point MUST contain a manifest [RFC6486]. The manifest contains a list of the names of all objects, as well as the hash value of each object's contents that are currently published by a CA or an EE.
每个存储库发布点必须包含清单[RFC6486]。清单包含所有对象的名称列表，以及CA或EE当前发布的每个对象内容的哈希值。
An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. (It is noted that if no such access regime is in place, then RPs MAY be exposed to intermediate repository states where the manifest and the repository contents may not be precisely aligned. Specific cases and actions in such a situation of misalignment of the manifest and the repository contents are considered in [RFC6486].)
在发布涵盖此更改范围内所有操作的单一清单之前，授权机构可以在存储库更改范围内的发布存储库上执行多个对象操作。存储库操作员应在存储库上实现某种形式的目录管理机制功能，以确保在存储库上执行检索操作的RP在更改存储库和相关清单期间不会暴露于中间状态。（需要注意的是，如果没有这样的访问机制，则RPs可能会暴露于中间存储库状态，其中清单和存储库内容可能无法精确对齐。在这种情况下，清单和存储库内容未对齐的具体情况和操作将在[RFC6486]中考虑。）
A CA certificate has two accessMethod elements specified in its SIA field. The id-ad-caRepository accessMethod element has an associated accessLocation element that points to the repository publication point of the certificates issued by this CA, as specified in [RFC6487]. The id-ad-rpkiManifest accessMethod element has an associated accessLocation element that points to the manifest object, as an object URI (as distinct to a directory URI), that is associated with this CA.
CA证书在其SIA字段中指定了两个accessMethod元素。id ad caRepository accessMethod元素具有关联的accessLocation元素，该元素指向此CA颁发的证书的存储库发布点，如[RFC6487]中所述。id ad rpkiManifest accessMethod元素有一个关联的accessLocation元素，该元素指向清单对象，作为与此CA关联的对象URI（与目录URI不同）。
A CA's publication repository contains the current (non-expired and non-revoked) certificates issued by this CA, the most recent CRL issued by this CA, the current manifest, and all other current signed objects that can be verified using an EE certificate [RFC6487] issued by this CA.
CA的发布存储库包含由该CA颁发的当前（未过期和未吊销）证书、由该CA颁发的最新CRL、当前清单，以及可以使用由该CA颁发的EE证书[RFC6487]验证的所有其他当前已签名对象。
The CA's manifest contains the names of this collection of objects, together with the hash value of each object's contents, with the single exception of the manifest itself.
CA的清单包含此对象集合的名称，以及每个对象内容的哈希值，清单本身除外。
The RPKI design requires that a CA be uniquely associated with a single key pair. Thus, the administrative entity that is a CA performs key rollover by generating a new CA certificate with a new subject name, as well as a new key pair [RFC6489]. (The reason for the new subject name is that in the context of the RPKI, the subject names in all certificates issued by a CA are intended to be unique, and because the RPKI key rollover procedure creates a new instance of a CA with the new key, the name constraint implies the need for a new subject name for the CA with the new key.) In such cases, the entity SHOULD continue to use the same repository publication point for both CA instances during the key rollover, ensuring that the value of the AIA extension in indirect subordinate objects that refer to the certificates issued by this CA remain valid across the key rollover,
RPKI设计要求CA与单个密钥对唯一关联。因此，作为CA的管理实体通过生成具有新使用者名称以及新密钥对的新CA证书来执行密钥滚动[RFC6489]。（新使用者名称的原因是，在RPKI的上下文中，CA颁发的所有证书中的使用者名称都是唯一的，并且由于RPKI密钥翻转过程使用新密钥创建CA的新实例，因此名称约束意味着需要使用新密钥为CA提供新的使用者名称。）在这种情况下，实体应在密钥翻转期间继续为两个CA实例使用相同的存储库发布点，确保引用此CA颁发的证书的间接从属对象中的AIA扩展的值在密钥翻转期间保持有效，
and that the reissuance of subordinate certificates in a key rollover is limited to the collection of immediate subordinate products of this CA [RFC6489]. In such cases, the repository publication point will contain the CRL, manifest and subordinate certificates of both CA instances. (It is feasible for the entity to use distinct repository publication points for the old and new CA keys, but, in such a case, very careful coordination would be required with subordinate CAs and EEs to ensure that the AIA pointers in the indirect subordinate levels of the RPKI hierarchy are correctly aligned to the subordinate products of the new CA.)
密钥展期中次级证书的重新颁发仅限于收集该CA的直接次级产品[RFC6489]。在这种情况下，存储库发布点将包含两个CA实例的CRL、清单和从属证书。（实体可以为新旧CA密钥使用不同的存储库发布点，但在这种情况下，需要与下级CA和EE进行非常仔细的协调，以确保RPKI层次结构的间接下级级别中的AIA指针与新CA密钥的下级产品正确对齐。）约）
The following paragraphs provide guidelines for naming objects in a CA's repository publication point:
以下段落提供了命名CA存储库发布点中对象的指导原则：
CRL: When a CA issues a new CRL, it replaces the previous CRL (issued under the same CA key pair) in the repository publication point. CAs MUST NOT continue to publish previous CRLs in the repository publication point. Thus, it MUST replace (overwrite) previous CRLs signed by the same CA (instance). A non-normative guideline for naming such objects is that the file name chosen for the CRL in the repository be a value derived from the public key of the CA. One such method of generating a CRL publication name is described in Section 2.1 of [RFC4387]; convert the 160-bit hash of a CA's public key value into a 27-character string using a modified form of Base64 encoding, with an additional modification as proposed in Section 5, table 2, of [RFC4648]. The filename extension of ".crl" MUST be used to denote the file as a CRL. Each ".crl" file contains exactly one CRL encoded in DER format.
CRL：当CA发布新的CRL时，它将替换存储库发布点中以前的CRL（在同一CA密钥对下发布）。CA不得继续在存储库发布点中发布以前的CRL。因此，它必须替换（覆盖）由同一CA（实例）签名的以前的CRL。命名此类对象的非规范性指南是，为存储库中的CRL选择的文件名应为从CA公钥派生的值。生成CRL发布名的一种方法在[RFC4387]的第2.1节中描述；使用Base64编码的修改形式将CA公钥值的160位散列转换为27个字符的字符串，并按照[RFC4648]第5节表2的建议进行额外修改。文件扩展名“.crl”必须用于表示文件为crl。每个“.crl”文件只包含一个以DER格式编码的crl。
Manifest: When a new instance of a manifest is published, it MUST replace the previous manifest to avoid confusion. CAs MUST NOT continue to publish previous CA manifests in the repository publication point. A non-normative guideline for naming such objects is that the filename chosen for the manifest in the publication repository be a value derived from the public key part of the entity's key pair, using the algorithm described for CRLs above for generation of filenames. The filename extension of ".mft" MUST be used to denote the object as a manifest.
清单：发布清单的新实例时，它必须替换以前的清单以避免混淆。CA不得继续在存储库发布点中发布以前的CA清单。命名此类对象的非规范性指南是，为发布存储库中的清单选择的文件名应为从实体密钥对的公钥部分派生的值，使用上述CRL算法生成文件名。必须使用“.mft”的文件扩展名将对象表示为清单。
Certificates: Within the RPKI framework, it is possible that a CA MAY issue a series of certificates to the same subject name, the same subject public key, and the same resource collection. However, a relying party requires access only to the most recently published certificate in such a series. Thus, such a series of certificates SHOULD share the same filename. This ensures that each successive
证书：在RPKI框架内，CA可能会向相同的使用者名称、相同的使用者公钥和相同的资源集合颁发一系列证书。但是，依赖方仅要求访问此类系列中最近发布的证书。因此，这一系列证书应该共享相同的文件名。这确保了每个连续的
issued certificate in such a series effectively overwrites the previous instance of the certificate. It is feasible to use different filenames, but this imposes a burden on the validating user. A non-normative guideline for naming such objects is for the CA to adopt a (local) policy requiring a subject to use a unique key pair for each unique instance of a certificate series issued to the same subject, thereby allowing the CA to use a file name generation scheme based on the subject's public key, e.g., using the algorithm described above for CRLs above. Published certificates MUST use a filename extension of ".cer" to denote the object as a certificate. Each ".cer" file contains exactly one certificate encoded in DER format.
在这样一个系列中颁发的证书实际上覆盖了证书的上一个实例。使用不同的文件名是可行的，但这会给验证用户带来负担。命名此类对象的非规范性指南是CA采用（本地）策略，要求主体对向同一主体颁发的证书系列的每个唯一实例使用唯一密钥对，从而允许CA使用基于主体公钥的文件名生成方案，例如。，使用上述CRL的算法。已发布的证书必须使用扩展名“.cer”将对象表示为证书。每个“.cer”文件只包含一个以DER格式编码的证书。
Signed Objects: RPKI signed objects [RFC6488] are published in the repository publication point referenced by the SIA of the CA certificate that issued the EE certificate used to validate the digital signature of the signed object (and are directly referenced by the SIA of that EE certificate). A general non-normative guideline for naming such RPKI signed objects is for the filename of such objects to be derived from the associated EE certificate's public key, applying the algorithm described above. Published RPKI signed objects MUST NOT use the filename extensions ".crl", ".mft", or ".cer".
签名对象：RPKI签名对象[RFC6488]在CA证书的SIA引用的存储库发布点中发布，CA证书颁发了EE证书，用于验证签名对象的数字签名（并且由该EE证书的SIA直接引用）。命名此类RPKI签名对象的一般非规范性指南是，应用上述算法，从相关EE证书的公钥派生此类对象的文件名。已发布的RPKI签名对象不得使用文件扩展名“.crl”、“.mft”或“.cer”。
One form of signed object defined at the time of publication of this document is a Route Origination Authorization (ROA) [RFC6482]. Published ROAs MUST use a filename extension of ".roa" to denote the object as a ROA.
本文件发布时定义的签名对象的一种形式是路由发起授权（ROA）[RFC6482]。已发布的roa必须使用文件扩展名“.roa”将对象表示为roa。
Each issuer MAY publish its issued certificates and CRL in any repository. However, there are a number of considerations that guide the choice of a suitable repository publication structure:
每个颁发者可以在任何存储库中发布其颁发的证书和CRL。但是，在选择合适的存储库发布结构时，有许多注意事项：
* The publication repository SHOULD be hosted on a highly available service and high-capacity publication platform.
* 发布存储库应托管在高可用性服务和高容量发布平台上。
* The publication repository MUST be available using rsync [RFC5781] [RSYNC]. Support of additional retrieval mechanisms is the choice of the repository operator. The supported retrieval mechanisms MUST be consistent with the accessMethod element value(s) specified in the SIA of the associated CA or EE certificate.
* 发布存储库必须使用rsync[RFC5781][rsync]可用。支持其他检索机制是存储库操作员的选择。支持的检索机制必须与关联CA或EE证书的SIA中指定的accessMethod元素值一致。
* Each CA repository publication point SHOULD contain the products of this CA, including those objects that can be verified by EE certificates that have been issued by this CA. The signed products of related CA's that are operated by the same entity MAY share this CA repository publication point. Aside from subdirectories, any other objects SHOULD NOT be placed in a repository publication point.
* 每个CA存储库发布点应包含此CA的产品，包括可由此CA颁发的EE证书验证的对象。由同一实体操作的相关CA的签名产品可能共享此CA存储库发布点。除了子目录之外，任何其他对象都不应放置在存储库发布点中。
Any such subdirectory SHOULD be the repository publication point of a CA or EE certificate that is contained in the CA directory. These considerations also apply recursively to subdirectories of these directories. Detection of content that is not a CA product has the potential to cause confusion to RPs, and in such a case RPs should exercise caution not to invalidate the valid CA products found at the CA's repository publication point.
任何这样的子目录都应该是CA目录中包含的CA或EE证书的存储库发布点。这些注意事项也递归地应用于这些目录的子目录。检测非CA产品的内容可能会导致RPs混淆，在这种情况下，RPs应谨慎行事，不要使在CA的存储库发布点找到的有效CA产品无效。
* Signed objects are published in the location indicated by the SIA field of the EE certificate used to verify the signature of each object. Signed objects are published in the repository publication point of the CA certificate that issued the EE certificate. The SIA extension of the EE certificate references this object rather than the repository publication directory [RFC6487].
* 签名对象发布在EE证书的SIA字段指示的位置，用于验证每个对象的签名。签名对象在颁发EE证书的CA证书的存储库发布点中发布。EE证书的SIA扩展引用此对象，而不是存储库发布目录[RFC6487]。
* Section 2.1 states that repository operators SHOULD implement some form of directory management regime function on the repository to ensure that RPs who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. Notwithstanding the following commentary, RPs SHOULD NOT assume that a consistent repository and manifest state are assured, and they SHOULD organize their retrieval operations accordingly (see Section 5).
* 第2.1节指出，存储库操作员应在存储库上实施某种形式的目录管理机制功能，以确保在存储库上执行检索操作的RP在存储库和相关清单更改期间不会暴露于中间状态。尽管有以下注释，RPs不应假设一致的存储库和清单状态得到保证，它们应相应地组织检索操作（参见第5节）。
The manner in which a repository operator can implement a directory update regime that mitigates the risk of the manifest and directory contents being inconsistent, to some extent, is dependent on the operational characteristics of the filesystem that hosts the repository, so the following comments are non-normative in terms of any implicit guidelines for repository operators.
在某种程度上，存储库操作员实施目录更新制度以降低清单和目录内容不一致的风险的方式取决于托管存储库的文件系统的操作特征，因此，就存储库操作员的任何隐式指南而言，以下评论都是不规范的。
A commonly used technique to avoid exposure to inconsistent retrieval states during updates to a large directory is to batch a set of changes to be made, create a working copy of the directory's contents, and then perform the batch of changes to the local copy of the directory. On completion, rename the
在更新大目录期间，避免暴露于不一致的检索状态的一种常用技术是批处理一组要进行的更改，创建目录内容的工作副本，然后对目录的本地副本执行批处理更改。完成后，重命名
filesystem symbolic link of the repository directory name to point to this working copy of the directory. The old repository directory contents can be purged at a slightly later time. However, it is noted that the outcomes of this technique in terms of ensuring the integrity of client synchronization functions performed over the directory depend on the interaction between the supported access mechanisms and the local filesystem behavior. It is probable that this technique will not remove all possibilities for RPs to see inconsistent states between the manifest and the repository. Because a repository has the potential to be in an partially updated state, it cannot be guaranteed to be internally self consistent all the time.
文件系统存储库目录名称的符号链接，指向该目录的工作副本。旧的存储库目录内容可以稍后清除。但是，需要注意的是，在确保通过目录执行的客户端同步功能的完整性方面，该技术的结果取决于受支持的访问机制和本地文件系统行为之间的交互。这种技术可能不会消除RPs看到清单和存储库之间不一致状态的所有可能性。因为存储库可能处于部分更新状态，所以不能保证它始终保持内部自一致性。
If a CA certificate is reissued, e.g., due to changes in the set of resources contained in the number resource extensions, it should not be necessary to reissue all certificates issued under it. Because these certificates contain AIA extensions that point to the publication point for the CA certificate, a CA SHOULD use a name for its repository publication point that persists across certificate reissuance events. That is, reissued CA certificates SHOULD use the same repository publication point as previously issued CA certificates having the same subject and subject public key, such that certificate reissuance SHOULD intentionally overwrite the previously issued certificate within the repository publication point.
如果重新颁发CA证书，例如，由于数字资源扩展中包含的资源集发生更改，则无需重新颁发根据该证书颁发的所有证书。因为这些证书包含指向CA证书的发布点的AIA扩展，CA应该为其存储库发布点使用一个名称，该名称在证书重新颁发事件中持续存在。也就是说，重新颁发的CA证书应使用与先前颁发的CA证书相同的存储库发布点，这些CA证书具有相同的主题和主题公钥，因此证书重新颁发应故意覆盖存储库发布点内先前颁发的证书。
It is noted in Section 2.2 that when a CA performs a key rollover, the entity SHOULD use a name for its repository publication point that persists across key rollover. In such cases, the repository publication point will contain the CRLs and manifests of both CA instances as a transient state in the key rollover procedure. The RPKI key rollover procedure [RFC6489] requires that the subordinate products of the old CA be overwritten in the common repository publication point by subordinate products issued by the new CA.
在第2.2节中注意到，当CA执行密钥滚动时，实体应该为其存储库发布点使用一个名称，该名称在密钥滚动期间持续存在。在这种情况下，存储库发布点将包含两个CA实例的CRL和清单，作为密钥滚动过程中的瞬态。RPKI密钥滚动过程[RFC6489]要求旧CA的从属产品在公共存储库发布点被新CA发布的从属产品覆盖。
It is possible to perform the validation-related task of certificate path construction using the retrieval of individual certificates, and certificate revocation lists using online retrieval of individual certificates, sets of candidate certificates and certificate revocation lists based on the AIA, SIA, and CRLDP certificate fields. This is NOT recommended in circumstances where speed and efficiency are relevant considerations.
可以使用单个证书的检索来执行证书路径构造的验证相关任务，以及使用基于AIA、SIA和CRLDP证书字段的单个证书、候选证书集和证书撤销列表的在线检索来执行证书撤销列表。在考虑速度和效率的情况下，不建议这样做。
To enable efficient validation of RPKI certificates, CRLs, and signed objects, it is recommended that each relying party maintain a local repository containing a synchronized copy of all valid certificates, current certificate revocation lists, and all related signed objects.
为了有效验证RPKI证书、CRL和签名对象，建议每个依赖方维护一个本地存储库，其中包含所有有效证书、当前证书吊销列表和所有相关签名对象的同步副本。
The general approach to repository synchronization is one of a "top-down" walk of the distributed repository structure. This commences with the collection of locally selected trust anchor material corresponding to the local choice of Trust Anchors, which can be used to load the initial set of self-signed resource certificate(s) that form the "seed" of this process [RFC6490]. The process then populates the local repository cache with all valid certificates that have been issued by these issuers. This procedure can be recursively applied to each of these subordinate certificates. Such a repository traversal process SHOULD support a locally configured maximal chain length from the initial trust anchors. If this is not done, then there might be a SIA pointer loop, or other degenerate forms of the logical RPKI hierarchy, that would cause an RP to malfunction when performing a repository synchronization operation with the RP's local RPKI cache.
存储库同步的一般方法是分布式存储库结构的一种“自上而下”的方法。这从收集与信任锚的本地选择相对应的本地选择的信任锚材料开始，可用于加载形成此过程“种子”的初始自签名资源证书集[RFC6490]。然后，该过程用这些颁发者颁发的所有有效证书填充本地存储库缓存。此过程可以递归地应用于每个从属证书。这样的存储库遍历过程应该支持从初始信任锚点开始的本地配置的最大链长度。如果不这样做，则可能存在SIA指针循环或逻辑RPKI层次结构的其他退化形式，这将导致RP在使用RP的本地RPKI缓存执行存储库同步操作时发生故障。
RPs SHOULD ensure that this local synchronization uses the retrieved manifests [RFC6486] to ensure that they are synchronizing against a current, consistent state of each repository publication point. It is noted in Section 3 that when the repository publication point contents are updated, a repository operator cannot assure RPs that the manifest contents and the repository contents will be precisely aligned at all times. RPs SHOULD use a retrieval algorithm that takes this potential for transient inconsistency into account. For the RP to mitigate this situation, possible algorithms include performing the synchronization across the repository twice in succession, or performing a manifest retrieval both before and after the synchronization of the directory contents, and repeating the synchronization function if the second copy of the manifest differs from the first.
RPs应确保此本地同步使用检索到的清单[RFC6486]，以确保它们针对每个存储库发布点的当前一致状态进行同步。第3节指出，当更新存储库发布点内容时，存储库操作员无法向RPs保证清单内容和存储库内容将始终精确对齐。RPs应该使用一种检索算法，将这种可能出现的暂时不一致性考虑在内。对于RP来说，为了缓解这种情况，可能的算法包括在存储库中连续执行两次同步，或者在同步目录内容之前和之后执行清单检索，如果清单的第二个副本与第一个不同，则重复同步功能。
Repositories are not assumed to be integrity-protected databases, and repository retrieval operations might be vulnerable to various forms of "man-in-the-middle" attacks. Corruption of retrieved objects is detectable by a relying party through the validation of the signature associated with each retrieved object. Replacement of newer instances of an object with an older instance of the same object is detectable through the use of manifests. Insertion of revoked, deleted certificates is detected through the retrieval and processing
存储库不被认为是受完整性保护的数据库，存储库检索操作可能容易受到各种形式的“中间人”攻击。依赖方可通过验证与每个检索对象关联的签名来检测检索对象的损坏。使用清单可以检测到用同一对象的旧实例替换对象的新实例。通过检索和处理检测插入已吊销、已删除的证书
of CRLs at scheduled intervals. However, even the use of manifests and CRLs will not allow a relying party to detect all forms of substitution attacks based on older (but not expired) valid objects.
按预定时间间隔对CRL进行更新。但是，即使使用清单和CRL，依赖方也无法检测基于旧（但未过期）有效对象的所有形式的替换攻击。
Confidentiality is not provided by the repository or by the signed objects published in the repository. Data that is subject to controlled access should not be included in signed objects in the repository unless there is some specified mechanism used to ensure the confidentiality of the data contained in the signed object.
存储库或存储库中发布的已签名对象不提供机密性。受控制访问的数据不应包含在存储库中的签名对象中，除非有某种指定的机制用于确保签名对象中包含的数据的机密性。
IANA has registered the following two media types:
IANA已注册了以下两种媒体类型：
application/rpki-manifest application/rpki-roa
应用程序/rpki清单应用程序/rpki roa
This document also uses the .cer and .crl file extensions from the application/pkix-cert and application/pkix-crl media registries defined in [RFC2585].
本文档还使用[RFC2585]中定义的application/pkix证书和application/pkix crl介质注册表中的.cer和.crl文件扩展名。
MIME media type name: application
MIME subtype name: rpki-manifest
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Manifest [RFC6486]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .mft
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
MIME media type name: application
MIME subtype name: rpki-manifest
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Manifest [RFC6486]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .mft
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
MIME media type name: application
MIME subtype name: rpki-roa
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI ROA [RFC6482]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .roa
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
MIME media type name: application
MIME subtype name: rpki-roa
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI ROA [RFC6482]
Interoperability considerations: None
Published specification: This document
Applications that use this media type: Any MIME-complaint transport
Additional information:
Magic number(s): None
File extension(s): .roa
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Author/Change controller: Geoff Huston <gih@apnic.net>
IANA has created the "RPKI Repository Name Scheme" registry. The registry contains three-letter filename extensions for RPKI repository objects. The registry's contents are managed by IETF Review [RFC5226]. The initial contents of this registry are the following:
IANA已经创建了“RPKI存储库名称方案”注册表。注册表包含RPKI存储库对象的三个字母文件扩展名。注册表的内容由IETF Review[RFC5226]管理。此注册表的初始内容如下：
Filename extension RPKI Object Reference
.cer Certificate [RFC6481]
.crl Certificate Revocation List [RFC6481]
.mft Manifest [RFC6481]
.roa Route Origination Authorization [RFC6481]
Filename extension RPKI Object Reference
.cer Certificate [RFC6481]
.crl Certificate Revocation List [RFC6481]
.mft Manifest [RFC6481]
.roa Route Origination Authorization [RFC6481]
This document has benefitted from helpful review comments and input from Stephen Kent, Matt Lepenski, Michael Elkins, Russ Housley, and Sean Turner.
本文件得益于斯蒂芬·肯特、马特·莱彭斯基、迈克尔·埃尔金斯、罗斯·霍斯利和肖恩·特纳的有益评论和意见。
[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月。
[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 (RPKI)", RFC 6486, February 2012.
[RFC6486]Austein，R.，Huston，G.，Kent，S.，和M.Lepinski，“资源公钥基础设施（RPKI）清单”，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 (RPKI)", RFC 6488, February 2012.
[RFC6488]Lepinski，M.，Chi，A.，和S.Kent，“资源公钥基础设施（RPKI）的签名对象模板”，RFC 6488，2012年2月。
[RSYNC] rsync web pages, <http://rsync.samba.org/>.
[RSYNC]RSYNC网页<http://rsync.samba.org/>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, February 2006.
[RFC4387]Gutmann，P.，Ed.“Internet X.509公钥基础设施操作协议：通过HTTP访问证书存储”，RFC 4387，2006年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[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月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，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月。
Authors' Addresses
作者地址
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
URI: http://www.apnic.net
EMail: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans APNIC
罗伯特·卢曼斯呼吸暂停综合征
EMail: robertl@apnic.net
URI: http://www.apnic.net
EMail: robertl@apnic.net
URI: http://www.apnic.net
George Michaelson APNIC
乔治·迈克尔森呼吸暂停综合征
EMail: ggm@apnic.net
URI: http://www.apnic.net
EMail: ggm@apnic.net
URI: http://www.apnic.net