Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 6486 ISC
Category: Standards Track G. Huston
ISSN: 2070-1721 APNIC
S. Kent
M. Lepinski
BBN
February 2012
Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 6486 ISC
Category: Standards Track G. Huston
ISSN: 2070-1721 APNIC
S. Kent
M. Lepinski
BBN
February 2012
Manifests for the Resource Public Key Infrastructure (RPKI)
资源公钥基础结构（RPKI）的清单
Abstract
摘要
This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects.
本文档定义了在资源公钥基础结构（RPKI）中使用的“清单”。清单是一个已签名对象（文件），其中包含与负责在存储库中发布的机构关联的存储库发布点（目录）中所有已签名对象（文件）的列表。对于在此存储库发布点发布的每个证书、证书吊销列表（CRL）或由授权机构发布的其他类型的签名对象，清单包含包含包含该对象的文件名和文件内容的哈希。清单旨在使依赖方（RP）能够检测针对存储库的某些形式的攻击。具体来说，如果RP根据从存储库发布点检索的签名对象检查清单的内容，则RP可以检测“过时”（有效）数据和签名对象的删除。
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/rfc6486.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6486.
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. Manifest Scope ..................................................4
3. Manifest Signing ................................................4
4. Manifest Definition .............................................5
4.1. eContentType ...............................................5
4.2. eContent ...................................................5
4.2.1. Manifest ............................................5
4.3. Content-Type Attribute .....................................7
4.4. Manifest Validation ........................................7
5. Manifest Generation .............................................7
5.1. Manifest Generation Procedure ..............................7
5.2. Considerations for Manifest Generation .....................9
6. Relying Party Use of Manifests ..................................9
6.1. Tests for Determining Manifest State ......................10
6.2. Missing Manifests .........................................11
6.3. Invalid Manifests .........................................12
6.4. Stale Manifests ...........................................12
6.5. Mismatch between Manifest and Publication Point ...........13
6.6. Hash Values Not Matching Manifests ........................14
7. Publication Repositories .......................................15
8. Security Considerations ........................................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Appendix A. ASN.1 Module ..........................................18
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Manifest Scope ..................................................4
3. Manifest Signing ................................................4
4. Manifest Definition .............................................5
4.1. eContentType ...............................................5
4.2. eContent ...................................................5
4.2.1. Manifest ............................................5
4.3. Content-Type Attribute .....................................7
4.4. Manifest Validation ........................................7
5. Manifest Generation .............................................7
5.1. Manifest Generation Procedure ..............................7
5.2. Considerations for Manifest Generation .....................9
6. Relying Party Use of Manifests ..................................9
6.1. Tests for Determining Manifest State ......................10
6.2. Missing Manifests .........................................11
6.3. Invalid Manifests .........................................12
6.4. Stale Manifests ...........................................12
6.5. Mismatch between Manifest and Publication Point ...........13
6.6. Hash Values Not Matching Manifests ........................14
7. Publication Repositories .......................................15
8. Security Considerations ........................................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Appendix A. ASN.1 Module ..........................................18
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of a distributed repository system [RFC6481] to make available a variety of objects needed by relying parties (RPs). Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs. However, digital signatures provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, the RPKI repository system can make use of a signed object called a "manifest".
资源公钥基础设施（RPKI）[RFC6480]利用分布式存储库系统[RFC6481]提供依赖方（RP）所需的各种对象。由于存储在存储库系统中的所有对象都由创建它们的实体进行数字签名，因此RPs可以检测到修改这些已发布对象的攻击。但是，数字签名不提供任何保护，以防攻击替代已签名对象的“过时”版本（即，有效且尚未过期但已被取代的对象）或删除存储库中应存在的对象的攻击。为了帮助检测此类攻击，RPKI存储库系统可以使用一个称为“清单”的签名对象。
A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point. Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point. A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point. A manifest also is intended to allow an RP to detect similar outcomes that may result from a man-in-the-middle attack on the retrieval of objects from the repository. Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by end-entity (EE) certificates issued by this CA).
清单是一个签名对象，它枚举存储库发布点（目录）中与负责在该发布点发布的机构关联的所有签名对象（文件）。每个清单都包含包含对象的文件的名称和文件内容的哈希，对于由授权机构的存储库发布点发布的每个已签名对象。清单旨在允许RP在发布点检测未经授权的对象移除或对象过时版本的替换。清单还旨在允许RP检测到中间人攻击从存储库检索对象可能导致的类似结果。清单旨在用于存储库中的证书颁发机构（CA）发布点（包含此CA颁发的从属证书和证书吊销列表（CRL）文件的目录，以及由此CA颁发的最终实体（EE）证书验证的其他签名对象）。
Manifests are modeled on CRLs, as the issues involved in detecting stale manifests and potential attacks using manifest replays, etc., are similar to those for CRLs. The syntax of the manifest payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs, e.g., digitally signed objects, such as Route Origination Authorizations (ROAs).
清单是在CRL上建模的，因为使用清单重放等检测陈旧清单和潜在攻击所涉及的问题与CRL的问题类似。清单有效负载的语法不同于CRL，因为RPKI存储库包含CRL未涵盖的对象，例如数字签名对象，如路由发起授权（ROA）。
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]中所述进行解释。
A manifest associated with a CA's repository publication point contains a list of:
与CA的存储库发布点关联的清单包含以下列表：
* the set of (non-expired, non-revoked) certificates issued and published by this CA,
* 由该CA颁发和发布的一组（未过期、未撤销）证书，
* the most recent CRL issued by this CA, and
* 本CA最近发布的CRL，以及
* all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA.
* 可使用此CA颁发的EE证书[RFC6487]验证的所有已发布签名对象。
Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used to verify it [RFC6488]. Thus, there is no requirement to separately publish that EE certificate at the CA's repository publication point.
在对象的加密消息语法（CMS）[RFC3370]包装中，每个RPKI签名对象都包括用于验证它的EE证书[RFC6488]。因此，不需要在CA的存储库发布点单独发布该EE证书。
Where multiple CA instances share a common publication point, as can occur when an entity performs a key-rollover operation [RFC6489], the repository publication point will contain multiple manifests. In this case, each manifest describes only the collection of published products of its associated CA instance.
当多个CA实例共享一个公共发布点时（当实体执行密钥滚动操作[RFC6489]时），存储库发布点将包含多个清单。在本例中，每个清单仅描述其关联CA实例的已发布产品的集合。
A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains the access method OID of id-ad-signedObject.
CA的清单使用EE证书进行验证。此EE证书的SubjectInfo访问（SIA）字段包含id为ad signedObject的访问方法OID。
The CA MAY choose to sign only one manifest with each generated private key, and generate a new key pair for each new version of the manifest. This form of use of the associated EE certificate is termed a "one-time-use" EE certificate.
CA可以选择使用每个生成的私钥只对一个清单进行签名，并为清单的每个新版本生成一个新的密钥对。相关EE证书的这种使用形式称为“一次性使用”EE证书。
Alternatively, the CA MAY elect to use the same private key to sign a sequence of manifests. Because only a single manifest (issued under a single CA instance) is current at any point in time, the associated EE certificate is used to verify only a single object at a time. As long as the sequence of objects verified by this EE certificate are published using the same file name, then this sequential, multiple use of the EE certificate is also valid. This form of use of an EE certificate is termed a "sequential-use" EE certificate.
或者，CA可以选择使用相同的私钥对清单序列进行签名。因为在任何时间点只有一个清单（在单个CA实例下发布）是当前的，所以关联的EE证书一次只用于验证单个对象。只要此EE证书验证的对象序列使用相同的文件名发布，则此连续多次使用EE证书也是有效的。EE证书的这种使用形式称为“顺序使用”EE证书。
A manifest is an RPKI signed object, as specified in [RFC6488]. The RPKI signed object template requires specification of the following data elements in the context of the manifest structure.
清单是一个RPKI签名的对象，如[RFC6488]中所述。RPKI签名对象模板要求在清单结构的上下文中指定以下数据元素。
The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26.
清单的eContentType定义为id ct rpkiManifest，其数值为1.2.840.113549.1.9.16.1.26。
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
The content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690]. The content of a manifest is defined as follows:
清单的内容使用可分辨编码规则（DER）[X.690]进行ASN.1编码。清单的内容定义如下：
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding fields in X.509 CRLs (see [RFC5280]). Analogous to CRLs, a manifest is nominally current until the time specified in nextUpdate or until a manifest is issued with a greater manifest number, whichever comes first.
manifestNumber、thisUpdate和nextUpdate字段按照X.509 CRLs中的相应字段建模（请参见[RFC5280]）。与CRL类似，在nextUpdate中指定的时间之前，或者在向清单发出更大的清单编号之前，清单名义上是最新的，以先到者为准。
If a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate MUST have a validity period that coincides with
如果使用“一次性使用”EE证书验证舱单，则EE证书的有效期必须与
the interval from thisUpdate to nextUpdate, to prevent needless growth of the CA's CRL.
从此更新到下一个更新的间隔，以防止CA的CRL不必要的增长。
If a "sequential-use" EE certificate is employed to verify a manifest, the EE certificate's validity period needs to be no shorter than the nextUpdate time of the current manifest. The extended validity time raises the possibility of a substitution attack using a stale manifest, as described in Section 6.4.
如果使用“顺序使用”EE证书来验证清单，则EE证书的有效期需要不短于当前清单的下一个最新时间。如第6.4节所述，延长的有效期增加了使用过期清单进行替换攻击的可能性。
The data elements of the manifest structure are defined as follows:
清单结构的数据元素定义如下：
version: The version number of this version of the manifest specification MUST be 0.
版本：此清单规范版本的版本号必须为0。
manifestNumber: This field is an integer that is incremented each time a new manifest is issued for a given publication point. This field allows an RP to detect gaps in a sequence of published manifests.
manifestNumber：该字段是一个整数，每次为给定发布点发布新清单时，该字段都会递增。此字段允许RP检测已发布清单序列中的间隙。
As the manifest is modeled on the CRL specification, the ManifestNumber is analogous to the CRLNumber, and the guidance in [RFC5280] for CRLNumber values is appropriate as to the range of number values that can be used for the manifestNumber. Manifest numbers can be expected to contain long integers. Manifest verifiers MUST be able to handle number values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets.
由于清单是根据CRL规范建模的，ManifestNumber与CRLNumber类似，[RFC5280]中关于CRLNumber值的指南适用于ManifestNumber可使用的数值范围。清单编号应包含长整数。清单验证器必须能够处理多达20个八位字节的数值。合格舱单签发人不得使用超过20个八位字节的数值。
thisUpdate: This field contains the time when the manifest was created. This field has the same format constraints as specified in [RFC5280] for the CRL field of the same name.
thisUpdate：此字段包含创建清单的时间。此字段具有与[RFC5280]中为相同名称的CRL字段指定的相同格式约束。
nextUpdate: This field contains the time at which the next scheduled manifest will be issued. The value of nextUpdate MUST be later than the value of thisUpdate. The specification of the GeneralizedTime value is the same as required for the thisUpdate field.
nextUpdate：此字段包含下一个计划清单的发布时间。nextUpdate的值必须晚于thisUpdate的值。GeneratedTime值的规格与thisUpdate字段的要求相同。
If the authority alters any of the items that it has published in the repository publication point, then the authority MUST issue a new manifest before the nextUpdate time. If a manifest encompasses a CRL, the nextUpdate field of the manifest MUST match that of the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL is published. If a "one-time-use" EE certificate is used to verify the manifest, then when a new manifest is issued before the time specified in nextUpdate of the
如果管理局更改了其在存储库发布点中发布的任何项，则管理局必须在nextUpdate时间之前发布新的清单。如果清单包含CRL，则清单的nextUpdate字段必须与CRL的nextUpdate字段匹配，因为在发布新CRL时，将重新发布清单。如果使用“一次性使用”EE证书来验证清单，则在
current manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest.
在当前清单中，CA还必须颁发新的CRL，其中包括与旧清单对应的EE证书。
fileHashAlg: This field contains the OID of the hash algorithm used to hash the files that the authority has placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC6485].
fileHashAlg：此字段包含哈希算法的OID，该算法用于哈希授权机构已放置到存储库中的文件。使用的哈希算法必须符合RPKI算法和密钥大小配置文件规范[RFC6485]。
fileList: This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each currently valid signed object that has been published by the authority (at this publication point). Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents.
fileList：此字段是FileAndHash对象的序列。对于授权机构（在此发布点）发布的每个当前有效的已签名对象，都有一个FileAndHash条目。每个FileAndHash都是一个有序对，由存储库发布点（目录）中的文件名和文件内容的哈希组成，存储库发布点（目录）包含有问题的对象。
The mandatory content-type attribute MUST have its attrValues field set to the same OID as eContentType. This OID is id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26.
强制内容类型属性必须将其attrValues字段设置为与eContentType相同的OID。该OID为id ct rpkiManifest，数值为1.2.840.113549.1.9.16.1.26。
To determine whether a manifest is valid, the RP MUST perform the following checks in addition to those specified in [RFC6488]:
为了确定清单是否有效，RP除了[RFC6488]中指定的检查外，还必须执行以下检查：
1. The eContentType in the EncapsulatedContentInfo is id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
1. 封装的ContentInfo中的eContentType是id ad rpkiManifest（OID 1.2.840.113549.1.9.16.1.26）。
2. The version of the rpkiManifest is 0.
2. rpkiManifest的版本为0。
3. In the rpkiManifest, thisUpdate precedes nextUpdate.
3. 在rpkiManifest中，此更新先于下一个安装日期。
If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present.
如果上述过程表明清单无效，则必须丢弃清单，并将其视为不存在清单。
For a CA publication point in the RPKI repository system, a CA MUST perform the following steps to generate a manifest:
对于RPKI存储库系统中的CA发布点，CA必须执行以下步骤以生成清单：
1. If no key pair exists, or if using a "one-time-use" EE certificate with a new key pair, generate a key pair.
1. 如果不存在密钥对，或者如果将“一次性使用”EE证书与新密钥对一起使用，则生成密钥对。
2. If using a "one-time-use" EE certificate, or if a key pair was generated in step 1, or if using a "sequential-use" EE certificate that will expire before the intended nextUpdate time of this manifest, issue an EE certificate for this key pair.
2. 如果使用“一次性使用”EE证书，或者如果在步骤1中生成了密钥对，或者如果使用的“顺序使用”EE证书将在本清单的预期下一次更新时间之前过期，请为此密钥对颁发EE证书。
This EE certificate MUST have an SIA extension access description field with an accessMethod OID value of id-ad-signedobject, where the associated accessLocation references the publication point of the manifest as an object URL.
此EE证书必须有一个SIA扩展访问描述字段，其accessMethod OID值为id ad signedobject，其中关联的accessLocation引用清单的发布点作为对象URL。
This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than explicit description of a resource set (see [RFC3779]).
此EE证书必须使用“继承”属性描述其Internet号码资源（INR），而不是资源集的明确描述（请参见[RFC3779]）。
In the case of a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest.
对于“一次性使用”EE证书，EE证书的有效时间必须与清单的thisUpdate和nextUpdate时间完全匹配。
In the case of a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate.
在“顺序使用”EE证书的情况下，EE证书的有效时间必须包括从此更新到下一个更新日期的时间间隔。
3. The EE certificate MUST NOT be published in the authority's repository publication point.
3. EE证书不得在管理局的存储库发布点中发布。
4. Construct the manifest content.
4. 构造清单内容。
The manifest content is described in Section 4.2.1. The manifest's fileList includes the file name and hash pair for each object issued by this CA that has been published at this repository publication point (directory). The collection of objects to be included in the manifest includes all certificates issued by this CA that are published at the CA's repository publication point, the most recent CRL issued by the CA, and all objects verified by EE certificates that were issued by this CA that are published at this repository publication point.
清单内容见第4.2.1节。清单的文件列表包括已在此存储库发布点（目录）发布的此CA发布的每个对象的文件名和哈希对。要包含在清单中的对象集合包括在CA的存储库发布点发布的由此CA颁发的所有证书、由CA颁发的最新CRL，以及在此存储库发布点发布的由此CA颁发的EE证书验证的所有对象。
Note that the manifest does not include a self reference (i.e., its own file name and hash), since it would be impossible to compute the hash of the manifest itself prior to it being signed.
请注意，清单不包括自引用（即，它自己的文件名和散列），因为在签署清单之前，不可能计算清单本身的散列。
5. Encapsulate the manifest content using the CMS SignedData content type (as specified Section 4), sign the manifest using the private key corresponding to the subject key contained in the EE certificate, and publish the manifest in the repository system publication point that is described by the manifest.
5. 使用CMS SignedData内容类型（如第4节所述）封装清单内容，使用与EE证书中包含的主题密钥相对应的私钥对清单进行签名，并在清单描述的存储库系统发布点中发布清单。
6. In the case of a key pair that is to be used only once, in conjunction with a "one-time-use" EE certificate, the private key associated with this key pair MUST now be destroyed.
6. 对于仅使用一次的密钥对以及“一次性使用”EE证书，现在必须销毁与该密钥对关联的私钥。
A new manifest MUST be issued and published on or before the nextUpdate time.
必须在下一个日期或之前发布和发布新清单。
An authority MUST issue a new manifest in conjunction with the finalization of changes made to objects in the publication point. 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 repository update procedure that mitigates, to the extent possible, the risk that RPs that are performing retrieval operations on the repository are exposed to inconsistent, transient, intermediate states during updates to the repository publication point (directory) and the associated manifest.
权威机构必须在完成发布点中对象的更改时发布新清单。在发布涵盖此更改范围内所有操作的单一清单之前，授权机构可以在存储库更改范围内的发布存储库上执行多个对象操作。存储库操作员应实施某种形式的存储库更新过程，以尽可能降低在存储库上执行检索操作的RP在更新存储库发布点（目录）和相关清单期间暴露于不一致、暂时、中间状态的风险。
Since the manifest object URL is included in the SIA of issued certificates, a new manifest MUST NOT invalidate the manifest object URL of previously issued certificates. This implies that the manifest's publication name in the repository, in the form of an object URL, is unchanged across manifest generation cycles.
由于清单对象URL包含在已颁发证书的SIA中，因此新清单不得使以前颁发的证书的清单对象URL无效。这意味着存储库中清单的发布名称（以对象URL的形式）在清单生成周期中保持不变。
When a CA entity is performing a key rollover, the entity MAY choose to have two CA instances simultaneously publishing into the same repository publication point. In this case, there will be one manifest associated with each active CA instance that is publishing into the common repository publication point (directory).
当CA实体正在执行密钥滚动时，该实体可以选择让两个CA实例同时发布到同一存储库发布点。在这种情况下，将有一个清单与发布到公共存储库发布点（目录）的每个活动CA实例关联。
The goal of an RP is to determine which signed objects to use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters). Ultimately, this selection is a matter of local policy. However, in the following sections, we describe a sequence of tests that the RP SHOULD perform to determine the manifest state of the given publication point. We then discuss the risks associated with using signed objects in the publication point, given the manifest state; we also provide suitable warning text that SHOULD be placed in a user-accessible log file. It is the responsibility of the RP to weigh these risks against the risk of routing failure that could occur if valid data is rejected, and to implement a suitable local policy. Note that if a certificate is deemed unfit for use due to local policy, then any signed object that
RP的目标是确定使用哪些签名对象来验证关于INR及其使用的断言（例如，在构建路由过滤器时使用哪些ROA）。最终，这一选择取决于当地政策。然而，在下面的部分中，我们描述了RP应该执行的一系列测试，以确定给定发布点的清单状态。然后，我们讨论在给定清单状态的情况下，在发布点使用签名对象的相关风险；我们还提供了适当的警告文本，应该放在用户可访问的日志文件中。RP负责将这些风险与有效数据被拒绝时可能发生的路由故障风险进行权衡，并实施适当的本地策略。请注意，如果由于本地策略而认为证书不适合使用，则
is validated using this certificate also SHOULD be deemed unfit for use (regardless of the status of the manifest at its own publication point).
使用此证书验证的也应被视为不适合使用（无论清单在其自身发布点的状态如何）。
For a given publication point, the RP SHOULD perform the following tests to determine the manifest state of the publication point:
对于给定的发布点，RP应执行以下测试以确定发布点的清单状态：
1. For each CA using this publication point, select the CA's current manifest (the "current" manifest is the manifest issued by this CA having the highest manifestNumber among all valid manifests, and where manifest validity is defined in Section 4.4).
1. 对于使用此发布点的每个CA，选择CA的当前清单（“当前”清单是由该CA发布的清单，在所有有效清单中具有最高的manifestNumber，其中清单有效性在第4.4节中定义）。
If the publication point does not contain a valid manifest, see Section 6.2. Lacking a valid manifest, the following tests cannot be performed.
如果发布点不包含有效的清单，请参阅第6.2节。由于缺少有效的清单，无法执行以下测试。
2. To verify completeness, an RP MAY check that every file at each publication point appears in one and only one current manifest, and that every file listed in a current manifest is published at the same publication point as the manifest.
2. 为验证完整性，RP可检查每个发布点的每个文件是否显示在一个且仅显示在一个当前清单中，以及当前清单中列出的每个文件是否在与清单相同的发布点发布。
If there exist files at the publication point that do not appear on any manifest, or files listed in a manifest that do not appear at the publication point, then see Section 6.5, but still continue with the following test.
如果发布点存在未出现在任何清单上的文件，或者清单中列出的文件未出现在发布点，请参见第6.5节，但仍继续进行以下测试。
3. Check that the current time (translated to UTC) is between thisUpdate and nextUpdate.
3. 检查当前时间（转换为UTC）是否介于此更新和下一个更新日期之间。
If the current time does not lie within this interval, then see Section 6.4, but still continue with the following tests.
如果当前时间不在此间隔内，则参见第6.4节，但仍继续进行以下试验。
4. Verify that the listed hash value of every file listed in each manifest matches the value obtained by hashing the file at the publication point.
4. 验证每个清单中列出的每个文件的所列哈希值是否与在发布点对文件进行哈希处理获得的值匹配。
If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then see Section 6.6.
如果清单上列出的文件的计算哈希值与清单中包含的哈希值不匹配，请参阅第6.6节。
5. An RP MAY check that the contents of each current manifest conforms to the manifest's scope constraints, as specified in Section 2.
5. RP可以检查每个当前清单的内容是否符合清单的范围约束，如第2节所述。
6. If a current manifest contains entries for objects that are not within the scope of the manifest, then the out-of-scope entries
6. 如果当前清单包含不在清单范围内的对象的条目，则范围外条目
SHOULD be disregarded in the context of this manifest. If there is no other current manifest that describes these objects within that other manifest's scope, then see Section 6.2.
在本清单的上下文中应忽略。如果没有其他当前清单在该清单的范围内描述这些对象，请参阅第6.2节。
For each signed object, if all of the following conditions hold:
对于每个签名对象，如果满足以下所有条件：
* the manifest for its publication and the associated publication point pass all of the above checks;
* 其发布的清单和相关发布点通过了所有上述检查；
* the signed object is valid; and
* 签名对象有效；和
* the manifests for every certificate on the certification path used to validate the signed object and the associated publication points pass all of the above checks;
* 用于验证签名对象和关联发布点的证书路径上的每个证书的清单都通过了上述所有检查；
then the RP can conclude that no attack against the repository system has compromised the given signed object, and the signed object MUST be treated as valid (relative to manifest checking).
然后RP可以得出结论，对存储库系统的攻击没有损害给定的签名对象，并且签名对象必须被视为有效（相对于清单检查）。
The absence of a current manifest at a publication point could occur due to an error by the publisher or due to (malicious or accidental) deletion or corruption of all valid manifests.
发布点缺少当前清单可能是由于发布者出错或（恶意或意外）删除或损坏所有有效清单所致。
When no valid manifest is available, there is no protection against attacks that delete signed objects or replay old versions of signed objects. All signed objects at the publication point, and all descendant objects that are validated using a certificate at this publication point, SHOULD be viewed as suspect, but MAY be used by the RP, as per local policy.
如果没有可用的有效清单，则无法防止删除已签名对象或重播已签名对象的旧版本的攻击。发布点的所有签名对象以及在此发布点使用证书验证的所有子对象都应视为可疑对象，但RP可以根据本地策略使用这些对象。
The primary risk in using signed objects at this publication point is that a superseded (but not stale) CRL would cause an RP to improperly accept a revoked certificate as valid (and thus rely upon signed objects that are validated using that certificate). This risk is somewhat mitigated if the CRL for this publication point has a short time between thisUpdate and nextUpdate (and the current time is within this interval). The risk in discarding signed objects at this publication point is that an RP may incorrectly discard a large number of valid objects. This gives significant power to an adversary that is able to delete a manifest at the publication point.
在此发布点使用签名对象的主要风险是，被取代（但不过时）的CRL将导致RP不正确地接受已吊销的证书作为有效证书（从而依赖使用该证书验证的签名对象）。如果此发布点的CRL在此更新和下一次更新之间的时间很短（且当前时间在此时间间隔内），则此风险会有所缓解。在此发布点丢弃签名对象的风险在于RP可能会错误地丢弃大量有效对象。这为能够在发布点删除清单的对手提供了强大的力量。
Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that: "No manifest is available for <pub point name>, and thus there may have been undetected deletions or replay substitutions from the publication point."
无论此出版物中的签名对象是否被视为适合RP使用，这种情况都会导致警告：“没有<pub point name>的清单可用，因此可能存在未检测到的从发布点删除或重播替换。”
In the case where an RP has access to a local cache of previously issued manifests that are valid, the RP MAY use the most recently previously issued valid manifests for this RPKI repository publication collection for each entity that publishes at this publication point.
如果RP可以访问先前发布的有效清单的本地缓存，则RP可以为在此发布点发布的每个实体使用此RPKI存储库发布集合的最近发布的有效清单。
The presence of an invalid manifest at a publication point could occur due to an error by the publisher or due to (malicious or accidental) corruption of a valid manifest. An invalid manifest MUST never be used, even if the manifestNumber of the invalid manifest is greater than that of other (valid) manifests.
发布点出现无效清单可能是由于发布者出错或有效清单（恶意或意外）损坏所致。不得使用无效清单，即使无效清单的manifestNumber大于其他（有效）清单的manifestNumber。
There are no risks associated with using signed objects at a publication point containing an invalid manifest, provided that valid manifests that collectively cover all the signed objects are also present.
在包含无效清单的发布点使用已签名对象不存在任何风险，前提是还存在涵盖所有已签名对象的有效清单。
If an invalid manifest is present at a publication point that also contains one or more valid manifests, this situation SHOULD result in a warning to the effect that: "An invalid manifest was found at <pub point name>, this indicates an attack against the publication point or an error by the publisher. Processing for this publication point will continue using the most recent valid manifest(s)."
如果在还包含一个或多个有效清单的发布点上存在无效清单，则这种情况应导致警告，大意是：在<pub point name>处发现无效清单，这表示对发布点的攻击或发布者的错误。将使用最新的有效清单继续处理此发布点。“
In the case where the RP has access to a local cache of previously issued (valid) manifests, an RP MAY make use of that locally cached data. Specifically, the RP MAY use the locally cached, most recent, previously issued, valid manifest issued by the entity that (appears to have) issued the invalid manifest.
在RP可以访问先前发布（有效）舱单的本地缓存的情况下，RP可以使用该本地缓存的数据。具体而言，RP可以使用由（似乎已经）发布无效清单的实体发布的本地缓存的、最近的、先前发布的有效清单。
A manifest is considered stale if the current time is after the nextUpdate time for the manifest. This could be due to publisher failure to promptly publish a new manifest, or due to (malicious or accidental) corruption or suppression of a more recent manifest.
如果当前时间晚于清单的nextUpdate时间，则清单将被视为过时。这可能是由于发布者未能及时发布新清单，或由于（恶意或意外）损坏或抑制较新清单所致。
All signed objects at the publication point issued by the entity that has published the stale manifest, and all descendant signed objects that are validated using a certificate issued by the entity that has published the stale manifest at this publication point, SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy.
发布点上发布过时清单的实体发布的所有签名对象，以及使用该发布点上发布过时清单的实体发布的证书验证的所有子代签名对象，都应视为可疑对象，但RP可根据本地策略使用。
The primary risk in using such signed objects is that a newer manifest exists that, if present, would indicate that certain objects
使用此类已签名对象的主要风险是存在一个更新的清单，如果存在，将指示某些对象
have been removed or replaced. (For example, the new manifest might show the existence of a newer CRL and the removal of one or more revoked certificates). Thus, the use of objects from a stale manifest may cause an RP to incorrectly treat invalid objects as valid. The risk is that the CRL covered by the stale manifest has been superseded, and thus an RP will improperly treat a revoked certificate as valid. This risk is somewhat mitigated if the time between the nextUpdate field of the manifest and the current time is short. The risk in discarding signed objects at this publication point is that the RP may incorrectly discard a large number of valid objects. This gives significant power to an adversary that is able to prevent the publication of a new manifest at a given publication point.
已被移除或替换。（例如，新清单可能显示存在较新的CRL，并且删除了一个或多个已吊销的证书）。因此，使用过时清单中的对象可能会导致RP错误地将无效对象视为有效对象。风险在于过期舱单涵盖的CRL已被取代，因此RP将不正确地将吊销的证书视为有效。如果清单的nextUpdate字段与当前时间之间的时间较短，则此风险会有所缓解。在此发布点丢弃签名对象的风险在于RP可能会错误地丢弃大量有效对象。这为能够阻止在给定发布点发布新清单的对手提供了强大的力量。
Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that: "A manifest found at <pub point name> is no longer current. It is possible that undetected deletions have occurred at this publication point."
无论此发布中的签名对象是否适合RP使用，这种情况都会导致警告：“在<pub point name>找到的清单不再是最新的。可能在此发布点发生了未检测到的删除。”
Note that there is also the potential for the current time to be before the thisUpdate time for the manifest. This case could be due to publisher error or a local clock error; in such a case, this situation SHOULD result in a warning to the effect that: "A manifest found at <pub point name> has an incorrect thisUpdate field. This could be due to publisher error, or a local clock error, and processing for this publication point will continue using this otherwise valid manifest."
请注意，当前时间也可能早于清单的thisUpdate时间。这种情况可能是由于发布服务器错误或本地时钟错误造成的；在这种情况下，这种情况会导致警告：“在<pub point name>找到的清单具有不正确的thisUpdate字段。这可能是由于发布者错误或本地时钟错误，对此发布点的处理将继续使用此有效清单。”
If there exist valid signed objects that do not appear in any manifest, then, provided the manifest is not stale (see Section 6.4), it is likely that their omission is an error by the publisher. It is also possible that this state could be the result of a (malicious or accidental) replacement of a current manifest with an older, but still valid, manifest. However, regarding the appropriate interpretation of such objects, it remains the case that if the objects were intended to be invalid, then they should have been revoked using whatever revocation mechanism is appropriate for the signed object in question. Therefore, there is little risk in using such signed objects. If the publication point contains a stale manifest, then there is a greater risk that the objects in question were revoked, along with a missing Certificate Revocation List (CRL), the absence of which is undetectable since the manifest is stale. In any case, the use of signed objects not present on a manifest, or descendant objects that are validated using such signed objects, is a matter of local policy.
如果存在未出现在任何清单中的有效已签名对象，那么，如果清单未过期（请参阅第6.4节），则其遗漏很可能是发布者的错误。这种状态也可能是（恶意或意外）用旧但仍然有效的清单替换当前清单的结果。然而，关于对这些对象的适当解释，仍然存在这样的情况，即如果这些对象的意图是无效的，则应使用适用于所述签名对象的任何撤销机制撤销这些对象。因此，使用此类签名对象的风险很小。如果发布点包含过时的清单，则存在更大的风险，即相关对象被吊销，以及缺少证书吊销列表（CRL），因为清单已过时，因此无法检测到缺少该列表。在任何情况下，使用清单上不存在的已签名对象，或使用此类已签名对象验证的后代对象，都是本地策略的问题。
Regardless of whether objects not appearing on a manifest are deemed
fit for use by the RP, this situation SHOULD result in a warning to
the effect that: "The following files are present in the repository
at <pub point name>, but are not listed on any manifest <file list>
for <pub point name>."
Regardless of whether objects not appearing on a manifest are deemed
fit for use by the RP, this situation SHOULD result in a warning to
the effect that: "The following files are present in the repository
at <pub point name>, but are not listed on any manifest <file list>
for <pub point name>."
If there exists files listed on the manifest that do not appear in the repository, then these objects are likely to have been improperly (via malice or accident) deleted from the repository. A primary purpose of manifests is to detect such deletions. Therefore, in such a case, this situation SHOULD result in a warning to the effect that: "The following files that should have been present in the repository at <pub point name> are missing <file list>. This indicates an attack against this publication point, or the repository, or an error by the publisher."
如果清单上列出的文件未出现在存储库中，则这些对象可能已从存储库中不正确地删除（通过恶意或意外）。清单的主要目的是检测此类删除。因此，在这种情况下，这种情况会导致警告：“存储库中<pub point name>处本应存在的以下文件丢失<file list>。这表示对该发布点或存储库的攻击，或发布者的错误。”
A file appearing on a manifest with an incorrect hash value could occur because of publisher error, but it also may indicate that an attack has occurred.
由于发布者错误，可能会出现清单上显示的哈希值不正确的文件，但也可能表明发生了攻击。
If an object appeared on a previous valid manifest with a correct hash value, and it now appears with an invalid hash value, then it is likely that the object has been superseded by a new (unavailable) version of the object. If the object is used, there is a risk that the RP will be treating a stale object as valid. This risk is more significant if the object in question is a CRL. If the object can be validated using the RPKI, the use of these objects is a matter of local policy.
如果一个对象以正确的哈希值出现在以前的有效清单上，而现在以无效的哈希值出现，则该对象可能已被该对象的新（不可用）版本所取代。如果使用该对象，则RP可能会将陈旧对象视为有效对象。如果所讨论的对象是CRL，则该风险更大。如果可以使用RPKI验证对象，则这些对象的使用取决于本地策略。
If an object appears on a manifest with an invalid hash and has never previously appeared on a manifest, then it is unclear whether the available version of the object is more or less recent than the version indicated by the manifest. If the manifest is stale (see Section 6.4), then it becomes more likely that the available version is more recent than the version indicated on the manifest, but this is never certain. Whether to use such objects is a matter of local policy. However, in general, it is better to use a possibly outdated version of the object than to discard the object completely.
如果某个对象出现在清单上，且散列无效，并且以前从未出现在清单上，则不清楚该对象的可用版本是否比清单指示的版本更新。如果清单已过时（见第6.4节），则可用版本更有可能比清单上指示的版本更新，但这永远无法确定。是否使用这些对象是本地政策的问题。但是，一般来说，使用可能过时的对象版本比完全丢弃对象要好。
While it is a matter of local policy, in the case of CRLs, an RP SHOULD endeavor to use the most recently issued valid CRL, even where the hash value in the manifest matches an older CRL or does not match any available CRL for a CA instance. The thisUpdate field of the CRL can be used to establish the most recent CRL in the case where an RP has more than one valid CRL for a CA instance.
虽然这是本地策略的问题，但在CRL的情况下，RP应尽量使用最近发布的有效CRL，即使清单中的哈希值与旧CRL匹配或与CA实例的任何可用CRL不匹配。当RP对CA实例有多个有效CRL时，CRL的thisUpdate字段可用于建立最新的CRL。
Regardless of whether objects with incorrect hashes are deemed fit for use by the RP, this situation SHOULD result in a warning to the effect that: "The following files at the repository <pub point name> appear on a manifest with incorrect hash values <file list>. It is possible that these objects have been superseded by a more recent version. It is very likely that this problem is due to an attack on the publication point, although it also could be due to a publisher error."
无论是否认为具有不正确哈希的对象适合RP使用，这种情况都会导致警告，大意是：“存储库<pub point name>中的以下文件显示在清单上，其哈希值不正确<file list>。这些对象可能已被较新版本取代。此问题很可能是由于对发布点的攻击造成的，但也可能是由于发布者错误造成的。”
The RPKI publication system model requires that every publication point be associated with one or more CAs, and be non-empty. Upon creation of the publication point associated with a CA, the CA MUST create and publish a manifest as well as a CRL. A CA's manifest will always contain at least one entry, namely, the CRL issued by the CA upon repository creation [RFC6481].
RPKI发布系统模型要求每个发布点都与一个或多个CA关联，并且不为空。在创建与CA关联的发布点时，CA必须创建并发布清单和CRL。CA的清单将始终包含至少一个条目，即CA在创建存储库时发布的CRL[RFC6481]。
Every published signed object in the RPKI [RFC6488] is published in the repository publication point of the CA that issued the EE certificate, and is listed in the manifest associated with that CA certificate.
RPKI[RFC6488]中每个已发布的签名对象都在颁发EE证书的CA的存储库发布点中发布，并在与该CA证书关联的清单中列出。
Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RP to determine if a repository object has been deleted, occluded, or otherwise removed from view, or if a publication of a newer version of an object has been suppressed (and an older version of the object has been substituted).
清单为RPKI RPs提供了额外的保护级别。清单可以帮助RP确定存储库对象是否已被删除、阻止或从视图中移除，或者是否已禁止发布较新版本的对象（并且替换了较旧版本的对象）。
Manifests cannot repair the effects of such forms of corruption of repository retrieval operations. However, a manifest enables an RP to determine if a locally maintained copy of a repository is a complete and up-to-date copy, even when the repository retrieval operation is conducted over an insecure channel. In cases where the manifest and the retrieved repository contents differ, the manifest can assist in determining which repository objects form the difference set in terms of missing, extraneous, or superseded objects.
清单无法修复存储库检索操作的此类损坏形式的影响。但是，清单使RP能够确定本地维护的存储库副本是否是完整的最新副本，即使存储库检索操作是通过不安全的通道进行的。在清单和检索到的存储库内容不同的情况下，清单可以帮助确定哪些存储库对象在缺少、无关或被替代的对象方面形成差异集。
The signing structure of a manifest and the use of the nextUpdate value allows an RP to determine if the manifest itself is the subject of attempted alteration. The requirement for every repository publication point to contain at least one manifest allows an RP to determine if the manifest itself has been occluded from view. Such attacks against the manifest are detectable within the time frame of the regular schedule of manifest updates. Forms of replay attack
清单的签名结构和nextUpdate值的使用允许RP确定清单本身是否是试图更改的对象。每个存储库发布点至少包含一个清单的要求允许RP确定清单本身是否已被阻挡在视图之外。此类针对清单的攻击可在定期清单更新时间表的时间范围内检测到。重放攻击的形式
within finer-grained time frames are not necessarily detectable by the manifest structure.
在细粒度的时间范围内，清单结构不一定能检测到。
This document registers the following in the "RPKI Signed Object" registry created by [RFC6488]:
本文档在[RFC6488]创建的“RPKI签名对象”注册表中注册以下内容：
Name: Manifest OID: 1.2.840.113549.1.9.16.1.26 Reference: [RFC6486] (this document)
名称：清单OID:1.2.840.113549.1.9.16.1.26参考：[RFC6486]（本文件）
This document registers the following three-letter filename extension for "RPKI Repository Name Schemes" registry created by [RFC6481]:
本文档为[RFC6481]创建的“RPKI存储库名称方案”注册表注册以下三个字母的文件扩展名：
Filename extension: mft RPKI Object: Manifest Reference: [RFC6481]
文件扩展名：mft RPKI对象：清单引用：[RFC6481]
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. The authors also wish to thank Sean Turner for his helpful review of this document.
作者希望感谢George Michelson和Randy Bush在清单规范编制过程中所做的贡献。此外，作者还要感谢Mark Reynolds和Christopher Small在澄清清单验证和RP行为方面提供的帮助。作者还要感谢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月。
[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月。
[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月。
[RFC6485] Huston, G., "A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485]Huston，G.“用于资源公钥基础设施（RPKI）的算法和密钥大小的配置文件”，RFC 6485，2012年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月。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[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月。
[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月。
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
-- IMPORTS NOTHING --
--什么也不进口--
-- Manifest Content Type: OID
--清单内容类型：OID
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
-- Manifest Content Type: eContent
--清单内容类型：eContent
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
终止
Authors' Addresses
作者地址
Rob Austein Internet Systems Consortium
Rob Austein互联网系统联合会
EMail: sra@hactrn.net
EMail: sra@hactrn.net
Geoff Huston APNIC 6 Cordelia St South Brisbane, QLD 4101 Australia
澳大利亚昆士兰州南布里斯班科迪利亚街6号杰夫休斯顿APNIC 4101
EMail: gih@apnic.net
URI: http://www.apnic.net
EMail: gih@apnic.net
URI: http://www.apnic.net
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Stephen Kent BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: kent@bbn.com
EMail: kent@bbn.com
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Matt Lepinski BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: mlepinski@bbn.com
EMail: mlepinski@bbn.com