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
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 存储库中发布对象，供注册用户下载。
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 都必须能在全球范围内访问这些对象。在创建证书、证书废止列表和签名对象时，它们会被上传到存储库发布点，RP 可以从那里下载使用。
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 地址块和 AS 号码的绑定。资源证书的主体可通过使用私钥生成数字签名（可使用证书中的公钥进行验证）来证明自己是证书中列举的资源的持有者。
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].
假定读者已熟悉 "互联网 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].
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY "和 "OPTIONAL "应按照 [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）证书，都有一个相应的存储库发布点，它是该认证机构签发的所有当前证书和 CRL 的权威发布点。证书的 SIA 扩展名包含一个 URI [RFC3986]，用于引用该存储库发布点并标识存储库访问机制。此外，证书的 Authority Information Access (AIA) 扩展名包含一个 URI，用于引用 CA 证书的权威位置，该 CA 证书就是根据该 URI 签发的。
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 |
+----------------+ +----------------+
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.
因此，证书 B 和 C 的 AIA 扩展指向（证书）A，证书 A 的 SIA 扩展指向 CA A 下属产品的存储库发布点，其中包括证书 B 和 C 以及 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 可能会暴露于中间存储库状态，在这种状态下，清单和存储库内容可能无法精确对齐。[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 元素，该元素指向 [RFC6487] 中规定的由该 CA 签发的证书的存储库发布点。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, 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.)
RPKI 设计要求 CA 与单个配对密钥唯一关联。因此，作为 CA 的管理实体通过生成具有新主体名的新 CA 证书和新的配对密钥来执行密钥展期 [RFC6489]。(使用新的主体名的原因是，在 RPKI 中，由 CA 签发的所有证书中的主体名都是唯一的，而由于 RPKI 密钥展期程序是用新的密钥创建 CA 的新实例，因此名称限制意味着需要用新的密钥为 CA 创建新的主体名）。在这种情况下，实体应在密钥转移期间继续对两个 CA 实例使用相同的存储库发布点，确保间接从属对象中引用该 CA 签发的证书的 AIA 扩展名的值在密钥转移期间保持有效，并确保在密钥转移中重新签发的从属证书仅限于该 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 公钥派生的值。RFC4387] 第 2.1 节描述了生成 CRL 发布名称的一种方法；使用 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 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.
证书：在 RPKI 框架内，CA 可以为同一主体名称、同一主体公开密钥和同一资源集合签发一系列证书。然而，依赖方只需访问该系列中最近发布的证书。因此，这一系列证书应共享相同的文件名。这样可确保该系列中每个连续发布的证书都能有效覆盖前一个证书实例。使用不同的文件名是可行的，但这会给验证用户带来负担。命名此类对象的一个非规范性准则是由 CA 采用（本地）政策，要求主体对签发给同一主体的证书系列中的每个唯一实例使用唯一的配对密钥，从而允许 CA 使用基于主体公开密钥的文件名生成方案，例如使用上文所述的 CRLs 算法。已发布的证书必须使用文件名扩展名".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 产品的内容有可能给注册管理员造成混乱，在这种情况下，注册管理员应谨慎行事，不要使在 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 节指出，版本库操作员应在版本库上实施某种形式的目录管理制度功能，以确保在版本库上执行检索操作的注册管理员在版本库和相关清单发生变化时不会暴露于中间状态。尽管有以下评注，但注册管理员不应假定版本库和清单的状态是一致的，他们应据此组织检索操作（见第 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.
为避免在更新大型目录时出现不一致的检索状态，一种常用的技术是批量进行一系列更改，创建目录内容的工作副本，然后对目录的本地副本执行批量更改。完成后，重命名版本库目录名的文件系统符号链接，使其指向该目录的工作副本。旧的版本库目录内容可以稍后再清除。不过，需要注意的是，在确保客户端同步功能的完整性方面，该技术的结果取决于所支持的访问机制与本地文件系统行为之间的相互作用。这种技术很可能无法消除 RP 在清单和存储库之间看到不一致状态的所有可能性。因为资源库有可能处于部分更新状态，所以无法保证其内部始终保持自一致性。
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 证书使用相同的存储库公布点，这样证书的重新签发应有意覆盖存储库公布点内以前签发的证书。
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 证书、证书废止列表和签名对象，建议每个依赖方都维护一个本地存储库，其中包含所有有效证书、当前证书废止列表和所有相关签名对象的同步副本。
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.
RP 应确保这种本地同步使用检索到的清单 [RFC6486]，以确保它们与每个存储库发布点的当前一致状态同步。第 3 节指出，当版本库发布点内容更新时，版本库操作员无法向 RP 保证清单内容和版本库内容始终精确一致。RP 应当使用一种检索算法，将这种潜在的瞬时不一致性考虑在内。对于 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
application/rpkii-manifest application/rpkii-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-cert 和 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 <[email protected]>
Intended usage: COMMON
Author/Change controller: Geoff Huston <[email protected]>
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 <[email protected]>
Intended usage: COMMON
Author/Change controller: Geoff Huston <[email protected]>
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 审查[RFC5226]管理。该注册表的初始内容如下：
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.
斯蒂芬-肯特（Stephen Kent）、马特-莱彭斯基（Matt Lepenski）、迈克尔-埃尔金斯（Michael Elkins）、拉斯-豪斯利（Russ Housley）和肖恩-特纳（Sean Turner）为本文件提供了有益的审查意见和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[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., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.
[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., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[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., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[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. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols：FTP 和 HTTP"，RFC 2585，1999 年 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., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[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., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[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 Public Key Infrastructure Operational Protocols：证书存储通过 HTTP 访问"，RFC 4387，2006 年 2 月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[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，"RFC 中 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., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "rsync URI Scheme", RFC 5781, February 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[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., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[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., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
Authors' Addresses
作者地址
Geoff Huston APNIC
Geoff Huston APNIC
EMail: [email protected] URI: http://www.apnic.net
Robert Loomans APNIC
罗伯特-卢曼斯 APNIC
EMail: [email protected] URI: http://www.apnic.net
George Michaelson APNIC
乔治-迈克尔逊 APNIC
EMail: [email protected] URI: http://www.apnic.net