Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6488 A. Chi
Category: Standards Track S. Kent
ISSN: 2070-1721 BBN
February 2012
Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6488 A. Chi
Category: Standards Track S. Kent
ISSN: 2070-1721 BBN
February 2012
Signed Object Template for the Resource Public Key Infrastructure (RPKI)
资源公钥基础结构（RPKI）的签名对象模板
Abstract
摘要
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format.
本文档为资源公钥基础结构（RPKI）中使用的已签名对象定义了通用配置文件。这些RPKI签名对象使用加密消息语法（CMS）作为标准封装格式。
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/rfc6488.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6488.
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 ....................................................2
1.1. Terminology ................................................3
1.2. Note on Algorithms .........................................3
2. Signed Object Syntax ............................................3
2.1. Signed-Data Content Type ...................................4
2.1.1. version .............................................4
2.1.2. digestAlgorithms ....................................4
2.1.3. encapContentInfo ....................................4
2.1.3.1. eContentType ...............................5
2.1.3.2. eContent ...................................5
2.1.4. certificates ........................................5
2.1.5. crls ................................................5
2.1.6. signerInfos .........................................5
2.1.6.1. version ....................................6
2.1.6.2. sid ........................................6
2.1.6.3. digestAlgorithm ............................6
2.1.6.4. signedAttrs ................................6
2.1.6.4.1. Content-Type Attribute ..........7
2.1.6.4.2. Message-Digest Attribute ........7
2.1.6.4.3. Signing-Time Attribute ..........7
2.1.6.4.4. Binary-Signing-Time Attribute ...8
2.1.6.5. signatureAlgorithm .........................8
2.1.6.6. signatureValue .............................8
2.1.6.7. unsigneAttrs ...............................8
3. Signed Object Validation ........................................8
4. Definition of Specific Signed Objects ..........................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
7. Acknowledgements ...............................................11
8. Normative References ...........................................11
9. Informative References .........................................12
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Note on Algorithms .........................................3
2. Signed Object Syntax ............................................3
2.1. Signed-Data Content Type ...................................4
2.1.1. version .............................................4
2.1.2. digestAlgorithms ....................................4
2.1.3. encapContentInfo ....................................4
2.1.3.1. eContentType ...............................5
2.1.3.2. eContent ...................................5
2.1.4. certificates ........................................5
2.1.5. crls ................................................5
2.1.6. signerInfos .........................................5
2.1.6.1. version ....................................6
2.1.6.2. sid ........................................6
2.1.6.3. digestAlgorithm ............................6
2.1.6.4. signedAttrs ................................6
2.1.6.4.1. Content-Type Attribute ..........7
2.1.6.4.2. Message-Digest Attribute ........7
2.1.6.4.3. Signing-Time Attribute ..........7
2.1.6.4.4. Binary-Signing-Time Attribute ...8
2.1.6.5. signatureAlgorithm .........................8
2.1.6.6. signatureValue .............................8
2.1.6.7. unsigneAttrs ...............................8
3. Signed Object Validation ........................................8
4. Definition of Specific Signed Objects ..........................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
7. Acknowledgements ...............................................11
8. Normative References ...........................................11
9. Informative References .........................................12
The purpose of the Resource Public Key Infrastructure (RPKI) is to support assertions by current resource holders of IP (v4 and v6) address space and AS numbers, based on the records of organizations that act as Certification Authorities (CAs). IP address and AS number resource information is carried in X.509 certificates via RFC 3779 extensions [RFC6487]. Other information assertions about resources are expressed via digitally signed, non-X.509 data structures that are referred to as "signed objects" in the RPKI context [RFC6480]. This document standardizes a template for specifying signed objects that can be validated using the RPKI.
资源公钥基础设施（RPKI）的目的是支持IP（v4和v6）地址空间和AS编号的当前资源持有者根据充当证书颁发机构（CA）的组织的记录进行断言。IP地址和AS号资源信息通过RFC 3779扩展[RFC6487]在X.509证书中携带。关于资源的其他信息断言通过数字签名的非X.509数据结构表示，这些数据结构在RPKI上下文中称为“签名对象”[RFC6480]。本文档标准化了用于指定可使用RPKI验证的签名对象的模板。
RPKI signed objects make use of Cryptographic Message Syntax (CMS) [RFC5652] as a standard encapsulation format. CMS was chosen to take advantage of existing open source software available for processing messages in this format. RPKI signed objects adhere to a profile (specified in Section 2) of the CMS signed-data object.
RPKI签名对象使用加密消息语法（CMS）[RFC5652]作为标准封装格式。选择CMS是为了利用现有的开源软件来处理这种格式的消息。RPKI签名对象遵循CMS签名数据对象的配置文件（在第2节中指定）。
The template defined in this document for RPKI signed objects is not a complete specification for any particular type of signed object, and instead includes only the items that are common to all RPKI signed objects. That is, fully specifying a particular type of signed object requires an additional document that specifies the details specific to a particular type of signed object. Such details include Abstract Syntax Notation One (ASN.1) [X.208-88] for the object's payload and any additional steps required to validate the particular type of signed object. Section 4 describes in more detail the additional pieces that must be specified in order to define a new type of RPKI signed object that uses this template. Additionally, see [RFC6482] for an example of a document that uses this template to specify a particular type of signed object, the Route Origination Authorization (ROA).
本文档中为RPKI签名对象定义的模板不是任何特定类型签名对象的完整规范，而是仅包括所有RPKI签名对象的通用项。也就是说，完全指定特定类型的签名对象需要额外的文档来指定特定类型的签名对象的详细信息。这些细节包括对象有效载荷的抽象语法符号1（ASN.1）[X.208-88]，以及验证特定类型的签名对象所需的任何附加步骤。第4节更详细地描述了为定义使用此模板的新类型的RPKI签名对象而必须指定的其他部分。此外，有关使用此模板指定特定类型的签名对象（路由发起授权（ROA））的文档示例，请参见[RFC6482]。
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], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "Cryptographic Message Syntax (CMS)" [RFC5652].
假设读者熟悉“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件”[RFC5280]、“IP地址和AS标识符的X.509扩展”[RFC3779]和“加密消息语法（CMS）”[RFC5652]中描述的术语和概念。
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]中所述进行解释。
CMS is a general format capable of accommodating a wide variety of signature and digest algorithms. The algorithms used in the RPKI (and associated key sizes) are specified in [RFC6485].
CMS是一种通用格式，能够容纳多种签名和摘要算法。[RFC6485]中规定了RPKI中使用的算法（以及相关的密钥大小）。
The RPKI signed object is a profile of the CMS [RFC5652] signed-data object, with the restriction that RPKI signed objects MUST be encoded using the ASN.1 Distinguished Encoding Rules (DER) [X.509-88].
RPKI签名对象是CMS[RFC5652]签名数据对象的配置文件，限制RPKI签名对象必须使用ASN.1可分辨编码规则（DER）[X.509-88]进行编码。
The general format of a CMS object is:
CMS对象的一般格式为：
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The content-type is the signed-data type of id-data, namely the id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.
内容类型是id数据的签名数据类型，即id signedData OID[RFC5652]，1.2.840.113549.1.7.2。
According to the CMS standard, the signed-data content type is the ASN.1 type SignedData:
根据CMS标准，签名数据内容类型为ASN.1类型签名数据：
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
SignerInfos ::= SET OF SignerInfo
Additionally, the SignerInfos set MUST contain only a single SignerInfo object.
此外，SignerInfos集必须仅包含一个SignerInfo对象。
The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
版本是语法版本号。它必须是3，对应于版本号为3的signerInfo结构。
The digestAlgorithms set contains the OIDs of the digest algorithm(s) used in signing the encapsulated content. This set MUST contain exactly one digest algorithm OID, and the OID MUST be selected from those specified in [RFC6485].
digestAlgorithms集包含用于对封装内容进行签名的摘要算法的OID。此集合必须仅包含一个摘要算法OID，并且OID必须从[RFC6485]中指定的OID中选择。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself. The encapContentInfo represents the payload of the RPKI signed object.
encapContentInfo是已签名的内容，由内容类型标识符和内容本身组成。encapContentInfo表示RPKI签名对象的有效负载。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
This field is left undefined by this profile. The eContentType is an OID specifying the type of payload in this signed object and MUST be specified by the Internet Standards Track document that defines the object.
此配置文件未定义此字段。eContentType是一个OID，用于指定此签名对象中的有效负载类型，必须由定义该对象的Internet标准跟踪文档指定。
This field is left undefined by this profile. The eContent is the payload of the signed object and MUST be specified by the Internet Standards Track document that defines the RPKI object.
此配置文件未定义此字段。eContent是已签名对象的有效负载，必须由定义RPKI对象的Internet标准跟踪文档指定。
Note that the signed object profile does not provide version numbers for signed objects. Therefore, in order to facilitate transition to new versions of the signed objects over time, it is RECOMMENDED that each type of signed object defined using this profile include a version number within its eContent.
请注意，签名对象配置文件不提供签名对象的版本号。因此，为了便于随着时间的推移转换到签名对象的新版本，建议使用此配置文件定义的每种类型的签名对象在其eContent中包含一个版本号。
The certificates field MUST be included, and MUST contain exactly one certificate, the RPKI end-entity (EE) certificate needed to validate this signed object.
“证书”字段必须包含，并且必须仅包含一个证书，即验证此签名对象所需的RPKI终端实体（EE）证书。
The crls field MUST be omitted.
必须省略crls字段。
SignerInfo is defined in CMS as:
签名信息在CMS中定义为：
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid.
版本号必须为3，与sid的SubjectKeyIdentifier选项相对应。
The sid is defined as:
sid定义为：
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
对于RPKI签名的对象，sid必须是出现在CMS证书字段中的EE证书中的SubjectKeyIdentifier。
The digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
摘要算法必须由符合RPKI算法和密钥大小配置文件规范[RFC6485]的摘要算法的OID组成。
The signedAttrs is defined as:
已签署的交易记录被定义为：
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
AttributeValue ::= ANY
The signedAttrs element MUST be present and MUST include the content-type and message-digest attributes [RFC5652]. The signer MAY also include the signing-time attribute [RFC5652], the binary-signing-time attribute [RFC6019], or both attributes. Other signed attributes MUST NOT be included.
signedAttrs元素必须存在，并且必须包含内容类型和消息摘要属性[RFC5652]。签名者还可以包括签名时间属性[RFC5652]、二进制签名时间属性[RFC6019]或这两个属性。不得包括其他已签名属性。
The signedAttrs element MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in an RPKI signed object, the attrValues MUST consist of only a single AttributeValue.
signedAttrs元素必须只包含任何特定属性的单个实例。此外，即使语法允许一组AttributeValue，但在RPKI签名对象中，AttrValue必须只包含一个AttributeValue。
The content-type attribute MUST be present. The attrType OID for the content-type attribute is 1.2.840.113549.1.9.3.
内容类型属性必须存在。内容类型属性的attrType OID为1.2.840.113549.1.9.3。
The attrValues for the content-type attribute MUST match the eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST contain the OID that specifies the payload type of the specific RPKI signed object carried in the CMS signed data structure.
content type属性的属性值必须与封装的ContentInfo中的eContentType匹配。因此，属性值必须包含OID，该OID指定CMS签名数据结构中携带的特定RPKI签名对象的有效负载类型。
The message-digest attribute MUST be present. The attrType OID for the message-digest attribute is 1.2.840.113549.1.9.4.
消息摘要属性必须存在。消息摘要属性的属性类型OID为1.2.840.113549.1.9.4。
The attrValues for the message-digest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 5.4 of [RFC5652].
消息摘要属性的属性值包含应用于被签名内容的摘要算法的输出，如[RFC5652]第5.4节所述。
The signing-time attribute MAY be present. Note that the presence or absence of the signing-time attribute MUST NOT affect the validity of the signed object (as specified in Section 3). The attrType OID for the signing-time attribute is 1.2.840.113549.1.9.5.
签名时间属性可能存在。请注意，签名时间属性的存在或不存在不得影响已签名对象的有效性（如第3节所述）。签名时间属性的属性类型OID为1.2.840.113549.1.9.5。
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
The attrValues for the signing-time attribute is defined as:
签名时间属性的属性值定义为：
SigningTime ::= Time
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content.
Time元素基于本地系统时钟指定将数字签名应用于内容的时间。
The definition of Time matches the one specified in the 1997 version of X.509. Additional information regarding the use of UTCTime and GeneralizedTime can be found in [RFC5652].
时间的定义与1997年版本的X.509中指定的定义相匹配。有关UTCTime和GeneratedTime使用的更多信息，请参见[RFC5652]。
The binary-signing-time attribute MAY be present. Note that the presence or absence of the binary-signing-time attribute MUST NOT affect the validity of the signed object (as specified in Section 3). The attrType OID for the binary-signing-time attribute is 1.2.840.113549.1.9.16.2.46.
可能存在二进制签名时间属性。请注意，二进制签名时间属性的存在或不存在不得影响已签名对象的有效性（如第3节所述）。二进制签名时间属性的attrType OID为1.2.840.113549.1.9.16.2.46。
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
The attrValues for the signing-time attribute is defined as:
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
The attrValues for the signing-time attribute is defined as:
BinarySigningTime ::= BinaryTime
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
BinaryTime ::= INTEGER (0..MAX)
The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. The precise definition of the BinaryTime element can be found in [RFC6019].
BinaryTime元素根据本地系统时钟指定将数字签名应用于内容的时间。BinaryTime元素的精确定义见[RFC6019]。
The signatureAlgorithm MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC6485].
签名算法必须符合RPKI算法和密钥大小配置文件规范[RFC6485]。
The signature value is defined as:
签名值定义为：
SignatureValue ::= OCTET STRING
SignatureValue ::= OCTET STRING
The signature characteristics are defined by the digest and signature algorithms.
签名特征由摘要和签名算法定义。
unsignedAttrs MUST be omitted.
必须省略未签名的TTR。
Before a relying party can use a signed object, the relying party MUST validate the signed object by verifying that all of the following conditions hold. A relying party may perform these checks in any order. Note that these checks are necessary, but not sufficient. In general, further validation MUST be performed based on the specific type of signed object.
在依赖方可以使用签名对象之前，依赖方必须通过验证以下所有条件是否成立来验证签名对象。依赖方可按任何顺序执行这些检查。请注意，这些检查是必要的，但还不够。通常，必须根据签名对象的特定类型执行进一步的验证。
1. The signed object syntax complies with this specification. In particular, each of the following is true:
1. 签名对象语法符合此规范。特别是，以下各项都是正确的：
a. The content-type of the CMS object is SignedData (OID 1.2.840.113549.1.7.2)
a. CMS对象的内容类型为SignedData（OID 1.2.840.113549.1.7.2）
b. The version of the SignedData object is 3.
b. SignedData对象的版本为3。
c. The certificates field in the SignedData object is present and contains one EE certificate, the SubjectKeyIdentifier field of which matches the sid field of the SignerInfo object.
c. SignedData对象中的certificates字段存在并包含一个EE证书，其SubjectKeyIdentifier字段与SignerInfo对象的sid字段匹配。
d. The crls field in the SignedData object is omitted.
d. 忽略SignedData对象中的crls字段。
e. The version of the SignerInfo is 3.
e. 签名信息的版本为3。
f. The signedAttrs field in the SignerInfo object is present and contains both the content-type attribute (OID 1.2.840.113549.1.9.3) and the message-digest attribute (OID 1.2.840.113549.1.9.4).
f. SignerInfo对象中的signedAttrs字段存在，并且包含内容类型属性（OID 1.2.840.113549.1.9.3）和消息摘要属性（OID 1.2.840.113549.1.9.4）。
g. The signedAttrs field in the SignerInfo object does not contain any attributes other than the following four: the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), the signing-time attribute (OID 1.2.840.113549.1.9.5), and the binary-signing-time attribute (OID 1.2.840.113549.1.9.16.2.46). Note that the signing-time and binary-signing-time attributes MAY be present, but they are not required.
g. SignerInfo对象中的signedAttrs字段不包含除以下四个属性以外的任何属性：内容类型属性（OID 1.2.840.113549.1.9.3）、消息摘要属性（OID 1.2.840.113549.1.9.4）、签名时间属性（OID 1.2.840.113549.1.9.5）和二进制签名时间属性（OID 1.2.840.113549.1.9.16.46）。请注意，签名时间和二进制签名时间属性可能存在，但不是必需的。
h. The eContentType in the EncapsulatedContentInfo is an OID that matches the attrValues in the content-type attribute.
h. 封装的ContentInfo中的eContentType是与content type属性中的AttrValue匹配的OID。
i. The unsignedAttrs field in the SignerInfo object is omitted.
i. SignerInfo对象中的unsignedAttrs字段被省略。
j. The digestAlgorithm in the SignedData and SignerInfo objects conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
j. SignedData和SignerInfo对象中的digestAlgorithm符合RPKI算法和密钥大小配置文件规范[RFC6485]。
k. The signatureAlgorithm in the SignerInfo object conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
k. SignerInfo对象中的signatureAlgorithm符合RPKI算法和密钥大小配置文件规范[RFC6485]。
l. The signed object is DER encoded.
l. 签名对象是DER编码的。
2. The public key of the EE certificate (contained within the CMS signed-data object) can be used to successfully verify the signature on the signed object.
2. EE证书的公钥（包含在CMS签名数据对象中）可用于成功验证签名对象上的签名。
3. The EE certificate (contained within the CMS signed-data object) is a valid EE certificate in the RPKI as specified by [RFC6487]. In particular, a valid certification path from a trust anchor to this EE certificate exists.
3. EE证书（包含在CMS签名数据对象中）是[RFC6487]指定的RPKI中的有效EE证书。特别是，存在从信任锚点到此EE证书的有效证书路径。
If the above procedure indicates that the signed object is invalid, then the signed object MUST be discarded and treated as though no signed object were present. If all of the conditions above are true, then the signed object may be valid. The relying party MUST then perform any additional validation steps required for the particular type of signed object.
如果上述过程表明已签名对象无效，则必须丢弃已签名对象，并将其视为不存在已签名对象。如果上述所有条件均为真，则签名对象可能有效。然后，依赖方必须执行特定类型的签名对象所需的任何其他验证步骤。
Note that a previously valid signed object will cease to be valid when the associated EE certificate ceases to be valid (for example, when the end of the certificate's validity period is reached, or when the certificate is revoked by the authority that issued it). See [RFC6487] for a complete specification of resource certificate validity.
请注意，当关联的EE证书不再有效时（例如，当证书的有效期结束时，或当颁发证书的机构撤销证书时），以前有效的签名对象将不再有效。有关资源证书有效性的完整规范，请参见[RFC6487]。
Each RPKI signed object MUST be defined in an Internet Standards Track document based on this profile, by specifying the following data elements and validation procedure:
必须通过指定以下数据元素和验证程序，在基于此配置文件的Internet标准跟踪文档中定义每个RPKI签名对象：
1. eContentType: A single OID to be used for both the eContentType field and the content-type attribute. This OID uniquely identifies the type of signed object.
1. eContentType：用于eContentType字段和内容类型属性的单个OID。此OID唯一标识已签名对象的类型。
2. eContent: Define the syntax for the eContent field in encapContentInfo. This is the payload that contains the data specific to a given type of signed object.
2. eContent：定义encapContentInfo中eContent字段的语法。这是包含特定于给定类型的签名对象的数据的有效负载。
3. Additional Validation: Define a set of additional validation steps for the specific signed object. Before using this specific signed object, a relying party MUST perform both the generic validation steps in Section 3 above, as well as these additional steps.
3. 附加验证：为特定签名对象定义一组附加验证步骤。在使用此特定签名对象之前，依赖方必须执行上述第3节中的通用验证步骤以及这些附加步骤。
There is no assumption of confidentiality for the data in an RPKI signed object. The integrity and authenticity of each signed object is based on the verification of the object's digital signature, and
RPKI签名对象中的数据不存在保密性假设。每个签名对象的完整性和真实性基于对象数字签名的验证，以及
the validation of the EE certificate used to perform that verification. It is anticipated that signed objects will be stored in repositories that will be publicly accessible.
用于执行该验证的EE证书的验证。预计签名对象将存储在可公开访问的存储库中。
Since RPKI signed objects make use of CMS as an encapsulation format, the security considerations for CMS apply [RFC5652].
由于RPKI签名对象使用CMS作为封装格式，CMS的安全注意事项适用[RFC5652]。
IANA has created a registry of "RPKI Signed Objects" types that utilize the template defined in this document. This registry contains three fields: an informal name for the signed object, the OID for the eContentType of the signed object, and a specification pointer that references the RFC in which the signed object is specified. The entries in this registry are managed by IETF Standards Action.
IANA已经创建了一个“RPKI签名对象”类型的注册表，该注册表使用本文档中定义的模板。此注册表包含三个字段：签名对象的非正式名称、签名对象的eContentType的OID以及引用指定签名对象的RFC的规范指针。此注册表中的条目由IETF标准行动管理。
The registry has been initially populated with the following two entries.
注册表最初已填充以下两个条目。
Name | OID | Specification
----------------------------------------------------------------
ROA | 1.2.840.113549.1.9.16.1.24 | RFC 6482
Manifest | 1.2.840.113549.1.9.16.1.26 | RFC 6486
Name | OID | Specification
----------------------------------------------------------------
ROA | 1.2.840.113549.1.9.16.1.24 | RFC 6482
Manifest | 1.2.840.113549.1.9.16.1.26 | RFC 6486
The authors wish to thank Charles Gardiner, Russ Housley, and Derek Kong for their help and contributions. Additionally, the authors would like to thank Rob Austein, Roque Gagliano, Danny McPherson, Sean Turner, and Sam Weiler for their careful reviews and helpful comments.
作者希望感谢查尔斯·加德纳、罗斯·霍斯利和德里克·孔的帮助和贡献。此外，作者还要感谢Rob Austein、Roque Gagliano、Danny McPherson、Sean Turner和Sam Weiler的仔细评论和有益的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC6485] Huston, G., "The 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月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号一的规范（ASN.1），1988年。
[X.509-88] CCITT. Recommendation X.509: The Directory Authentication Framework, 1988.
[X.509-88]CCITT。建议X.509：目录认证框架，1988年。
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, September 2010.
[RFC6019]Housley，R.，“二进制时间：在ASN.1中表示日期和时间的替代格式”，RFC 6019，2010年9月。
[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月。
[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月。
Authors' Addresses
作者地址
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138
Matt Lepinski BBN Technologies马萨诸塞州剑桥莫尔顿街10号02138
EMail: mlepinski@bbn.com
EMail: mlepinski@bbn.com
Andrew Chi BBN Technologies 10 Moulton Street Cambridge MA 02138
马萨诸塞州剑桥莫尔顿街10号Andrew Chi BBN Technologies 02138
EMail: achi@bbn.com
EMail: achi@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138
马萨诸塞州剑桥莫尔顿街10号Stephen Kent BBN Technologies 02138
EMail: kent@bbn.com
EMail: kent@bbn.com