Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6492 R. Loomans
Category: Standards Track B. Ellacott
ISSN: 2070-1721 APNIC
R. Austein
ISC
February 2012
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6492 R. Loomans
Category: Standards Track B. Ellacott
ISSN: 2070-1721 APNIC
R. Austein
ISC
February 2012
A Protocol for Provisioning Resource Certificates
提供资源证书的协议
Abstract
摘要
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework.
本文件通过双方交互协议的规范，定义了互联网号码资源颁发者（“颁发者”）和互联网号码资源接收者（“主体”）之间的证书管理交互框架。该协议支持传输来自主体的请求，以及来自颁发者的相应响应，包括证书颁发、证书撤销和证书状态信息报告的操作。本协议仅限于Internet号码资源证书管理的应用，不作为更通用的证书管理框架的一部分使用。
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/rfc6492.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6492.
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. Scope ...........................................................4
3. Protocol Specification ..........................................4
3.1. CMS Profile ................................................5
3.1.1. SignedData Content Type .............................5
3.1.2. CMS Object Validation ..............................10
3.1.3. ASN.1 Specification of the CMS Signed Object .......12
3.2. Common Message Format .....................................14
3.3. Control - Resource Class Query ............................16
3.3.1. Resource Class List Query ..........................16
3.3.2. Resource Class List Response .......................17
3.4. CA - Certificate Issuance .................................21
3.4.1. Certificate Issuance Request .......................21
3.4.2. Certificate Issuance Response ......................24
3.5. Certificate Revocation ....................................24
3.5.1. Certificate Revocation Request .....................25
3.5.2. Certificate Revocation Response ....................26
3.6. Request-Not-Performed Response ............................26
3.7. XML Schema ................................................27
4. Security Considerations ........................................29
5. IANA Considerations ............................................30
5.1. application/rpki-updown ...................................30
6. Acknowledgements ...............................................30
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Scope ...........................................................4
3. Protocol Specification ..........................................4
3.1. CMS Profile ................................................5
3.1.1. SignedData Content Type .............................5
3.1.2. CMS Object Validation ..............................10
3.1.3. ASN.1 Specification of the CMS Signed Object .......12
3.2. Common Message Format .....................................14
3.3. Control - Resource Class Query ............................16
3.3.1. Resource Class List Query ..........................16
3.3.2. Resource Class List Response .......................17
3.4. CA - Certificate Issuance .................................21
3.4.1. Certificate Issuance Request .......................21
3.4.2. Certificate Issuance Response ......................24
3.5. Certificate Revocation ....................................24
3.5.1. Certificate Revocation Request .....................25
3.5.2. Certificate Revocation Response ....................26
3.6. Request-Not-Performed Response ............................26
3.7. XML Schema ................................................27
4. Security Considerations ........................................29
5. IANA Considerations ............................................30
5.1. application/rpki-updown ...................................30
6. Acknowledgements ...............................................30
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource certificate management and is not intended to be used as part of a more general certificate management framework.
本文件通过双方交互协议的规范，定义了互联网号码资源颁发者（“颁发者”）和互联网号码资源接收者（“主体”）之间的证书管理交互框架。该协议支持传输来自主体的请求，以及来自颁发者的相应响应，包括证书颁发、证书撤销和证书状态信息报告的操作。本协议仅限于Internet号码资源证书管理的应用，不作为更通用的证书管理框架的一部分使用。
Terms used in this document are:
本文件中使用的术语为：
"Internet Number Resource" (or "resource") used in the context of this document to refer to Autonomous System (AS) numbers, IP version 4 addresses, and IP version 6 addresses.
本文件中使用的“互联网号码资源”（或“资源”）指自主系统（AS）号码、IP版本4地址和IP版本6地址。
"issuer" used in the context of this document as an entity undertaking the role of resource issuer. An "issuer" is a Certification Authority (CA), and can issue resource certificates.
“发行人”在本文件中用作承担资源发行人角色的实体。“颁发者”是证书颁发机构（CA），可以颁发资源证书。
"subject" used in the context of this document as an entity undertaking the role of resource recipient who is the subject of a resource certificate. A "subject" may be issued with a CA-enabled certificate, allowing the entity to also assume the role of an "issuer".
“主体”在本文件中用作承担资源接收者角色的实体，资源接收者是资源证书的主体。“主体”可以被颁发CA启用证书，从而允许实体也承担“颁发者”的角色。
"resource class" a resource class refers to a collection of resources that can be certified in a single resource certificate by an issuer.
“资源类”资源类是指可由颁发者在单个资源证书中认证的资源集合。
"server" in the context of this client/server protocol specification, the issuer assumes the role of the "server".
“服务器”在本客户机/服务器协议规范的上下文中，发卡机构承担“服务器”的角色。
"client" in the context of this client/server protocol specification, the subject assumes the role of the "client".
“客户机”在本客户机/服务器协议规范的上下文中，主体承担“客户机”的角色。
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]中所述进行解释。
This Resource Public Key Infrastructure (RPKI) certificate provisioning protocol defines a basic set of interactions that allow a subject to request certificate issuance, revocation, and status information from the issuer, and for an issuer to maintain an issued certificate set that is aligned to the allocation records relating to each subject. The issuer's resource allocation database is the authoritative source of what resource allocations the issuer may certify for a subject.
此资源公钥基础设施（RPKI）证书提供协议定义了一组基本的交互，允许主体从颁发者请求证书颁发、吊销和状态信息，并允许颁发者维护与每个主体相关的分配记录一致的已颁发证书集。发卡机构的资源分配数据库是发卡机构可认证的主题资源分配的权威来源。
A resource recipient (subject) may also undertake the role of a resource issuer (issuer).
资源接收者（主体）也可以担任资源发布者（发布者）的角色。
This protocol specification does not encompass:
本协议规范不包括：
o signing of objects with keys that are certified by resource certificates, nor the issuance of end-entity certificates.
o 使用由资源证书认证的密钥对对象进行签名，或颁发最终实体证书。
o the specification of interaction with the issuer's resource allocation database, nor the specification of a protocol to manage the publication repository.
o 与发布者的资源分配数据库的交互规范，也不是管理发布存储库的协议规范。
o the interactions between client and server that establish identities, or the exchange of the certificates and validation Public Key Infrastructure (PKI) contexts used in the Cryptographic Message Syntax (CMS) [RFC5652] message exchange.
o 建立身份的客户端和服务器之间的交互，或在加密消息语法（CMS）[RFC5652]消息交换中使用的证书和验证公钥基础设施（PKI）上下文的交换。
o the interactions between client and server that allow respective local CMS signing time values to be reset to mutually recognized values.
o 客户端和服务器之间的交互，允许将各自的本地CMS签名时间值重置为相互认可的值。
This RPKI certificate provisioning protocol is expressed as a simple request/response interaction, where the client passes a request to the server, and the server generates a corresponding response.
此RPKI证书供应协议表示为简单的请求/响应交互，其中客户端将请求传递给服务器，服务器生成相应的响应。
The protocol is implemented as an exchange of messages.
该协议实现为消息交换。
Messages are passed over an HTTP [RFC2616] end-to-end connection. A message exchange commences with the client initiating an HTTP POST with content type of "application/rpki-updown" and the message object as the body. The server's response is similarly an HTTP response, with the message object carried as the body of the response and with a response content type of "application/rpki-updown". The content of the POST and the server's response are "well-formed" CMS [RFC5652] objects, encoded using the Distinguished Encoding Rules (DER) for
消息通过HTTP[RFC2616]端到端连接传递。消息交换开始时，客户端启动一个HTTP POST，内容类型为“application/rpki updown”，消息对象作为主体。服务器的响应类似于HTTP响应，消息对象作为响应主体，响应内容类型为“application/rpki updown”。POST的内容和服务器的响应是“格式良好”的CMS[RFC5652]对象，使用可分辨编码规则（DER）对其进行编码
ASN.1 [X.509-88], formatted in accordance with the CMS profile specified in the following section. CMS is used as the signing format to sign the message object. The CMS message includes an end-entity (EE) certificate that is to be used to validate the CMS digital signature (see Section 3.1.1.4); the certificate chain that is used to validate the EE certificate MAY be included in the CMS message, and if it is not present it is assumed to have been communicated between the two entities, through mechanisms not defined in this specification.
ASN.1[X.509-88]，按照以下章节中规定的CMS配置文件进行格式化。CMS用作对消息对象进行签名的签名格式。CMS消息包括用于验证CMS数字签名的终端实体（EE）证书（见第3.1.1.4节）；用于验证EE证书的证书链可包含在CMS消息中，如果不存在，则假定已通过本规范中未定义的机制在两个实体之间进行了通信。
The protocol's request/response interaction is assumed to be reliable, in that all requests MUST generate a matching response. The protocol requires sequential operation for each distinct client, where the server MUST NOT accept a client's request unless it has generated and sent a response to the client's previous request. Attempts by the client to initiate multiple requests in parallel (i.e., multiple concurrent requests with a common sender attribute (see Section 3.2) in the request) MUST be detected by the server and rejected with an error response (i.e., an error code 1101 response).
协议的请求/响应交互被认为是可靠的，因为所有请求都必须生成匹配的响应。该协议要求对每个不同的客户机进行顺序操作，其中服务器不得接受客户机的请求，除非它已生成并发送对客户机先前请求的响应。服务器必须检测到客户端并行发起多个请求（即，请求中具有公共发送者属性（见第3.2节）的多个并发请求）的尝试，并使用错误响应（即，错误代码1101响应）予以拒绝。
The format of the 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 id-signedData, OID = 1.2.840.113549.1.7.2. [RFC5652]
内容类型是id数据的签名数据类型，即id signedData，OID=1.2.840.113549.1.7.2。[RFC5652]
According to the CMS standard [RFC5652], signed-data content types are the ASN.1 type SignedData:
根据CMS标准[RFC5652]，签名数据内容类型为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
SignerInfos ::= SET OF SignerInfo
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
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 Object Identifiers (OID)s 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 certificate provisioning protocol.
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
The eContentType for the RPKI Protocol Message object is defined as id-ct-xml, and has the numerical value of 1.2.840.113549.1.9.16.1.28.
RPKI协议消息对象的eContentType定义为id ct xml，其数值为1.2.840.113549.1.9.16.1.28。
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-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
The content of an RPKI XML Protocol Object consists of a single protocol message, structured according to a defined XML schema, as defined in subsequent sections of this document. The eContent field of the CMS object is formally defined using ASN.1 as:
RPKI XML协议对象的内容由单个协议消息组成，该消息根据本文档后续章节中定义的已定义XML模式进行结构化。CMS对象的eContent字段使用ASN.1正式定义为：
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
This field MUST be present and MUST contain the single EE certificate of the key pair whose private key value was used to sign the CMS. This MUST NOT be an RPKI certificate, and SHOULD be a certificate that is recognized to attest to the identity of the party that created the CMS object.
此字段必须存在，并且必须包含密钥对的单个EE证书，其私钥值用于签署CMS。这不能是RPKI证书，而应该是一个被认可的证书，以证明创建CMS对象的一方的身份。
This field MAY contain CA certificates that a relying party MAY use to validate the EE certificate.
此字段可能包含依赖方可用于验证EE证书的CA证书。
This field MUST be present. The contents of the field are specified in [RFC5652]. The current Certificate Revocation List (CRL) issued by the same CA that issued the EE certificate of the key pair whose private key value was used to sign the CMS MUST be present in this field. This field MAY contain CRLs issued by other CAs covering CA certificates included in the certificates field of the CMS object (see Section 3.1.1.4). This field MUST NOT contain any other CRLs.
此字段必须存在。[RFC5652]中规定了该字段的内容。此字段中必须存在由颁发密钥对EE证书的CA颁发的当前证书吊销列表（CRL），该密钥对的私钥值用于签署CMS。该字段可能包含由其他CA颁发的CRL，涵盖CMS对象证书字段中包含的CA证书（见第3.1.1.4节）。此字段不得包含任何其他CRL。
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 }
In this profile, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
在此配置文件中，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 field is defined as:
signedAttrs字段定义为：
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= 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 signedAttr element MUST be present and MUST include the content-type and message-digest attributes [RFC5652]. If either the signing-time [RFC5652] attribute or the binary-signing-time attribute [RFC6019], or both attributes, are present, they MUST also be included as the SignedAttributes. Other signed attributes MUST NOT be included.
signedAttr元素必须存在，并且必须包含内容类型和消息摘要属性[RFC5652]。如果存在签名时间[RFC5652]属性或二进制签名时间属性[RFC6019]或这两个属性，则它们也必须作为SignedAttribute包含。不得包括其他已签名属性。
The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in this profile, the attrValues MUST consist of only a single AttributeValue.
signedAttr必须只包含任何特定属性的单个实例。此外，即使语法允许使用一组AttributeValue，在此配置文件中，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。
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The attrValues for the content-type attribute MUST match the eContentType in the EncapsulatedContentInfo. This OID value is defined as id-ct-xml and has the numerical value of 1.2.840.113549.1.9.16.1.28.
content type属性的属性值必须与封装的ContentInfo中的eContentType匹配。该OID值定义为id ct xml，其数值为1.2.840.113549.1.9.16.1.28。
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。
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRING
MessageDigest ::= OCTET STRING
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. The attrType OID for the signing-time attribute is 1.2.840.113549.1.9.5.
签名时间属性可能存在。签名时间属性的属性类型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 }
SigningTime ::= Time
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The signing-time attribute specifies the time, based on the local system clock, when the digital signature was applied to the content.
signing time属性根据本地系统时钟指定将数字签名应用于内容的时间。
Guidelines regarding the use of UTCTime and GeneralizedTime in the signing-time attribute can be found in Section 11.3 of [RFC5652].
关于在签名时间属性中使用UTCTime和GeneratedTime的指南，请参见[RFC5652]的第11.3节。
Either one of the signing-time attribute or the binary-signing-time attribute, or both attributes, MUST be present. If both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value.
必须存在签名时间属性或二进制签名时间属性中的一个或两个属性。如果签名时间和二进制签名时间属性都存在，则它们必须都表示相同的基础时间值。
The binary-signing-time attribute MAY be present. The attrType OID for the binary-signing-time attribute is 1.2.840.113549.1.9.16.2.46.
可能存在二进制签名时间属性。二进制签名时间属性的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 }
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
BinarySigningTime ::= BinaryTime
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
BinaryTime ::= INTEGER (0..MAX)
The binary-signing-time attribute specifies the time, based on the local system clock, when the digital signature was applied to the content. The precise definition of the binary-signing-time attribute can be found at [RFC6019].
二进制签名时间属性根据本地系统时钟指定将数字签名应用于内容的时间。二进制签名时间属性的精确定义见[RFC6019]。
Either one of the signing-time or the binary-signing-time attributes, or both attributes, MUST be present. If both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value.
必须存在签名时间或二进制签名时间属性中的一个或两个属性。如果签名时间和二进制签名时间属性都存在，则它们必须都表示相同的基础时间值。
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 recipient of a CMS signed object can use the content of the object, the recipient MUST validate the signed object by verifying that all of the following conditions hold. A recipient may perform these checks in any order.
在CMS签名对象的收件人可以使用该对象的内容之前，收件人必须通过验证以下所有条件是否成立来验证签名对象。收件人可以按任何顺序执行这些检查。
1. The CMS object is well formed, such that the signed object syntax complies with this specification. In particular, that each of the following is true:
1. CMS对象格式良好，因此签名对象语法符合本规范。特别是，以下每一项都是正确的：
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 present.
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 one each of the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and either or both of a single instance of 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), and no other attributes.
f. 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.2.46），无其他属性。
g. The eContentType in the EncapsulatedContentInfo is an OID that matches the attrValue in the content-type attribute and has the attrValue of id-ct-xml.
g. 封装的ContentInfo中的eContentType是一个OID，它与content type属性中的attrValue相匹配，并具有id ct xml的attrValue。
h. The unsignedAttrs field in the SignerInfo object is omitted.
h. SignerInfo对象中的unsignedAttrs字段被省略。
i. If both the signing-time attribute and the binary-signing-time attribute are present, then their values represent the same time.
i. 如果签名时间属性和二进制签名时间属性都存在，则它们的值表示相同的时间。
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 particular, there exists a valid certification path from a trust anchor selected by the recipient to this EE certificate.
3. EE证书（包含在CMS签名数据对象中）是有效的EE证书。特别是，存在从收件人选择的信任锚点到此EE证书的有效证书路径。
4. At the current time, the EE certificate is not revoked. This can be determined by confirming that the CRL contained in the crls field of the CMS signed data object is a current valid CRL, issued by the same CA that issued the EE certificate, and the CRL does not list the serial number of the EE certificate.
4. 目前，EE证书未被吊销。这可以通过确认CMS签名数据对象的crls字段中包含的CRL是当前有效的CRL，由颁发EE证书的同一CA颁发，并且CRL没有列出EE证书的序列号来确定。
5. The time represented by the signing-time attribute or the binary-signing-time attribute is greater than or equal to the time value passed in previously valid CMS objects that were passed from the same originator to this recipient. This signing time value MAY lie within the Validity Time of the EE certificate, but the EE certificate SHOULD NOT be considered invalid if this is not the case when all other checks listed here are passed.
5. 签名时间属性或二进制签名时间属性表示的时间大于或等于从同一发起人传递给此收件人的以前有效CMS对象中传递的时间值。此签名时间值可能在EE证书的有效期内，但如果此处列出的所有其他检查均通过，则不应认为EE证书无效。
The following is the ASN.1 specification of the CMS signed object used by the RPKI provisioning protocol.
以下是RPKI供应协议使用的CMS签名对象的ASN.1规范。
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
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-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-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
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
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 }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
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
SignatureValue ::= OCTET STRING
SignatureValue ::= OCTET STRING
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRING
MessageDigest ::= OCTET STRING
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 }
SigningTime ::= Time
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(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 }
BinarySigningTime ::= BinaryTime
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
BinaryTime ::= INTEGER (0..MAX)
The XML template for all messages is informally described as follows (the RELAX NG compact form schema that formally describes the protocol message objects is contained in Section 3.7):
所有消息的XML模板非正式描述如下（正式描述协议消息对象的RELAXNG紧凑表单模式包含在第3.7节中）：
---------------------------------------------------------------
---------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
<?xml version="1.0" encoding="UTF-8"?>
<message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
version="1" sender="sender name" recipient="recipient name" type="message type">
version=“1”sender=“sender name”recipient=“recipient name”type=“message type”>
[payload]
[有效载荷]
</message>
</message>
---------------------------------------------------------------
---------------------------------------------------------------
version: the value of this attribute is the version of this protocol. This document describes version 1.
版本：此属性的值是此协议的版本。本文档介绍版本1。
sender: the value of this attribute is the agreed name of the message sender, as determined between the client and the server by prior arrangement.
发送者：此属性的值是消息发送者的约定名称，由客户机和服务器事先安排确定。
recipient: the value of this attribute is the agreed name of the message recipient, as determined between the client and the server by prior arrangement.
recipient：此属性的值是消息收件人的约定名称，由客户机和服务器通过事先安排确定。
type: the possible values of this attribute are "list", "list_response", "issue", "issue_response", "revoke", "revoke_response", and "error_response".
类型：此属性的可能值为“列表”、“列表响应”、“问题”、“问题响应”、“撤销”、“撤销响应”和“错误响应”。
Conforming parsers MUST reject any document with a version number they do not understand or with any elements or attributes they do not understand. Servers must generate an error response when receiving such a request. Clients should generate an error when receiving such a response.
一致性分析人员必须拒绝任何版本号不清楚或元素或属性不清楚的文档。服务器在接收此类请求时必须生成错误响应。客户端在收到这样的响应时应该生成一个错误。
The encapsulated content of the CMS wrapping is an XML document. The remainder of this protocol specification omits this CMS wrapper and only discusses the XML document.
CMS包装的封装内容是一个XML文档。本协议规范的其余部分省略了CMS包装，只讨论XML文档。
Messages are checked using the following tests:
使用以下测试检查消息：
1. Check that the CMS is well-formed (see test 1 of Section 3.1.2).
1. 检查CMS是否成形良好（见第3.1.2节测试1）。
2. Check that the XML is well-formed.
2. 检查XML的格式是否正确。
3. Check that the XML sender and recipient attributes reference a known client and this server's system respectively for a query, and the previously addressed server and this client for a response.
3. 检查XML sender和recipient属性是否分别引用已知客户端和此服务器的系统进行查询，以及先前寻址的服务器和此客户端是否进行响应。
4. Verify the digital signature using the public key provided in the certificate carried in the CMS wrapper (see test 2 of Section 3.1.2).
4. 使用CMS包装中的证书中提供的公钥验证数字签名（见第3.1.2节测试2）。
5. Validate the CMS-provided certificate using the PKI that has been determined by prior arrangement between the client and server (see test 3 of Section 3.1.2).
5. 使用客户机和服务器之间事先安排确定的PKI验证CMS提供的证书（见第3.1.2节测试3）。
6. Check that the signing time of the CMS is equal to or greater than the signing time provided in the most recent previous message that this recipient has received from this sender (see test 4 of Section 3.1.2).
6. 检查CMS的签名时间是否等于或大于该收件人从该发件人收到的最近一封邮件中提供的签名时间（见第3.1.2节测试4）。
7. Check that the value of the version number of the message is 1.
7. 检查消息版本号的值是否为1。
These checks SHOULD be applied in the order specified here.
这些检查应按此处指定的顺序进行。
Any errors encountered while checking items 1 through 7 MUST cause a server to generate an "HTTP 400 Bad Request" response to the HTTP POST operation. An error in step 7 MUST cause the server to generate a "Request-Not-Performed" error response. Any errors encountered in these tests by a client SHOULD cause the client to generate an error.
检查项目1到7时遇到的任何错误都必须导致服务器对HTTP POST操作生成“HTTP 400错误请求”响应。步骤7中的错误必须导致服务器生成“未执行请求”错误响应。客户机在这些测试中遇到的任何错误都会导致客户机生成错误。
A server MAY perform flow control on the rate of processed requests. Requests not processed due to such a flow control constraint MAY cause the server to generate an "HTTP 503 Service Unavailable" response. An HTTP 503 response MAY include an HTTP Retry-After: header as a hint to the client.
服务器可以对已处理请求的速率执行流控制。由于这种流控制约束而未处理的请求可能会导致服务器生成“HTTP 503服务不可用”响应。HTTP 503响应可以包括HTTP Retry After:头，作为对客户端的提示。
This query is used for a client to query a server for a list of all resources that have been allocated or assigned by the server to the client. In addition, the server's response will contain a copy of the current certificates issued by the server's CA where this client is the certificate's subject.
此查询用于客户端向服务器查询服务器已分配或分配给客户端的所有资源的列表。此外，服务器的响应将包含服务器CA颁发的当前证书的副本，其中该客户端是证书的主体。
The value of the message "type" message attribute for this query is:
此查询的消息“类型”消息属性的值为：
type="list"
type=“列表”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
[No message payload is defined for this query]
[未为此查询定义任何消息负载]
---------------------------------------------------------------
---------------------------------------------------------------
The value of the message "type" element for this response is:
此响应的消息“type”元素的值为：
type="list_response"
type=“列表\响应”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set"
resource_set_notafter="datetime"
suggested_sia_head="[directory uri]" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set"
resource_set_notafter="datetime"
suggested_sia_head="[directory uri]" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
...
...
(repeated for each current certificate where the client is the certificate's subject)
（如果客户是证书的主体，则对每个当前证书重复）
<issuer>[issuer's certificate]</issuer>
</class>
<issuer>[issuer's certificate]</issuer>
</class>
...
...
(repeated for each of the issuer's resource class where the client has been allocated resources)
（对于已为客户分配资源的每个发行人资源类别重复）
---------------------------------------------------------------
---------------------------------------------------------------
Where the client has been allocated resources from multiple resource classes, the response MUST contain multiple class elements that correspond to the complete set of the issuer's resource classes where the client holds allocated resources. Those issuer's resource classes where the client holds no allocated resources MUST NOT be included in the response.
如果已从多个资源类向客户端分配了资源，则响应必须包含多个类元素，这些类元素对应于客户端持有已分配资源的发卡机构资源类的完整集合。客户端未持有已分配资源的发卡机构资源类不得包含在响应中。
Where the issuer has issued multiple certificates in a resource class signed with different keys (as may occur during a staged issuer-key
颁发者已在资源类中颁发了多个证书，并使用不同的密钥进行了签名（在分段颁发者密钥期间可能会发生这种情况）
rollover), only the most recent certificate issued with the currently "active" issuer's key is to be listed in the response.
响应中只列出使用当前“活动”颁发者密钥颁发的最新证书。
Each "class" element describes a set of resources that are certified within the scope of a single certificate, referring to a single resource class with a common validation path.
每个“类”元素描述一组在单个证书范围内经过认证的资源，引用具有公共验证路径的单个资源类。
class_name: the value of this attribute is the issuer-assigned name of the issuer's resource class.
class_name：该属性的值是发卡机构资源类的发卡机构分配名称。
cert_url: in the context of a class element, the value of this attribute is a pointer to the issuer's CA certificate (i.e., a reference to the immediate superior certificate, being the CA-enabled certificate where the issuer is the certificate's subject). Its value is a comma-separated list of URIs, of which at least one MUST be an rsync URI [RFC5781]. Any comma values within a URI MUST be escaped ("%2C"). The ordering of the list may be interpreted by the client as a relative preference for access methods as expressed by the publisher of this certificate.
cert_url：在类元素的上下文中，此属性的值是指向颁发者的CA证书的指针（即，对直接上级证书的引用，是启用CA的证书，其中颁发者是证书的主体）。它的值是以逗号分隔的URI列表，其中至少有一个必须是rsync URI[RFC5781]。URI中的任何逗号值都必须转义（“%2C”）。客户可以将列表的顺序解释为访问方法的相对偏好，如本证书的发布者所表示的。
resource_set_as: in the context of a class element, the value of this attribute is the set of AS numbers and AS number ranges that the issuer has allocated to the client within the scope of this resource class, presented in ASCII as a comma-separated list. The list elements are decimal integer values and ranges of decimal integers specified by the lowest and highest values of the range with a hyphen delimiter, using the canonical order as described in [RFC3779], without leading zeros, and with no white space or punctuation other than the comma and the hyphen range designator (e.g., resource_set_as="123,456-789,123456"). If there are no AS numbers in this resource class, then the empty AS set is represented by a null string value ("") for this attribute.
resource_set_as：在类元素的上下文中，此属性的值是颁发者分配给该资源类范围内的客户端的as编号和as编号范围的集合，以ASCII格式以逗号分隔的列表表示。列表元素是十进制整数值和十进制整数值范围，该范围的最低值和最高值用连字符分隔符指定，使用[RFC3779]中所述的规范顺序，不带前导零，除逗号和连字符范围指示符（例如，资源集）外，不带空格或标点=“123456-789123456”）。如果此资源类中没有AS编号，则此属性的空AS集由空字符串值（“”）表示。
resource_set_ipv4: in the context of a class element, the value of this attribute is the set of IPv4 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <dotted quad>/mask length, or a range specified as the lowest and highest values of the range in dotted quad notation with a hyphen delimiter. The list is presented in canonical order, as described in [RFC3779]. The dotted quad notation is without leading zeros, and the list contains no white space or punctuation other than the period, forward slash, hyphen, and comma (e.g.,
resource_set_ipv4：在类元素的上下文中，此属性的值是颁发者在此资源类范围内分配给客户端的ipv4地址集。该值以ASCII格式表示为逗号分隔的元素列表。每个元素要么是使用<虚线四元>/掩码长度表示法的地址前缀，要么是使用连字符分隔符指定为虚线四元表示法中范围的最低值和最高值的范围。列表按规范顺序显示，如[RFC3779]所述。虚线四元符号没有前导零，列表中除了句点、正斜杠、连字符和逗号（例如。，
resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76"). If there are no IPv4 addresses in this resource class, the empty IPv4 address set is represented by a null string value ("") for this attribute.
resource_set_ipv4=“192.0.2.0/26192.0.2.66-192.0.2.76”）。如果此资源类中没有IPv4地址，则此属性的空IPv4地址集由空字符串值（“”）表示。
resource_set_ipv6: in the context of a class element, the value of this attribute is the set of IPv6 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <hex nibble sequence>/mask length, or a range specified as lowest and highest values of the range in hex nibble notation with a hyphen delimiter. Trailing zero nibbles are truncated and represented by '::'. The list is presented in canonical order, as described in [RFC3779]. The hex nibble sequence notation is without leading zeros, and the list contains no white space or punctuation other than the colon, forward slash, hyphen, and comma, and conforms to the canonical format of [RFC5952] (e.g., resource_set_ipv6="2001:db8::/48,2001:db8:2::-2001:db8:5::"). The XML Schema data type is "http://www.w3.org/TR/xmlschema-2/#hexBinary" and the value is case insensitive, with the canonical form being lower case. If there are no IPv6 addresses in this resource class, the empty IPv6 address set is represented by a null string value ("") for this attribute.
resource_set_ipv6：在类元素的上下文中，此属性的值是颁发者在该资源类的范围内分配给客户端的一组ipv6地址。该值以ASCII格式表示为逗号分隔的元素列表。每个元素要么是使用<hex-nibble-sequence>/mask-length表示法的地址前缀，要么是使用连字符分隔符指定为十六进制nibble表示法中范围的最低值和最高值的范围。尾随的零半字节被截断并用“：”表示。列表按规范顺序显示，如[RFC3779]所述。十六进制半字节序列表示法没有前导零，列表中除冒号、正斜杠、连字符和逗号外不包含空格或标点符号，并且符合[RFC5952]的标准格式（例如，resource_set_ipv6=“2001:db8:：/482001:db8:2:：-2001:db8:5:”）。XML架构数据类型为“http://www.w3.org/TR/xmlschema-2/#hexBinary值不区分大小写，标准形式为小写。如果此资源类中没有IPv6地址，则此属性的空IPv6地址集由空字符串值（“”）表示。
resource_set_notafter: The value of this attribute specifies the date/time that would be set in the Validity notAfter field in any new certificate issued for this particular client within the scope of this resource class, should the client request a new certificate. The time format used for the value of this attribute is specified as defined in ISO 8601 [ISO.8601:2004], and MUST use UTC time represented as YYYY-MM-DDThh:mm:ssZ (e.g., 2007-11-29T04:40:00Z). If the client's certificate has a validity notAfter time that is different from this time, then the client SHOULD request a new certificate to be issued for this resource class.
resource_set_notafter：如果客户端请求新证书，则此属性的值指定在此资源类范围内为该特定客户端颁发的任何新证书的Validity notafter字段中设置的日期/时间。用于此属性值的时间格式按照ISO 8601[ISO.8601:2004]中的定义指定，并且必须使用UTC时间表示为YYYY-MM DDThh:MM:ssZ（例如，2007-11-29T04:40:00Z）。如果客户端的证书的有效期不超过此时间，则客户端应请求为此资源类颁发新证书。
suggested_sia_head: (OPTIONAL) If this field is present, then its value is a directory URI that indicates a repository publication point that the server has made available to the client to use for the client's collection of published products. This specification does not encompass the protocols that the client may use with the operator of the repository publication point in order to publish objects at this publication point.
建议的_sia_head：（可选）如果存在此字段，则其值是一个目录URI，指示服务器已向客户端提供的存储库发布点，用于客户端的已发布产品集合。此规范不包括客户端可能与存储库发布点的操作员一起使用的协议，以便在此发布点发布对象。
[issuer's certificate] value is the Base64 encoding of the DER-encoded issuer's CA certificate (the CA-enabled certificate where the issuer is the certificate's subject).
[issuer's certificate]值是DER编码的颁发者CA证书（颁发者是证书主体的启用CA的证书）的Base64编码。
Each certificate element describes the most recently issued current certificate where the certificate's subject refers to the client for each active client key pair. A "current" certificate is a non-expired, non-revoked certificate. If no current certificate has been issued, then no certificate element is to be included in the response.
每个证书元素描述最近颁发的当前证书，其中证书的主题指每个活动客户端密钥对的客户端。“当前”证书是未过期、未吊销的证书。如果没有颁发当前证书，则响应中不包括任何证书元素。
cert_url: in the context of a certificate element, this is a pointer to the location where the certificate issuer has published this certificate. This field is the issuer's suggestion for the Authority Information Access (AIA) field for the subject to use in subordinate certificates that are issued by the subject. According to the Resource Certificate Profile [RFC6487], the AIA field is a non-empty (contains a minimum of 1 element) list of URI's, one of which MUST be an rsync URI [RFC5781]. The order of URI's in the AIA field may be interpreted as the publisher's relative preference for access methods for this certificate. The cert_url conforms to this AIA specification. Its value is a comma-separated list of URIs, one of which MUST be an rsync URI. Any comma values within a URI MUST be escaped ("%2C").
cert_url：在证书元素的上下文中，这是指向证书颁发者发布此证书的位置的指针。此字段是发卡机构对主体的授权信息访问（AIA）字段的建议，用于主体颁发的从属证书中。根据资源证书配置文件[RFC6487]，AIA字段是URI的非空（至少包含1个元素）列表，其中一个必须是rsync URI[RFC5781]。AIA字段中URI的顺序可以解释为发布者对该证书访问方法的相对偏好。证书url符合本AIA规范。它的值是一个逗号分隔的URI列表，其中一个必须是rsync URI。URI中的任何逗号值都必须转义（“%2C”）。
req_resource_set_as: the set of AS numbers that were specified in the corresponding original certificate request that defined the maximal requested span of the certified AS number set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
req_resource_set_as：在相应的原始证书请求中指定的一组as编号，按照上述语法定义认证as编号集的最大请求范围。如果该属性存在于证书请求中，则该属性必须存在于该响应中；否则，它不能出现。
req_resource_set_ipv4: the set of IPv4 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv4 address set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
req_resource_set_ipv4：在相应的原始证书请求中指定的一组ipv4地址，该请求定义了经认证的ipv4地址集的最大请求范围，符合上述语法。如果该属性存在于证书请求中，则该属性必须存在于该响应中；否则，它不能出现。
req_resource_set_ipv6: the set of IPv6 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv6 address set, following the syntax described above. If this attribute was present in the certificate
req_resource_set_ipv6：在相应的原始证书请求中指定的一组ipv6地址，该请求定义了经认证的ipv6地址集的最大请求范围，符合上述语法。如果证书中存在此属性
request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
请求，则该属性必须存在于该响应中；否则，它不能出现。
[certificate] value is the Base64 encoding of the DER-encoded certificate.
[certificate]值是DER编码证书的Base64编码。
This query is used by the client to request the server's CA to issue a resource certificate for the resources that have been allocated or assigned to the client. If the request can be successfully processed, then the server's response includes the issued certificate.
客户端使用此查询请求服务器的CA为已分配或分配给客户端的资源颁发资源证书。如果请求可以成功处理，则服务器的响应包括已颁发的证书。
The value of the message "type" element for this request is:
此请求的消息“type”元素的值为：
type="issue"
type=“问题”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<request
class_name="class name"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set">
[Certificate request]
</request>
<request
class_name="class name"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set">
[Certificate request]
</request>
---------------------------------------------------------------
---------------------------------------------------------------
The client MUST use different key pairs for each distinct resource class.
客户端必须为每个不同的资源类使用不同的密钥对。
The req_resource_set attributes are optional in the request.
请求资源集属性在请求中是可选的。
If none of the req_resource_set attributes are specified, then the request signifies that the complete set of all resources that match the client's current resource allocation is to be included in the issued certificate.
如果未指定任何req_resource_set属性，则该请求表示与客户端当前资源分配匹配的所有资源的完整集合将包含在颁发的证书中。
If any of the req_resource_set attributes are specified in the request, then any missing req_resource_set attributes are to be interpreted as specifying the complete set of the corresponding
如果在请求中指定了任何req_资源_集属性，则任何缺少的req_资源_集属性都将被解释为指定了相应资源的完整集
resource type that match the client's current resource allocation are to be included in the issued certificate.
与客户端当前资源分配匹配的资源类型将包含在颁发的证书中。
If the value of any included req_resource_set attributes is the null value (""), then this indicates that no resources of that resource type are to be included in the issued certificate.
如果任何包含的req_resource_set属性的值为空值（“”），则这表示颁发的证书中不包含该资源类型的资源。
The requested resource set values are held as a local record by the issuer against the resource class and the client's public key. Any subsequent Certificate Issuance Requests that specify the same resource class and the same client's public key will (re)set the issuer's local record of the requested resource sets to the most recently specified values.
请求的资源集值由颁发者根据资源类和客户机的公钥保存为本地记录。指定相同资源类和相同客户端公钥的任何后续证书颁发请求将（重新）将颁发者请求的资源集的本地记录设置为最近指定的值。
class_name: value is the server's identifier of a resource class.
class\u name:value是资源类的服务器标识符。
req_resource_set_as: (OPTIONAL) the set of AS numbers that define the maximal requested span of the certified AS number set, formatted as per the resource_set_as attribute of the resource class list response.
req_resource_set_as：（可选）定义认证as编号集的最大请求范围的as编号集，按照资源类列表响应的resource_set_as属性格式化。
req_resource_set_ipv4: (OPTIONAL) the set of IPv4 addresses that define the maximal requested span of the certified IPv4 address set, formatted as per the resource_set_ipv4 attribute of the resource class list response.
req_resource_set_ipv4：（可选）定义经认证的ipv4地址集的最大请求范围的ipv4地址集，按照资源类列表响应的resource_set_ipv4属性进行格式化。
req_resource_set_ipv6: (OPTIONAL) the set of IPv6 addresses that define the maximal requested span of the certified IPv6 address set, formatted as per the resource_set_ipv6 attribute of the resource class list response.
req_resource_set_ipv6：（可选）定义经认证的ipv6地址集的最大请求范围的ipv6地址集，按照资源类列表响应的resource_set_ipv6属性进行格式化。
[Certificate request] value is the certificate request. This is a Base64 encoded DER version of a request formatted using PKCS#10 [RFC2986]. The certificate request is signed using the private key part of the key pair whose public part is the subject key value in the certification request. The signing algorithm is specified in [RFC6485]. (This signature component is intended to demonstrate proof of possession of the private key.)
[证书请求]值是证书请求。这是使用PKCS#10[RFC2986]格式化的请求的Base64编码DER版本。证书请求使用密钥对的私钥部分签名，该密钥对的公钥部分是证书请求中的主体密钥值。[RFC6485]中规定了签名算法。（此签名组件旨在证明拥有私钥。）
The response to this request is a Certificate Issuance Response if the request can be processed online. If the request cannot be undertaken immediately, then the server MUST respond with a "Request-Not-Performed" message, using the appropriate error code:
如果可以在线处理该请求，则对此请求的响应为证书颁发响应。如果无法立即执行请求，则服务器必须使用适当的错误代码以“request Not Executed”（请求未执行）消息进行响应：
o If the resource class is not defined by the server, then the server MUST return error code 1201.
o 如果服务器未定义资源类，则服务器必须返回错误代码1201。
o If the client holds no resources in a defined resource class, then the server MUST return error code 1202 and not proceed with the request.
o 如果客户端在定义的资源类中没有资源，那么服务器必须返回错误代码1202，并且不能继续请求。
o If the certificate request payload is badly formed, then the server MUST return error code 1203.
o 如果证书请求有效负载的格式不正确，则服务器必须返回错误代码1203。
o If the public key used in the certificate request implies that the client is attempting to use identical key pairs for multiple resource classes, then the server MUST respond with a 1204 error code.
o 如果证书请求中使用的公钥意味着客户端试图对多个资源类使用相同的密钥对，则服务器必须以1204错误代码响应。
o If the certificate issuer uses an off-line process to undertake certificate issuance, and the server cannot directly respond to the certificate issuance request with an issued certificate, then the certificate issuer MUST respond to the first instance of this request with an error code 1104 to indicate that the request is being processed asynchronously. Subsequent repetitions of this request while the off-line actions are being undertaken SHOULD cause a response with error code 1101. In this context, where off-line processes are invoked for certificate issuance, if the certificate issuer determines in processing the request that the issued certificate would be identical in all respects to the most recently issued certificate for this client, other than the certificate's serial number, were the certificate to be issued, the issuer may choose to respond with the most recently issued certificate and not initiate an off-line certificate issuance request.
o 如果证书颁发者使用离线流程进行证书颁发，并且服务器无法使用颁发的证书直接响应证书颁发请求，然后，证书颁发者必须使用错误代码1104响应该请求的第一个实例，以指示该请求正在异步处理。在执行离线操作时，后续重复此请求应导致错误代码为1101的响应。在这种情况下，如果调用离线进程进行证书颁发，则如果证书颁发者在处理请求时确定所颁发的证书在所有方面都与该客户端最近颁发的证书相同，而不是证书的序列号，则证书将被颁发，发卡机构可以选择使用最新颁发的证书进行响应，而不发起离线证书颁发请求。
Note that a client, when receiving a 1104 response to a certificate issuance request, MAY periodically resubmit the request, in which case the client MUST receive an error code 1101 response while the request is being processed, and a Certificate Issuance Response when the certificate issuance process has completed. In such circumstances, a client SHOULD limit the frequency of such repeated requests to no more than 1 request in each 24-hour interval.
注意，当客户端接收到对证书颁发请求的1104响应时，可以定期重新提交该请求，在这种情况下，客户端必须在处理请求时接收错误代码1101响应，并且在证书颁发过程完成时接收证书颁发响应。在这种情况下，客户应将此类重复请求的频率限制为每24小时间隔不超过1次。
The value of the message "type" element for this response is:
此响应的消息“type”元素的值为：
type="issue_response"
type=“发布\响应”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
<issuer>[issuer's certificate]</issuer>
</class>
<class class_name="class name"
cert_url="url"
resource_set_as="as resource set"
resource_set_ipv4="ipv4 resource set"
resource_set_ipv6="ipv6 resource set" >
<certificate cert_url="url"
req_resource_set_as="as resource set"
req_resource_set_ipv4="ipv4 resource set"
req_resource_set_ipv6="ipv6 resource set" >
[certificate]
</certificate>
<issuer>[issuer's certificate]</issuer>
</class>
---------------------------------------------------------------
---------------------------------------------------------------
If the certificate issuer determines that the issued certificate would be identical in all respects to the most recently issued certificate for this client, other than the certificate's serial number, were the certificate to be issued, the issuer may choose to respond with the most recently issued certificate and not issue a new certificate for this request.
如果证书颁发者确定所颁发的证书在所有方面都与该客户端最近颁发的证书相同，但证书的序列号除外，则该证书是要颁发的，颁发者可以选择使用最近颁发的证书进行响应，而不为此请求颁发新证书。
The definition of the attributes and syntax of the values is the same as the resource class list response, but the response only references the (single) named resource class, and the (single) certificate issued against the client's public key as provided in the corresponding certificate request.
属性的定义和值的语法与资源类列表响应相同，但响应仅引用（单个）命名资源类，以及根据相应证书请求中提供的客户端公钥颁发的（单个）证书。
This request 'retires' a client's key pair by requesting that the server's CA revoke all certificates for this client (i.e., where this client is the subject) that contain the matching public key, within the scope of a named resource class. Individual certificates cannot be revoked within the scope of this protocol.
此请求通过请求服务器的CA吊销此客户机（即，此客户机是主题）的所有证书来“注销”客户机的密钥对，这些证书包含命名资源类范围内的匹配公钥。无法在此协议范围内吊销单个证书。
The value of the message "type" element for this request is:
此请求的消息“type”元素的值为：
type="revoke"
type=“撤销”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
---------------------------------------------------------------
---------------------------------------------------------------
This command directs the server's CA to immediately mark all issued valid certificates issued by this issuer within the named resource class with this client's subject name and the provided SKI value to be marked as revoked, causing the issued certificates to be withdrawn from the publication repository and to be listed in the server's subsequent CRLs within this resource class. The issuer MUST ensure that all certificates to be revoked were issued with the requesting client as the certificate's subject.
此命令指示服务器的CA立即使用此客户端的使用者名称和提供的SKI值将此颁发者在命名资源类中颁发的所有有效证书标记为吊销，导致已颁发的证书从发布存储库中撤回，并在此资源类中列出在服务器的后续CRL中。发卡机构必须确保所有要撤销的证书都是由作为证书主体的请求客户端颁发的。
class_name: value is the issuer-assigned name of the issuer's resource class.
class_name:value是发卡机构资源类的发卡机构分配名称。
ski: value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648].
ski:value是要撤销的客户端公钥的编码哈希。编码算法是生成[RFC5280]第4.2.1.2节方法（1）中定义的客户端公钥的160位SHA-1散列，并使用[RFC4648]第5节中定义的URL和文件名安全字母表的Base 64编码对该值进行编码。
The value of the message "type" element for this response is:
此响应的消息“type”元素的值为：
type="revoke_response"
type=“撤销\u响应”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
---------------------------------------------------------------
---------------------------------------------------------------
class_name: value is the issuer-assigned name of the server's resource class.
class_name:value是服务器资源类的颁发者分配的名称。
ski: value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648].
ski:value是要撤销的客户端公钥的编码哈希。编码算法是生成[RFC5280]第4.2.1.2节方法（1）中定义的客户端公钥的160位SHA-1散列，并使用[RFC4648]第5节中定义的URL和文件名安全字母表的Base 64编码对该值进行编码。
The value of the message "type" element for this response is:
此响应的消息“type”元素的值为：
type="error_response"
type=“错误\u响应”
---------------------------------------------------------------
---------------------------------------------------------------
Payload:
有效载荷：
<status>[Code]</status>
<description xml:lang="en-US">[Readable text]</description>
<status>[Code]</status>
<description xml:lang="en-US">[Readable text]</description>
---------------------------------------------------------------
---------------------------------------------------------------
All states where an error response if to be generated, either due to detected errors or inconsistencies in the content of the request or server-side states that prevent the request being performed, generate a Request-Not-Performed response.
由于检测到的错误或请求内容中的不一致或阻止执行请求的服务器端状态而要生成错误响应（如果）的所有状态都会生成请求未执行响应。
description: value is a text field. This element MAY be present. It's value has no defined meaning within the scope of this protocol, and implementations may assume that some form of human-readable text may be used here. If the HTTP request that triggered this error response includes an Accept-Language header as defined in Section 14.4 of the HTTP/1.1 specification [RFC2616], then the server MAY include a second description element using the highest ranked preferred language of the client. The en-US description MUST always be included if the element is present.
说明：值是一个文本字段。该元素可能存在。在本协议的范围内，它的值没有定义的含义，并且实现可能会假设这里可以使用某种形式的人类可读文本。如果触发此错误响应的HTTP请求包括HTTP/1.1规范[RFC2616]第14.4节中定义的接受语言标头，则服务器可能包括使用客户机排名最高的首选语言的第二个描述元素。如果存在元件，则必须始终包括en US说明。
The error code set is:
错误代码集为：
Code Value Description 1101 already processing request 1102 version number error 1103 unrecognized request type 1104 request scheduled for processing 1201 request - no such resource class 1202 request - no resources allocated in resource class 1203 request - badly formed certificate request 1204 request - already used key in request 1301 revoke - no such resource class 1302 revoke - no such key 2001 Internal Server Error - Request not performed
代码值说明1101已处理请求1102版本号错误1103未识别的请求类型1104请求计划处理1201请求-无此类资源类1202请求-资源类1203请求中未分配资源-格式错误的证书请求1204请求-请求1301中已使用的密钥撤销-没有这样的资源类1302 revoke-没有这样的密钥2001内部服务器错误-未执行请求
The following is a RELAX NG compact form schema describing version 1 of this protocol.
下面是一个RELAXNG紧凑表单模式，描述了该协议的版本1。
Note: As discussed in [XML], "the namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)".
注意：正如[XML]中所讨论的，“为了达到预期目的，名称空间名称应该具有唯一性和持久性的特征。它的目标不是直接用于检索模式（如果存在的话）”。
default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
grammar {
resource_set_as = xsd:string { maxLength="512000"
pattern="[\-,0-9]*" }
resource_set_ip4 = xsd:string { maxLength="512000"
pattern="[\-,/.0-9]*" }
resource_set_ip6 = xsd:string { maxLength="512000"
pattern="[\-,/:0-9a-fA-F]*" }
grammar {
resource_set_as = xsd:string { maxLength="512000"
pattern="[\-,0-9]*" }
resource_set_ip4 = xsd:string { maxLength="512000"
pattern="[\-,/.0-9]*" }
resource_set_ip6 = xsd:string { maxLength="512000"
pattern="[\-,/:0-9a-fA-F]*" }
class_name = xsd:token { minLength="1" maxLength="1024" }
ski = xsd:token { minLength="27" maxLength="1024" }
class_name = xsd:token { minLength="1" maxLength="1024" }
ski = xsd:token { minLength="27" maxLength="1024" }
label = xsd:token { minLength="1" maxLength="1024" }
cert_url = xsd:string { minLength="10" maxLength="4096" }
base64_binary = xsd:base64Binary { minLength="4"
maxLength="512000" }
label = xsd:token { minLength="1" maxLength="1024" }
cert_url = xsd:string { minLength="10" maxLength="4096" }
base64_binary = xsd:base64Binary { minLength="4"
maxLength="512000" }
start = element message {
attribute version { xsd:positiveInteger {
maxInclusive="1" } },
attribute sender { label },
attribute recipient { label },
payload
}
start = element message {
attribute version { xsd:positiveInteger {
maxInclusive="1" } },
attribute sender { label },
attribute recipient { label },
payload
}
payload |= attribute type { "list" }, list_request
payload |= attribute type { "list_response"}, list_response
payload |= attribute type { "issue" }, issue_request
payload |= attribute type { "issue_response"}, issue_response
payload |= attribute type { "revoke" }, revoke_request
payload |= attribute type { "revoke_response"}, revoke_response
payload |= attribute type { "error_response"}, error_response
payload |= attribute type { "list" }, list_request
payload |= attribute type { "list_response"}, list_response
payload |= attribute type { "issue" }, issue_request
payload |= attribute type { "issue_response"}, issue_response
payload |= attribute type { "revoke" }, revoke_request
payload |= attribute type { "revoke_response"}, revoke_response
payload |= attribute type { "error_response"}, error_response
list_request = empty list_response = class*
列表\请求=空列表\响应=类*
class = element class {
attribute class_name { class_name },
attribute cert_url { cert_url },
attribute resource_set_as { resource_set_as },
attribute resource_set_ipv4 { resource_set_ip4 },
attribute resource_set_ipv6 { resource_set_ip6 },
attribute resource_set_notafter { xsd:dateTime },
attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
pattern="rsync://.+"} }?,
element certificate {
attribute cert_url { cert_url },
attribute req_resource_set_as { resource_set_as }?,
attribute req_resource_set_ipv4 { resource_set_ip4 }?,
attribute req_resource_set_ipv6 { resource_set_ip6 }?,
base64_binary
}*,
element issuer { base64_binary }
}
class = element class {
attribute class_name { class_name },
attribute cert_url { cert_url },
attribute resource_set_as { resource_set_as },
attribute resource_set_ipv4 { resource_set_ip4 },
attribute resource_set_ipv6 { resource_set_ip6 },
attribute resource_set_notafter { xsd:dateTime },
attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
pattern="rsync://.+"} }?,
element certificate {
attribute cert_url { cert_url },
attribute req_resource_set_as { resource_set_as }?,
attribute req_resource_set_ipv4 { resource_set_ip4 }?,
attribute req_resource_set_ipv6 { resource_set_ip6 }?,
base64_binary
}*,
element issuer { base64_binary }
}
issue_request = element request { attribute class_name { class_name }, attribute req_resource_set_as { resource_set_as }?, attribute req_resource_set_ipv4 { resource_set_ip4 }?, attribute req_resource_set_ipv6 { resource_set_ip6 }?,
issue_request=元素请求{attribute class_name{class_name}，属性req_resource_set_as}，属性req_resource_set_as}，属性req_set_ipv4{resource_set_ip4}，属性req_resource_set_set_ipv6{resource_set_ip6}？，
base64_binary } issue_response = class
base64\u binary}问题\u响应=类
revoke_request = revocation revoke_response = revocation
撤销请求=撤销撤销响应=撤销
revocation = element key {
attribute class_name { class_name },
attribute ski { ski }
}
revocation = element key {
attribute class_name { class_name },
attribute ski { ski }
}
error_response =
element status { xsd:positiveInteger { maxInclusive="9999" } },
element description { attribute xml:lang { xsd:language },
xsd:string { maxLength="1024" } }*
}
error_response =
element status { xsd:positiveInteger { maxInclusive="9999" } },
element description { attribute xml:lang { xsd:language },
xsd:string { maxLength="1024" } }*
}
This protocol supports the maintenance of resource certificates that the issuer issues for a subject in certifying resources that have been allocated or assigned by the issuer to the subject [RFC6480]. This protocol assumes that the issuer and subject are known to each other and have exchanged credentials so as to support the mutual recognition of the digital signatures used to sign the CMS messages. The mechanisms used to perform the associated credential exchange are not described in this specification.
此协议支持维护发卡机构为主题颁发的资源证书，以证明发卡机构已分配或分配给主题的资源[RFC6480]。该协议假设发卡机构和主体彼此已知，并交换了凭证，以支持用于签署CMS消息的数字签名的相互识别。本规范中未描述用于执行相关凭证交换的机制。
The protocol is a minimal query/response protocol that imposes strict serialization on each query/response transaction, reducing the potential for the subject and the issuer to lose synchronization over the issued certificate state.
该协议是一个最小查询/响应协议，它对每个查询/响应事务施加严格的序列化，从而减少主题和颁发者在已颁发证书状态下失去同步的可能性。
Validation of protocol objects (Section 3.1.2) requires that the CMS signing-time value be greater than or equal to the time value passed in the previously valid protocol objects that were passed from the same originator to the same recipient. If a party inadvertently sends a valid message (protocol object) with a signing time in the future, then subsequent messages from the party in the same client/server context can use signing-time value consistent with this validation constraint, such that the signing times contained in subsequent messages are greater than or equal to the signing-time value of the previous valid message. (Note that it is not a normative requirement that the signing time be precisely aligned to a time of day clock, thus permitting arbitrarily large clock skew values in the context of this protocol message exchange.) If the client and server wish to reset the signing time to a mutually agreed
协议对象的验证（第3.1.2节）要求CMS签名时间值大于或等于从同一发起人传递给同一接收人的先前有效协议对象中传递的时间值。如果一方在将来无意中发送了具有签名时间的有效消息（协议对象），则来自同一客户机/服务器上下文中该方的后续消息可以使用与此验证约束一致的签名时间值，使后续消息中包含的签名时间大于或等于先前有效消息的签名时间值。（请注意，签名时间与一天中的时钟精确对齐不是规范性要求，因此允许在此协议消息交换上下文中任意大的时钟偏差值。）如果客户端和服务器希望将签名时间重置为双方同意的时间
value, then, (as noted in Section 2) the interactions between the client and the server to achieve this outcome are not encompassed in this protocol.
那么，（如第2节所述）客户端和服务器之间为实现此结果而进行的交互不包含在本协议中。
IANA has registered the following media type:
IANA已注册以下媒体类型：
application/rpki-updown
应用程序/rpki向上向下
Type name: application
Subtype name: rpki-updown
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Provisioning Protocol
Message, as defined in this document.
Interoperability considerations: None
Published specification: This document
Applications that use this media type: HTTP [RFC5652]
Additional information:
Magic number(s): None
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Restrictions on usage: Only to be used as an RPKI Provisioning
Protocol message object type, as defined in this document.
Author: Geoff Huston <gih@apnic.net>
Change controller: Geoff Huston <gih@apnic.net>
Type name: application
Subtype name: rpki-updown
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries an RPKI Provisioning Protocol
Message, as defined in this document.
Interoperability considerations: None
Published specification: This document
Applications that use this media type: HTTP [RFC5652]
Additional information:
Magic number(s): None
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
Geoff Huston <gih@apnic.net>
Intended usage: COMMON
Restrictions on usage: Only to be used as an RPKI Provisioning
Protocol message object type, as defined in this document.
Author: Geoff Huston <gih@apnic.net>
Change controller: Geoff Huston <gih@apnic.net>
The authors would like to acknowledge the valued contributions from Russ Housley, Steve Kent, Randy Bush, George Michaelson, Robert Kisteleki, Tim Bruijnzeels, and Carsten Bormann in the preparation of the protocol described in this document.
作者要感谢Russ Housley、Steve Kent、Randy Bush、George Michaelson、Robert Kisteleki、Tim Bruijnzeels和Carsten Bormann在本文件所述方案编制过程中做出的宝贵贡献。
[ISO.8601:2004] ISO, "ISO 8601:2004 Representation of dates and Times", 2004.
[ISO.8601:2004]ISO，“ISO 8601:2004日期和时间的表示”，2004年。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[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月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 57812010年2月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[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月。
[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月。
[X.509-88] CCITT, "Recommendation X.509: The Directory-Authentication Framework", 1988.
[X.509-88]CCITT，“建议X.509：目录认证框架”，1988年。
[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月。
[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月。
[XML] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[XML]Bray，T.，Hollander，D.，Layman，A.，Tobin，R.，和H.Thompson，“XML 1.0中的名称空间（第三版）”，万维网联盟建议REC-XML-names-20091208，2009年12月<http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
Authors' Addresses
作者地址
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
URI: http://www.apnic.net
EMail: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans APNIC
罗伯特·卢曼斯呼吸暂停综合征
EMail: robertl@apnic.net
URI: http://www.apnic.net
EMail: robertl@apnic.net
URI: http://www.apnic.net
Byron Ellacott APNIC
拜伦·埃拉科特·阿尼奇
EMail: bje@apnic.net
URI: http://www.apnic.net
EMail: bje@apnic.net
URI: http://www.apnic.net
Rob Austein Internet Systems Consortium
Rob Austein互联网系统联合会
EMail: sra@hactrn.net
EMail: sra@hactrn.net