Network Working Group M. Myers
Request for Comments: 2797 VeriSign
Category: Standards Track X. Liu
Cisco
J. Schaad
Microsoft
J. Weinstein
April 2000
Network Working Group M. Myers
Request for Comments: 2797 VeriSign
Category: Standards Track X. Liu
Cisco
J. Schaad
Microsoft
J. Weinstein
April 2000
Certificate Management Messages over CMS
CMS上的证书管理消息
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community:
本文档定义了使用CMS（CMC）的证书管理协议。该协议解决了Internet PKI社区内的两个迫切需要：
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys.
1. 需要基于[CMS]和[PKCS10]的公钥认证产品和服务的接口，以及2。[SMIMEV3]中需要使用Diffie-Hellman公钥的DSA签名证书的证书注册协议。
A small number of additional services are defined to supplement the core certificate request service.
定义了少量附加服务来补充核心证书请求服务。
Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.
在本规范中，术语CMS同时指[CMS]和[PKCS7]。对于signedData和envelopedData，CMS都是PKCS7的超集。通常，本文档中PKCS7的使用与提供PKCS7语法超集的加密消息语法[CMS]一致。术语CMC指本规范。
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 [RFC 2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
- The protocol is to be based as much as possible on the existing CMS, PKCS#10 and CRMF specifications. - The protocol must support the current industry practice of a PKCS#10 request followed by a PKCS#7 response as a subset of the protocol. - The protocol needs to easily support the multi-key enrollment protocols required by S/MIME and other groups. - The protocol must supply a way of doing all operations in a single-round trip. When this is not possible the number of round trips is to be minimized. - The protocol will be designed such that all key generation can occur on the client. - The mandatory algorithms must superset the required algorithms for S/MIME. - The protocol will contain POP methods. Optional provisions for multiple-round trip POP will be made if necessary. - The protocol will support deferred and pending responses to certificate request for cases where external procedures are required to issue a certificate. - The protocol needs to support arbitrary chains of local registration authorities as intermediaries between certificate requesters and issuers.
- 协议应尽可能基于现有的CMS、PKCS#10和CRMF规范。-协议必须支持PKCS#10请求，然后PKCS#7响应作为协议子集的当前行业实践。-该协议需要轻松支持S/MIME和其他组所需的多密钥注册协议。-协议必须提供在一次往返中执行所有操作的方法。如果不可能，则应尽量减少往返次数。-协议的设计应确保所有密钥生成都可以在客户端进行。-强制算法必须是S/MIME所需算法的超集。-协议将包含POP方法。如有必要，将为多次往返POP制定可选规定。-对于需要外部程序颁发证书的情况，协议将支持对证书请求的延迟和挂起响应。-该协议需要支持本地注册机构作为证书请求者和颁发者之间的中介的任意链。
An enrollment transaction in this specification is generally composed of a single round trip of messages. In the simplest case an enrollment request is sent from the client to the server and an enrollment response is then returned from the server to the client. In some more complicated cases, such as delayed certificate issuance and polling for responses, more than one round trip is required.
本规范中的注册事务通常由单个消息往返组成。在最简单的情况下，注册请求从客户端发送到服务器，然后注册响应从服务器返回到客户端。在一些更复杂的情况下，例如延迟证书颁发和轮询响应，需要不止一次往返。
This specification supports two different request messages and two different response messages.
此规范支持两种不同的请求消息和两种不同的响应消息。
Public key certification requests can be based on either the PKCS10 or CRMF object. The two different request messages are (a) the bare PKCS10 (in the event that no other services are needed), and (b) the PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a PKIData object.
公钥证书请求可以基于PKCS10或CRMF对象。这两种不同的请求消息是（a）裸PKCS10（在不需要其他服务的情况下），和（b）作为PKDATA对象的一部分包装在CMS封装中的PKCS10或CRMF消息。
Public key certification responses are based on the CMS signedData object. The response may be either (a) a degenerate CMS signedData object (in the event no other services are needed), or (b) a ResponseBody object wrapped in a CMS signedData object.
公钥证书响应基于CMS signedData对象。响应可以是（a）退化的CMS signedData对象（如果不需要其他服务），或者（b）封装在CMS signedData对象中的ResponseBody对象。
No special services are provided for doing either renewal (new certificates with the same key) or re-keying (new certificates on new keys) of clients. Instead a renewal/re-key message looks the same as any enrollment message, with the identity proof being supplied by existing certificates from the CA.
对于客户端的续订（使用相同密钥的新证书）或重新设置密钥（使用新密钥的新证书），不提供任何特殊服务。相反，续订/重设密钥消息看起来与任何注册消息相同，身份证明由CA的现有证书提供。
A provision exists for Local Registration Authorities (LRAs) to participate in the protocol by taking client enrollment messages, wrapping them in a second layer of enrollment message with additional requirements or statements from the LRA and then passing this new expanded request on to the Certification Authority.
本地注册机构（LRA）可以通过获取客户端注册消息，将其包装在注册消息的第二层中，并使用LRA的附加要求或声明，然后将此新的扩展请求传递给证书颁发机构，从而参与协议。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS is not meant to imply an email-based transport.
本规范不对底层传输机制进行任何假设。CMS的使用并不意味着基于电子邮件的传输。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/CRL retrieval.
本规范提供的可选服务包括事务管理、重播检测（通过nonce）、延迟证书颁发、证书撤销请求和证书/CRL检索。
There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage:
本文件中使用了几个不同的术语、缩写和首字母缩略词，我们在此处对其进行了定义，以便于使用和保持一致性：
"End-Entity" (EE) refers to the entity that owns a key pair and for whom a certificate is issued. "LRA" or "RA" refers to a (Local) Registration Authority. A registration authority acts as an intermediary between an End-Entity and a Certification Authority. Multiple RAs can exist between the End-Entity and the Certification Authority. "CA" refers to a Certification Authority. A Certification Authority is the entity that performs the actual issuance of a certificate. "Client" refers to an entity that creates a PKI request. In this document both RAs and End-Entities can be clients. "Server" refers to the entities that process PKI requests and create PKI responses. CAs and RAs can be servers in this document. "PKCS#10" refers the Public Key Cryptography Standard #10. This is one of a set of standards defined by RSA Laboratories in the 1980s. PKCS#10 defines a Certificate Request Message syntax. "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. We are using certificate request message format defined in this document as part of our management protocol. "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.
“终端实体”（EE）指拥有密钥对并为其颁发证书的实体。“LRA”或“RA”指（当地）注册机构。注册机构充当最终实体和认证机构之间的中介机构。终端实体和证书颁发机构之间可以存在多个RAs。“CA”指证书颁发机构。证书颁发机构是执行证书实际颁发的实体。“客户端”是指创建PKI请求的实体。在本文档中，RAs和终端实体都可以是客户机。“服务器”是指处理PKI请求并创建PKI响应的实体。CAs和RAs可以是本文档中的服务器。“PKCS#10”是指公钥密码标准#10。这是RSA实验室在20世纪80年代定义的一组标准之一。PKCS#10定义了证书请求消息语法。“CRMF”指证书请求消息格式RFC[CRMF]。我们使用本文档中定义的证书请求消息格式作为管理协议的一部分。“CMS”指加密消息语法RFC[CMS]。本文档提供了基本的加密服务，包括加密和签名（使用和不使用密钥管理）。
"POP" is an acronym for "Proof of Possession". POP refers to a value that can be used to prove that the private key corresponding to a public key is in the possession and can be used by an end-entity. "Transport wrapper" refers to the outermost CMS wrapping layer.
“POP”是“持有证明”的首字母缩略词。POP是指一个值，该值可用于证明与公钥相对应的私钥处于拥有状态，并且可由终端实体使用。“传输包装”是指最外层的CMS包装层。
Figure 1 shows the Simple Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.1 and 4.3 below.
图1显示了简单的注册请求和响应消息。这些信息的内容详见下文第4.1节和第4.3节。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS "certs-only" |
+----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
+----------+ +------------------+
| PKCS #10 | | CMS "certs-only" |
+----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Request and Response Messages
图1：简单的PKI请求和响应消息
Full PKI Request Full PKI Response
----------------------- ------------------------
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| signed (keypair | | |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| signed (keypair | | |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
Figure 2: Full PKI Request and Response Messages
图2：完整的PKI请求和响应消息
Figure 2 shows the Full Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.2 and 4.4 below.
图2显示了完整注册请求和响应消息。这些信息的内容详见下文第4.2节和第4.4节。
This section covers each of the different elements that may be used to construct enrollment request and enrollment response messages. Section 4 will cover how to build the enrollment request and response messages.
本节介绍可用于构造注册请求和注册响应消息的每个不同元素。第4节将介绍如何构建注册请求和响应消息。
The new content object PKIData has been defined for this protocol. This new object is used as the body of the full PKI request message. The new body is identified by:
已为此协议定义了新的内容对象PKIData。此新对象用作完整PKI请求消息的主体。新机构的标识如下：
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
The ASN.1 structure corresponding to this new content type is:
与此新内容类型对应的ASN.1结构为：
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 5. As control sequences are defined by OIDs, other parties can define additional control attributes. Unrecognized OIDs MUST result in no part of the request being successfully processed.
--controlSequence由一系列控件属性组成。本文件中定义的控制属性见第5节。由于控制序列由OID定义，其他方可以定义其他控制属性。无法识别的OID不得导致成功处理请求的任何部分。
-- reqSequence consists of a sequence of certificate requests. The certificate requests can be either a CertificateRequest (PKCS10 request) or a CertReqMsg. Details on each of these request types are found in sections 3.3.1 and 3.3.2 respectively.
--reqSequence由一系列证书请求组成。证书请求可以是CertificateRequest（PKCS10请求）或CertReqMsg。有关每种请求类型的详细信息，请分别参见第3.3.1节和第3.3.2节。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
--cmsSequence由一系列[CMS]消息对象组成。此协议仅使用EnvelopedData、SignedData和EncryptedData。详见第3.6节。
-- otherMsgSequence allows for other arbitrary data items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. See section 3.7 for more details.
--otherMsgSequence允许将其他任意数据项放入注册协议中。{OID，any}对值允许任意定义材质。数据对象放在此处，而控制对象放在controlSequence字段中。详见第3.7节。
The new content object ResponseBody has been defined for this protocol. This new object is used as the body of the full PKI response message. The new body is identified by:
已为此协议定义了新的内容对象响应库。此新对象用作完整PKI响应消息的主体。新机构的标识如下：
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
The ASN.1 structure corresponding to this body content type is:
与此正文内容类型对应的ASN.1结构为：
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 3.5. Other parties can define additional control attributes.
--controlSequence由一系列控件属性组成。本文件中定义的控制属性见第3.5节。其他方可以定义其他控制属性。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
--cmsSequence由一系列[CMS]消息对象组成。此协议仅使用EnvelopedData、SignedData和EncryptedData。详见第3.6节。
-- otherMsgSequence allows for other arbitrary items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. See section 3.7 for more details.
--otherMsgSequence允许将其他任意项放入注册协议中。{OID，any}对值允许任意定义材质。数据对象放在此处，而控制对象放在controlSequence字段中。详见第3.7节。
Certification Requests are based on either PKCS10 or CRMF messages. Section 3.3.1 specifies mandatory and optional requirements for clients and servers dealing with PKCS10 request messages. Section 3.3.2 specifies mandatory and optional requirements for clients and servers dealing with CRMF request messages.
认证请求基于PKCS10或CRMF消息。第3.3.1节规定了处理PKCS10请求消息的客户端和服务器的强制性和可选要求。第3.3.2节规定了处理CRMF请求消息的客户端和服务器的强制性和可选要求。
Servers MUST be able to understand and process PKCS10 request bodies. Clients MUST produce a PKCS10 request body when using the Simple Enrollment Request message. Clients MAY produce a PKCS10 request body when using the Full Enrollment Request message.
服务器必须能够理解和处理PKCS10请求主体。使用简单注册请求消息时，客户端必须生成PKCS10请求正文。使用完整注册请求消息时，客户端可能会生成PKCS10请求正文。
When producing a PKCS10 request body, clients MUST produce a PKCS10 message body containing a subject name and public key. Some certification products are operated using a central repository of information to assign subject names upon receipt of a public key for certification. To accommodate this mode of operation, the subject name in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject name MAY reject such requests. If rejected and a response is returned, the CA MUST respond with the failInfo attribute of badRequest.
生成PKCS10请求正文时，客户端必须生成包含主题名称和公钥的PKCS10消息正文。一些认证产品使用中央信息库进行操作，以便在收到用于认证的公钥时分配主题名称。为了适应这种操作模式，CertificationRequest中的使用者名称可以为NULL，但必须存在。接收主体名称为空的CertificationRequest的CA可能会拒绝此类请求。如果拒绝并返回响应，CA必须使用badRequest的failInfo属性进行响应。
The client MAY incorporate one or more standard X.509 v3 extensions in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq attribute is defined as
客户端可以在任何PKCS10请求中合并一个或多个标准X.509 v3扩展作为ExtensionReq属性。ExtensionReq属性定义为
ExtensionReq ::= SEQUENCE OF Extension
ExtensionReq ::= SEQUENCE OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is identified by {pkcs-9 14}.
其中，扩展从[PKEXCERT]导入，扩展请求由{pkcs-9 14}标识。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process other V3 X.509 extensions transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example changing key usage from key exchange to signing.) If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST respond with the failInfo attribute of unsupportedExt.
服务器必须能够处理[PKIXCERT]中定义的所有扩展。服务器不需要能够处理使用此协议传输的其他V3 X.509扩展，也不需要能够处理其他专用扩展。服务器不需要将所有客户端请求的扩展放入证书中。允许服务器修改客户端请求的扩展。服务器不得更改扩展以使客户端请求的扩展的原始意图无效。（例如，将密钥使用从密钥交换更改为签名。）如果由于无法处理请求的扩展而拒绝认证请求并返回响应，则服务器必须使用failInfo属性unsupportedExt进行响应。
Servers MUST be able to understand and process CRMF request body. Clients MAY produce a CRMF message body when using the Full Enrollment Request message.
服务器必须能够理解和处理CRMF请求体。当使用完整注册请求消息时，客户端可能会生成CRMF消息正文。
This memo imposes the following additional changes on the construction and processing of CRMF messages:
本备忘录对CRMF消息的构造和处理进行了以下附加更改：
- When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate. As in the case of PKCS10 requests, the subject may be encoded as NULL, but MUST be present. - In general, when both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override any CRMF control. - The regInfo field MUST NOT be used on a CRMF message. Equivalent functionality is provided in the regInfo control attribute (section 5.12). - The indirect method of proving POP is not supported in this protocol. One of the other methods (including the direct method described in this document) MUST be used instead if POP is desired. The value of encrCert in SubsequentMessage MUST NOT be used.
- 在完整注册请求消息中使用CRMF消息正文时，每条CRMF消息必须在CertTemplate中同时包含subject和publicKey字段。与PKCS10请求的情况一样，主题可以编码为NULL，但必须存在。-通常，当CRMF和CMC控件都具有同等功能时，应使用CMC控件。CMC控件必须覆盖任何CRMF控件。-regInfo字段不得用于CRMF消息。regInfo控制属性（第5.12节）中提供了等效功能本协议不支持证明POP的间接方法。如果需要POP，则必须使用其他方法之一（包括本文档中描述的直接方法）。不能使用SubsequentMessage中encrCert的值。
- Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
- 由于subject和PublicKeyValue始终存在，因此在计算POPSigningKey的值时不得使用PopSigningKeyInput。
A server is not required to use all of the values suggested by the client in the certificate template. Servers MUST be able to process all extensions defined in [PXIXCERT]. Servers are not required to be able to process other V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example change key usage from key exchange to signing.) If a certificate request is denied due to the inability to handle a requested extension, the server MUST respond with a failInfo attribute of unsupportedExt.
服务器不需要使用客户端在证书模板中建议的所有值。服务器必须能够处理[PXIXCERT]中定义的所有扩展。服务器不需要能够处理使用此协议传输的其他V3 X.509扩展，也不需要能够处理其他专用扩展。允许服务器修改客户端请求的扩展。服务器不得更改扩展以使客户端请求的扩展的原始意图无效。（例如，将密钥使用从密钥交换更改为签名。）如果由于无法处理请求的扩展而拒绝证书请求，则服务器必须使用failInfo属性unsupportedExt进行响应。
Part of a certification request is a signature over the request; Diffie-Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value.
认证请求的一部分是对请求的签名；Diffie-Hellman是一种密钥协商算法，不能用于直接生成所需的签名对象。[DH-POP]提供两种方法来生成必要的签名值。本文档还定义了一种签名算法，该算法不提供POP值，但可用于生成必要的签名值。
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
密钥管理（加密/解密）私钥不能始终用于生成某种类型的签名值，因为它们可以位于仅解密的设备中。认证请求要求填充签名字段。本节提供了专门用于此目的的签名算法。以下对象标识符和签名值用于标识此签名类型：
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
NoSignatureValue ::= OCTET STRING
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in section 5.7 MUST be used.
id alg NOSIGNATION的参数必须存在，并且必须编码为NULL。NoSignatureValue包含证书请求的哈希。重要的是要认识到，没有与此签名类型相关联的安全性。如果此签名类型在认证请求中，且认证机构策略要求提供私钥拥有证明，则必须使用第5.7节中定义的POP机制。
CMC compliant implementations MUST support section 5 of [DH-POP].
符合CMC的实施必须支持[DH-POP]的第5节。
CMC compliant implementations MAY support section 4 of [DH-POP].
符合CMC的实施可能支持[DH-POP]的第4节。
Each element of a PKIData or PKIResponse message has an associated body part identifier. The Body Part Identifier is a 4-octet integer encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartId field of the other objects. The Body Part Identifier MUST be unique within a single PKIData or PKIResponse object. Body Part Identifiers can be duplicated in different layers (for example a CMC message embedded within another). The Body Part Id of zero is reserved to designate the current PKIData object. This value is used in control attributes such as the Add Extensions Control in the pkiDataReference field to refer to a request in the current PKIData object.
PKIData或PKIResponse消息的每个元素都有一个关联的正文部分标识符。主体部分标识符是在CertReqMsg对象的CertReqId字段（在标记请求中）或其他对象的bodyPartId字段中编码的4个八位整数。主体部分标识符在单个PKIData或PKIResponse对象中必须是唯一的。身体部位标识符可以在不同的层中复制（例如，嵌入在另一层中的CMC消息）。保留零的主体部分Id以指定当前PKIData对象。此值在控件属性（如pkiDataReference字段中的Add Extensions控件）中使用，以引用当前PKIData对象中的请求。
Some control attribute, such as the CMC Status Info attribute, will also use Body Part Identifiers to refer to elements in the previous message. This allows an error to be explicit about the attribute or request to which the error applies.
某些控件属性（如CMC Status Info属性）也将使用身体部位标识符来引用上一条消息中的元素。这允许错误明确表示错误应用到的属性或请求。
The overall control flow of how a message is processed in this document is based on the control attributes. Each control attribute consists of an object identifier and a value based on the object identifier.
在此文档中如何处理消息的总体控制流基于控制属性。每个控件属性由对象标识符和基于对象标识符的值组成。
Servers MUST fail the processing of an entire PKIData message if any included control attribute is not recognized. The response MUST be the error badRequest and bodyList MUST contain the bodyPartID of the invalid or unrecognized control attribute.
如果未识别任何包含的控件属性，则服务器必须无法处理整个PKIData消息。响应必须是错误badRequest，bodyList必须包含无效或无法识别的控件属性的bodyPartID。
The syntax of a control attribute is
控件属性的语法是
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
-- bodyPartId is a unique integer that is used to reference this control attribute. The id of 0 is reserved for use as the reference to the current PKIData object.
--bodyPartId是用于引用此控件属性的唯一整数。0的id保留为用作对当前PKIData对象的引用。
-- attrType is the OID defining the associated data in attrValues
--attrType是在AttrValue中定义关联数据的OID
-- attrValues contains the set of data values used in processing the control attribute.
--attrValues包含处理控件属性时使用的数据值集。
The set of control attributes that are defined by this memo are found in section 5.
本备忘录定义的控制属性集见第5节。
The cmsSequence field of the PKIRequest and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is
PKI请求和PKI响应消息的cmsSequence字段包含零个或多个标记的内容信息对象。此结构的语法为
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
-- bodyPartId is a unique integer that is used to reference this content info object. The id of 0 is reserved for use as the reference to the current PKIData object.
--bodyPartId是用于引用此内容信息对象的唯一整数。0的id保留为用作对当前PKIData对象的引用。
-- contentInfo contains a ContentInfo object (defined in [CMS]). The three contents used in this location are SignedData, EnvelopedData and Data.
--contentInfo包含一个contentInfo对象（在[CMS]中定义）。此位置中使用的三个内容是SignedData、EnvelopedData和Data。
EnvelopedData provides for shrouding of data. Data allows for general transport of unstructured data.
EnvelopedData提供对数据的覆盖。数据允许非结构化数据的一般传输。
The SignedData object from [CMS] is also used in this specification to provide for authentication as well as serving as the general transport wrapper of requests and responses.
[CMS]中的SignedData对象在本规范中还用于提供身份验证，以及用作请求和响应的通用传输包装器。
The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as a wrapper for a PKIData as part of the enrollment request message. The signedData object is also used as the outer part of an enrollment response message.
构造注册消息时，signedData对象在两个不同的位置使用。signedData对象用作PKIData的包装器，作为注册请求消息的一部分。signedData对象还用作注册响应消息的外部部分。
For the enrollment response the signedData wrapper allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs for the enrollment request. If no data is being returned beyond the certificates, no signerInfo objects are placed in the signedData object.
对于注册响应，signedData包装器允许服务器对返回的数据（如果存在）进行签名，并携带注册请求的证书和CRL。如果在证书之外没有返回任何数据，则不会在signedData对象中放置signerInfo对象。
EnvelopedData is the primary method of providing confidentiality for sensitive information in this protocol. The protocol currently uses EnvelopedData to provide encryption of an entire request (see section 4.5). The envelopedData object would also be used to wrap private key material for key archival.
信封数据是本协议中为敏感信息提供机密性的主要方法。该协议目前使用EnvelopedData对整个请求进行加密（见第4.5节）。envelopedData对象还将用于包装密钥存档的私钥材料。
Servers MUST implement envelopedData according to [CMS]. There is an ambiguity (about encrypting content types other than id-data) in the PKCS7 specification that has lead to non-interoperability.
服务器必须根据[CMS]实现envelopedData。PKCS7规范中存在歧义（关于加密除id数据以外的内容类型），导致互操作性不强。
The other message body portion of the message allows for arbitrary data objects to be carried as part of a message. This is intended to contain data that is not already wrapped in a CMS contentInfo object. The data is ignored unless a control attribute references the data by bodyPartId.
消息的另一个消息体部分允许作为消息的一部分携带任意数据对象。这旨在包含尚未包装在CMS contentInfo对象中的数据。除非控件属性按bodyPartId引用数据，否则将忽略该数据。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- bodyPartID contains the unique id of this object
--bodyPartID包含此对象的唯一id
-- otherMsgType contains the OID defining both the usage of this body part and the syntax of the value associated with this body part
--otherMsgType包含定义此正文部分的用法和与此正文部分关联的值的语法的OID
-- otherMsgValue contains the data associated with the message body part.
--otherMsgValue包含与消息正文部分关联的数据。
This section discusses the details of putting together the different enrollment request and response messages.
本节讨论将不同的注册请求和响应消息组合在一起的详细信息。
The simplest form of an enrollment request is a plain PKCS10 message. If this form of enrollment request is used for a private key that is capable of generating a signature, the PKCS10 MUST be signed with that private key. If this form of the enrollment request is used for a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be used.
注册请求的最简单形式是普通PKCS10消息。如果此形式的注册请求用于能够生成签名的私钥，则必须使用该私钥对PKCS10进行签名。如果此形式的注册请求用于D-H密钥，则必须使用[DH-POP]中描述的D-H POP机制。
Servers MUST support the Simple Enrollment Request message. If the Simple Enrollment Request message is used, servers MUST return the Simple Enrollment Response message (see Section 4.3) if the enrollment request is granted. If the enrollment request fails, the Full Enrollment Response MAY be returned or no response MAY be returned.
服务器必须支持简单注册请求消息。如果使用简单注册请求消息，如果注册请求被批准，服务器必须返回简单注册响应消息（参见第4.3节）。如果注册请求失败，则可能会返回完整注册响应或不返回响应。
Many advanced services specified in this memo are not supported by the Simple Enrollment Request message.
简单注册请求消息不支持此备忘录中指定的许多高级服务。
The Full Enrollment Request provides the most functionality and flexibility. Clients SHOULD use the Full Enrollment Request message when enrolling. Servers MUST support the Full Enrollment Request message. An enrollment response (full or simple as appropriate) MUST be returned to all Full Enrollment Requests.
完整注册请求提供了最大的功能性和灵活性。客户端在注册时应使用完整注册请求消息。服务器必须支持完整注册请求消息。必须向所有完整注册请求返回注册响应（完整或简单，视情况而定）。
The Full Enrollment Request message consists of a PKIData object wrapped in a signedData CMS object. The objects in the PKIData are ordered as follows:
完整注册请求消息由包裹在signedData CMS对象中的PKIData对象组成。PKI数据中的对象按如下顺序排列：
1. All Control Attributes, 2. All certification requests, 3. All CMS objects, 4. All other messages.
1. 所有控件属性，2。所有认证申请，3。所有CMS对象，4。所有其他消息。
Each element in a Full Enrollment Request is identified by a Body Part Identifier. If duplicate ids are found, the server MUST return the error badRequest with a bodyPartID of 0.
完整注册请求中的每个元素都由身体部位标识符标识。如果发现重复的ID，服务器必须返回bodyPartID为0的错误badRequest。
The signedData object wrapping the PKIData may be signed either by the private key material of the signature certification request, or by a previously certified signature key. If the private key of a signature certification request is being used, then: a) the certification request containing the corresponding public key MUST include a Subject Key Identifier extension request, b) the subjectKeyIdentifier form of signerInfo MUST be used, and
包装PKI数据的signedData对象可以由签名认证请求的私钥材料签名，或者由先前认证的签名密钥签名。如果正在使用签名认证请求的私钥，则：a）包含相应公钥的认证请求必须包括主题密钥标识符扩展请求，b）必须使用SignerinInfo的主题密钥标识符表单，以及
c) the value of the subjectKeyIdentifier form of signerInfo MUST be the Subject Key Identifier specified in the corresponding certification request.
c) signerInfo的subjectKeyIdentifier表单的值必须是相应证书请求中指定的subjectKeyIdentifier。
(The subjectKeyIdentifier form of signerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one signerInfo object in the signedData object.
（此处使用signerInfo的subjectKeyIdentifier表单，因为尚未为签名密钥颁发证书。）如果请求密钥用于签名，则signedData对象中必须只有一个signerInfo对象。
When creating a message to renew a certificate, the following should be taken into consideration:
创建续订证书的消息时，应考虑以下因素：
1. The identification and identityProof control statements are not required. The same information is provided by the use of an existing certificate from the CA when signing the enrollment message. 2. CAs and LRAs may impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for an entity be used. 3. A renewal message may occur either by creating a new set of keys, or by re-using an existing set of keys. Some CAs may prevent re-use of keys by policy. In this case the CA MUST return NOKEYREUSE as the failure code.
1. 不需要识别和识别车顶控制说明。签名注册消息时，使用CA的现有证书可以提供相同的信息。2.CAs和LRA可能会对所使用的签名证书施加附加限制。他们可能要求使用实体最近颁发的签名证书。3.续订消息可以通过创建一组新的密钥，也可以通过重新使用一组现有的密钥来发生。某些CA可能会通过策略阻止密钥的重复使用。在这种情况下，CA必须返回NOKEYREUSE作为故障代码。
Servers SHOULD use the simple enrollment response message whenever possible. Clients MUST be able to process the simple enrollment response message. The simple enrollment response message consists of a signedData object with no signerInfo objects on it. The certificates requested are returned in the certificate bag of the signedData object.
服务器应尽可能使用简单注册响应消息。客户端必须能够处理简单的注册响应消息。简单注册响应消息由一个signedData对象组成，该对象上没有signerInfo对象。请求的证书将在signedData对象的证书包中返回。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the certificate.
客户端不得假定证书是按任何顺序排列的。服务器应包括形成一个或多个自签名证书完整链所需的所有中间证书，而不仅仅是新颁发的证书。服务器还可以在CRL包中返回CRL。服务器可能包括自签名证书。客户端不能仅仅因为其存在于证书包中而隐式信任包含的自签名证书。如果客户端从服务器接收到新的自签名证书，客户端应提供一种机制，使用户能够显式信任该证书。
Servers MUST return full PKI response messages if a) a full PKI request message failed or b) additional services other than returning certificates are required. Servers MAY return full PKI responses with failure information for simple PKI requests. Following section 4.3 above, servers returning only certificates and a success status to the client SHOULD use the simple PKI response message.
如果a）完整PKI请求消息失败或b）需要返回证书以外的其他服务，则服务器必须返回完整PKI响应消息。对于简单的PKI请求，服务器可能会返回包含故障信息的完整PKI响应。按照上面的第4.3节，仅向客户端返回证书和成功状态的服务器应使用简单的PKI响应消息。
Clients MUST be able to process a full PKI response message.
客户端必须能够处理完整的PKI响应消息。
The full enrollment response message consists of a signedData object encapsulating a responseBody object. In a responseBody object all Control Attributes MUST precede all CMS objects. The certificates granted in an enrollment response are returned in the certificates field of the immediately encapsulating signedData object.
完整注册响应消息由封装ResponseBy对象的signedData对象组成。在ResponseBy对象中，所有控件属性必须位于所有CMS对象之前。注册响应中授予的证书将在立即封装的signedData对象的证书字段中返回。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains one ore more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the certificate.
客户端不得假定证书是按任何顺序排列的。服务器应包括形成完整链所需的所有中间证书一个或多个自签名证书，而不仅仅是新颁发的证书。服务器还可以在CRL包中返回CRL。服务器可能包括自签名证书。客户端不能仅仅因为其存在于证书包中而隐式信任包含的自签名证书。如果客户端从服务器接收到新的自签名证书，客户端应提供一种机制，使用户能够显式信任该证书。
There are occasions where a PKI request or response message must be encrypted in order to prevent any information about the enrollment from being accessible to unauthorized entities. This section describes the means used to encrypt a PKI message. This section is not applicable to a simple enrollment message.
有时，必须对PKI请求或响应消息进行加密，以防止未经授权的实体访问有关注册的任何信息。本节介绍用于加密PKI消息的方法。本节不适用于简单的注册邮件。
Confidentiality is provided by wrapping the PKI message (a signedData object) in a CMS EnvelopedData object. The nested content type in the EnvelopedData is id-signedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data objects. It is recommended that if an enveloped data layer is applied to a PKI message, a second signing layer be placed outside of the enveloped data layer. The following figure shows how this nesting would be done:
通过将PKI消息（signedData对象）包装到CMS EnvelopedData对象中来提供机密性。信封数据中的嵌套内容类型为id signedData。请注意，这与S/MIME不同，S/MIME在加密和签名数据对象之间放置了MIME层。建议将封装数据层应用于PKI消息时，将第二个签名层置于封装数据层之外。下图显示了如何进行嵌套：
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Options 1 and 2 provide the benefit of preventing leakage of sensitive data by encrypting the information. LRAs can remove the enveloped data wrapping, and replace or forward without further processing. Section 6 contains more information about LRA processing.
选项1和2通过加密信息提供了防止敏感数据泄漏的好处。LRA可以移除封装的数据包装，替换或转发，无需进一步处理。第6节包含有关LRA处理的更多信息。
PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST provided support for all three versions.
PKI消息可以在明文中加密或传输。服务器必须为所有三个版本提供支持。
Alternatively, an authenticated, secure channel could exist between the parties requiring encryption. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of PKI request and response messages.
或者，需要加密的各方之间可能存在经过身份验证的安全通道。客户机和服务器可以使用此类信道而不是上述技术来提供PKI请求和响应消息的安全、私有通信。
Control attributes are carried as part of both PKI requests and responses. Each control attribute is encoded as a unique Object Identifier followed by that data for the control attribute. The encoding of the data is based on the control attribute object identifier. Processing systems would first detect the OID and process the corresponding attribute value prior to processing the message body.
控制属性作为PKI请求和响应的一部分携带。每个控件属性都编码为唯一的对象标识符，后跟该控件属性的数据。数据的编码基于控件属性对象标识符。处理系统将首先检测OID并在处理消息体之前处理相应的属性值。
The following table lists the names, OID and syntactic structure for each of the control attributes documented in this memo.
下表列出了本备忘录中记录的每个控件属性的名称、OID和语法结构。
Control Attribute OID Syntax
----------------- ---------- --------------
cMCStatusInfo id-cmc 1 CMCStatusInfo
identification id-cmc 2 UTF8String
identityProof id-cmc 3 OCTET STRING
dataReturn id-cmc 4 OCTET STRING
transactionId id-cmc 5 INTEGER
senderNonce id-cmc 6 OCTET STRING
recipientNonce id-cmc 7 OCTET STRING
addExtensions id-cmc 8 AddExtensions
encryptedPOP id-cmc 9 EncryptedPOP
decryptedPOP id-cmc 10 DecryptedPOP
lraPOPWitness id-cmc 11 LraPOPWitness
getCert id-cmc 15 GetCert
getCRL id-cmc 16 GetCRL
revokeRequest id-cmc 17 RevokeRequest
regInfo id-cmc 18 OCTET STRING
responseInfo id-cmc 19 OCTET STRING
QueryPending id-cmc 21 OCTET STRING
idPOPLinkRandom id-cmc 22 OCTET STRING
idPOPLinkWitness id-cmc 23 OCTET STRING
idConfirmCertAcceptance id-cmc 24 CMCCertId
Control Attribute OID Syntax
----------------- ---------- --------------
cMCStatusInfo id-cmc 1 CMCStatusInfo
identification id-cmc 2 UTF8String
identityProof id-cmc 3 OCTET STRING
dataReturn id-cmc 4 OCTET STRING
transactionId id-cmc 5 INTEGER
senderNonce id-cmc 6 OCTET STRING
recipientNonce id-cmc 7 OCTET STRING
addExtensions id-cmc 8 AddExtensions
encryptedPOP id-cmc 9 EncryptedPOP
decryptedPOP id-cmc 10 DecryptedPOP
lraPOPWitness id-cmc 11 LraPOPWitness
getCert id-cmc 15 GetCert
getCRL id-cmc 16 GetCRL
revokeRequest id-cmc 17 RevokeRequest
regInfo id-cmc 18 OCTET STRING
responseInfo id-cmc 19 OCTET STRING
QueryPending id-cmc 21 OCTET STRING
idPOPLinkRandom id-cmc 22 OCTET STRING
idPOPLinkWitness id-cmc 23 OCTET STRING
idConfirmCertAcceptance id-cmc 24 CMCCertId
The CMC status info control is used in full PKI Response messages to return information on a client request. Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a response message. This statement uses the following ASN.1 definition:
CMC状态信息控件用于完整PKI响应消息，以返回客户端请求的信息。服务器可能会发出多个CMC状态信息控件，这些控件引用单个主体部分。客户端必须能够在响应消息中处理多个CMC状态信息控件。本声明使用以下ASN.1定义：
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
-- cMCStatus is described in section 5.1.1
--第5.1.1节描述了cMCStatus
-- bodyList contains the list of body parts in the request message to which this status information applies. If an error is being returned for a simple enrollment message, body list will contain a single integer of value '1'.
--bodyList包含应用此状态信息的请求消息中的车身零件列表。如果简单注册消息返回错误，则正文列表将包含一个值为“1”的整数。
-- statusString contains a string with additional description information. This string is human readable.
--statusString包含一个带有附加描述信息的字符串。此字符串是可读的。
-- failInfo is described in section 5.1.2. It provides a detailed error on what the failure was. This choice is present only if cMCStatus is failed.
--故障信息见第5.1.2节。它提供了关于失败原因的详细错误。仅当cMCStatus失败时，此选项才存在。
-- pendToken is the token to be used in the queryPending control attribute.
--pendToken是要在queryPending控件属性中使用的标记。
-- pendTime contains the suggested time the server wants to be queried about the status of the request.
--pendTime包含服务器希望查询请求状态的建议时间。
If the cMCStatus field is success, the CMC Status Info Control MAY be omitted unless it is only item in the response message. If no status exists for a certificate request or other item requiring processing, then the value of success is to be assumed.
如果cMCStatus字段为success，则可以省略CMC状态信息控件，除非它是响应消息中的唯一项。如果证书请求或其他需要处理的项目不存在状态，则假定成功值。
CMCStatus is a field in the CMCStatusInfo structure. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure of:
CMCStatus是CMCStatusInfo结构中的一个字段。此字段包含表示特定操作成功或失败的代码。CMCStatus的ASN.1结构为：
CMCStatus ::= INTEGER {
success (0),
-- request was granted
-- reserved (1),
-- not used, defined where the original structure was defined
failed (2),
-- you don't get what you want, more information elsewhere in
the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
-- pending may only be return for certificate request
operations.
noSupport (4),
-- the requested operation is not supported
confirmRequired (5)
CMCStatus ::= INTEGER {
success (0),
-- request was granted
-- reserved (1),
-- not used, defined where the original structure was defined
failed (2),
-- you don't get what you want, more information elsewhere in
the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
-- pending may only be return for certificate request
operations.
noSupport (4),
-- the requested operation is not supported
confirmRequired (5)
-- conformation using the idConfirmCertAcceptance control is
required
-- before use of certificate
}
-- conformation using the idConfirmCertAcceptance control is
required
-- before use of certificate
}
CMCFailInfo conveys information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfo传递与故障条件解释相关的信息。CMCFailInfo具有以下ASN.1结构：
CMCFailInfo ::= INTEGER {
badAlg (0)
-- Unrecognized or unsupported algorithm
badMessageCheck (1)
-- integrity check failed
badRequest (2)
-- transaction not permitted or supported
badTime (3)
-- Message time field was not sufficiently close to the system
time
badCertId (4)
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5)
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6)
-- Private key material must be supplied
badIdentity (7)
-- Identification Attribute failed to verify
popRequired (8)
-- Server requires a POP proof before issuing certificate
popFailed (9)
-- POP processing failed
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
CMCFailInfo ::= INTEGER {
badAlg (0)
-- Unrecognized or unsupported algorithm
badMessageCheck (1)
-- integrity check failed
badRequest (2)
-- transaction not permitted or supported
badTime (3)
-- Message time field was not sufficiently close to the system
time
badCertId (4)
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5)
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6)
-- Private key material must be supplied
badIdentity (7)
-- Identification Attribute failed to verify
popRequired (8)
-- Server requires a POP proof before issuing certificate
popFailed (9)
-- POP processing failed
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
Additional failure reasons MAY be defined for closed environments with a need.
可能会为需要的封闭环境定义其他故障原因。
Some CAs and LRAs require that a proof of identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most people are familiar with the request of a bank to provide your mother's maiden name as a form of identity proof.
一些CA和LRA要求在认证请求中包含身份证明。许多不同的方法都有不同程度的安全性和可靠性。大多数人都熟悉银行要求提供你母亲的婚前姓作为身份证明的要求。
CMC provides one method of proving the client's identity based on a shared secret between the certificate requestor and the verifying authority. If clients support full request messages, clients MUST implement this method of identity proof. Servers MUST provide this method and MAY also have a bilateral method of similar strength available.
CMC提供了一种基于证书请求者和验证机构之间的共享秘密来证明客户端身份的方法。如果客户端支持完整的请求消息，则客户端必须实现此身份验证方法。服务器必须提供这种方法，也可以提供类似强度的双边方法。
The CMC method starts with an out-of-band transfer of a token (the shared secret). The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
CMC方法从令牌（共享密钥）的带外传输开始。此令牌的分发超出了本文档的范围。然后，客户端使用此令牌进行身份验证，如下所示：
1. The reqSequence field of the PKIData object (encoded exactly as it appears in the request message including the sequence type and length) is the value to be validated. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret value. 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value of the identityProof attribute.
1. PKIData对象的reqSequence字段（编码与请求消息中显示的完全相同，包括序列类型和长度）是要验证的值。2.将计算令牌的SHA1哈希。3.然后，如[HMAC]中所述，使用步骤2中的令牌散列作为共享秘密值，在步骤1中生成的值上计算HMAC-SHA1值。4.然后将步骤3中的160位HMAC-SHA1结果编码为identityProof属性的值。
When the server verifies the identityProof attribute, it computes the HMAC-SHA1 value in the same way and compares it to the identityProof attribute contained in the enrollment request.
当服务器验证identityProof属性时，它以相同的方式计算HMAC-SHA1值，并将其与注册请求中包含的identityProof属性进行比较。
If a server fails the verification of an identityProof attribute and the server returns a response message, the failInfo attribute MUST be present in the response and MUST have a value of badIdentity.
如果服务器未能验证identityProof属性，并且服务器返回响应消息，则failInfo属性必须出现在响应中，并且其值必须为badIdentity。
Optionally, servers MAY require the inclusion of the unprotected identification attribute with an identification attribute. The identification attribute is intended to contain either a text string or a numeric quantity, such as a random number, which assists the server in locating the shared secret needed to validate the contents of the identityProof attribute. Numeric values MUST be converted to text string representations prior to encoding as UTF8-STRINGs in this attribute. If the identification control attribute is included in
或者，服务器可能需要将未受保护的标识属性包含在标识属性中。identification属性旨在包含文本字符串或数字量（如随机数），这有助于服务器定位验证identityProof属性内容所需的共享机密。在此属性中编码为UTF8字符串之前，必须将数值转换为文本字符串表示形式。如果标识控制属性包含在
the message, the derivation of the shared secret in step 2 is altered so that the hash of the concatenation of the token and the identity value are hashed rather than just the token.
消息中，步骤2中共享秘密的派生被更改，以便对令牌和标识值的串联哈希进行哈希处理，而不仅仅是对令牌进行哈希处理。
The shared secret between the end-entity and the identity verify is sometimes transferred using a hardware device that generates a series of tokens based on some shared secret value. The user can therefore prove their identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications:
终端实体和身份验证之间的共享密钥有时使用硬件设备传输，该硬件设备基于某个共享密钥值生成一系列令牌。因此，用户可以通过将此令牌以纯文本形式与名称字符串一起传输来证明其身份。通过以下修改，上述协议可与硬件共享秘密令牌生成设备一起使用：
1. The identification attribute MUST be included and MUST contain the hardware-generated token. 2. The shared secret value used above is the same hardware-generated token. 3. All certification requests MUST have a subject name and the subject name MUST contain the fields required to identify the holder of the hardware token device.
1. 必须包括标识属性，并且该属性必须包含硬件生成的令牌。2.上面使用的共享密钥值与硬件生成的令牌相同。3.所有认证请求必须具有使用者名称，使用者名称必须包含识别硬件令牌设备持有人所需的字段。
In a PKI Full Request message identity information about the creator/author of the message is carried in the signature of the CMS SignedData object containing all of the certificate requests. Proof-of-possession information for key pairs requesting certification, however, is carried separately for each PKCS#10 or CRMF message. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS#10 or CRMF request. For encryption-only keys the controls described in Section 5.7 below are used.) In order to prevent substitution-style attacks we must guarantee that the same entity generated both the POP and proof-of-identity information.
在PKI完整请求消息中，消息创建者/作者的身份信息包含在包含所有证书请求的CMS SignedData对象的签名中。但是，对于每个PKCS#10或CRMF消息，请求认证的密钥对的占有证明信息是单独携带的。（对于能够生成数字签名的密钥，POP由PKCS#10或CRMF请求上的签名提供。对于加密密钥，仅使用下面第5.7节中描述的控件。）为了防止替换式攻击，我们必须保证相同实体同时生成POP和身份证明信息。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 5.3.1) and shared-secret/subject DN matching (Section 5.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. The idea behind both mechanisms is to force the client to sign some data into each certificate request that can be directly associated with the shared-secret; this will defeat attempts to include certificate requests from different entities in a single Full PKI Request message.
本节描述了链接身份和POP信息的两种机制：以加密方式从共享机密（第5.3.1节）派生的见证值和共享机密/主题DN匹配（第5.3.2节）。客户端和服务器必须支持见证值技术。客户端和服务器可支持共享秘密/主题DN匹配或其他类似强度的双边技术。这两种机制背后的思想是强制客户机在每个证书请求中签署一些数据，这些数据可以直接与共享机密关联；这将阻止在单个完整PKI请求消息中包含来自不同实体的证书请求的尝试。
The first technique for doing identity-POP linking works by forcing the client to include a piece of information cryptographically-derived from the shared-secret token as a signed extension within each certificate request (PKCS#10 or CRMF) message. This technique is useful if null subject DNs are used (because, for example, the server can generate the subject DN for the certificate based only on the shared secret). Processing begins when the client receives the shared-secret token out-of-band from the server. The client then computes the following values:
第一种进行身份弹出链接的技术是，强制客户机在每个证书请求（PKCS#10或CRMF）消息中包含一条以加密方式从共享秘密令牌派生的信息，作为签名扩展。如果使用空主题DN，此技术非常有用（因为，例如，服务器可以仅基于共享机密生成证书的主题DN）。当客户端从服务器接收到带外共享秘密令牌时，处理开始。然后，客户端计算以下值：
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the random value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret. 4. The random value produced in Step 1 is encoded as the value of an idPOPLinkRandom control attribute. This control attribute MUST be included in the Full PKI Request message. 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value of an idPOPLinkWitness extension to the certificate request. a. For CRMF, idPOPLinkWitness is included in the controls section of the CertRequest structure. b. For PKCS#10, idPOPLinkWitness is included in the attributes section of the CertificationRequest structure.
1. 客户端生成一个随机字节字符串R，长度至少为512位。2.将计算令牌的SHA1哈希。3.然后，如[HMAC]中所述，使用步骤2中的令牌散列作为共享密钥，对步骤1中产生的随机值计算HMAC-SHA1值。4.在步骤1中产生的随机值被编码为idPOPLinkRandom control属性的值。此控制属性必须包含在完整的PKI请求消息中。5.步骤3的160位HMAC-SHA1结果被编码为证书请求的idPOPLinkWitness扩展的值。A.对于CRMF，IdpolinkWitness包含在CertRequest结构的控制部分中。B对于PKCS#10，idPOPLinkWitness包含在CertificationRequest结构的属性部分中。
Upon receipt, servers MUST verify that each certificate request contains a copy of the idPOPLinkWitness and that its value was derived in the specified manner from the shared secret and the random string included in the idPOPLinkRandom control attribute.
收到后，服务器必须验证每个证书请求是否包含idPOPLinkWitness的副本，以及其值是否以指定方式从共享机密和idPOPLinkRandom control属性中包含的随机字符串中派生。
The second technique for doing identity-POP linking is to link a particular subject distinguished name (subject DN) to the shared-secrets that are distributed out-of-band and to require that clients using the shared-secret to prove identity include that exact subject DN in every certificate request. It is expected that many client-server connections using shared-secret based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certificate request messages.)
进行身份POP链接的第二种技术是将特定的主题可分辨名称（主题DN）链接到带外分发的共享机密，并要求使用共享机密来证明身份的客户端在每个证书请求中都包含该确切的主题DN。预计许多使用基于共享秘密的身份证明的客户机-服务器连接将使用此机制。（通常不会从证书请求消息中忽略主题DN信息。）
When the shared secret is generated and transferred out-of-band to initiate the registration process (Section 5.2), a particular subject DN is also associated with the shared secret and communicated to the client. (The subject DN generated MUST be unique per entity in
当生成共享秘密并将其传输到带外以启动注册过程（第5.2节）时，特定的主体DN也与共享秘密关联并与客户端通信。（生成的主题DN在每个实体中必须是唯一的。）
accordance with CA policy; a null subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN.) When the client generates the Full PKI Request message, it MUST use these two pieces of information as follows:
符合CA政策；不能使用空的主题DN。通常的做法是将标识值作为主题DN的一部分。）当客户端生成完整的PKI请求消息时，它必须使用以下两条信息：
1. The client MUST include the specific subject DN that it received along with the shared secret as the subject name in every certificate request (PKCS#10 and/or CRMF) in the Full PKI Request. The subject names in the requests MUST NOT be null. 2. The client MUST include the identityProof control attribute (Section 5.2), derived from the shared secret, in the Full PKI Request.
1. 客户端必须在完整PKI请求中的每个证书请求（PKCS#10和/或CRMF）中包含它接收到的特定主题DN以及共享机密作为主题名称。请求中的主题名称不得为空。2.客户端必须在完整PKI请求中包含源自共享机密的identityProof控制属性（第5.2节）。
The server receiving this message MUST (a) validate the identityProof control attribute and then, (b) check that the subject DN included in each certificate request matches that associated with the shared secret. If either of these checks fails the certificate request MUST be rejected.
接收此消息的服务器必须（a）验证identityProof控件属性，然后（b）检查每个证书请求中包含的主题DN是否与共享机密相关联。如果其中任何一项检查失败，则必须拒绝证书请求。
In a renewal or re-key message, the subject DN in (a) the certificate referenced by the CMS SignerInfo object, and (b) all certificate requests within the request message MUST match according to the standard name match rules described in [PKIXCERT].
在续订或重设密钥消息中，（a）CMS SignerInfo对象引用的证书中的主题DN，以及（b）请求消息中的所有证书请求必须根据[PKIXCERT]中描述的标准名称匹配规则进行匹配。
The data return control attribute allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the enrollment response message. Data placed in a data return statement is considered to be opaque to the server. The same control is used for both requests and responses. If the data return statement appears in an enrollment message, the server MUST return it as part of the enrollment response message.
数据返回控制属性允许客户端向服务器发送任意数据（通常是某种类型的内部状态信息），并将数据作为注册响应消息的一部分返回。放置在数据返回语句中的数据对服务器来说是不透明的。相同的控件用于请求和响应。如果数据返回语句出现在注册消息中，服务器必须将其作为注册响应消息的一部分返回。
In the event that the information in the data return statement needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.
如果数据返回声明中的信息需要保密，预计客户会对包含的数据应用某种类型的加密，但其细节不在本规范的范围内。
An example of using this feature is for a client to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.
使用此功能的一个示例是，客户机放置一个标识符，标记私钥材料的确切来源。这可能是包含私钥的硬件设备的标识符。
The Add Extensions control attribute is used by LRAs in order to specify additional extensions that are to be placed on certificates. This attribute uses the following ASN.1 definition:
LRA使用“添加扩展控制”属性来指定要放置在证书上的其他扩展。此属性使用以下ASN.1定义：
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
-- pkiDataReference field contains the body part id of the embedded request message.
--pkiDataReference字段包含嵌入请求消息的主体部分id。
-- certReferences field is a list of references to one or more of the payloads contained within a PKIData. Each element of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest or the certReqId of the CertRequest within a CertReqMsg. By definition, the listed extensions are to be applied to every element referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the error badRequest is returned referencing this control attribute.
--certReferences字段是对PKIData中包含的一个或多个有效负载的引用列表。certReferences序列的每个元素必须等于TaggedCertificationRequest的bodyPartID或CertReqMsg中CertRequest的certReqId。根据定义，列出的扩展将应用于certReferences序列中引用的每个元素。如果找不到与bodyPartID对应的请求，则返回错误badRequest，并引用此控件属性。
-- extensions field contains the sequence of extensions to be applied to the referenced certificate requests.
--extensions字段包含要应用于引用的证书请求的扩展序列。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process every V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all LRA-requested extensions into a certificate. Servers are permitted to modify LRA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a failInfo attribute with the value of unsupportedExt.
服务器必须能够处理[PKIXCERT]中定义的所有扩展。服务器不需要能够处理使用此协议传输的每个V3 X.509扩展，也不需要能够处理其他专用扩展。服务器不需要将所有LRA请求的扩展放入证书中。允许服务器修改LRA请求的扩展。服务器不得更改扩展以反转客户端请求的扩展的含义。如果由于无法处理请求的扩展而拒绝认证请求并返回响应，则服务器必须返回值为unsupportedExt的failInfo属性。
If multiple Add Extensions statements exist in an enrollment message, the exact behavior is left up to the certificate issuer policy. However it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control attribute (as opposed to an "all or nothing" approach).
如果注册消息中存在多个Add Extensions语句，则具体行为由证书颁发者策略决定。但是，建议使用以下策略。这些规则将应用于addextensions控件属性中的单个扩展（与“全部或无”方法相反）。
1. If the conflict is within a single PKIData object, the certificate request would be rejected with an error of badRequest.
1. 如果冲突发生在单个PKIData对象内，则证书请求将被拒绝，错误为badRequest。
2. If the conflict is between different PKIData objects, the outermost version of the extension would be used (allowing an LRA to override the extension requested by the end-entyt).
2. 如果冲突发生在不同的PKIData对象之间，则将使用最外层版本的扩展（允许LRA覆盖end entyt请求的扩展）。
Transactions are identified and tracked using a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a message that completes the transaction. Servers correspondingly include received transaction identifiers in the response.
使用事务标识符识别和跟踪事务。如果使用，客户端将生成事务标识符并保留其值，直到服务器响应完成事务的消息。服务器相应地在响应中包括接收到的事务标识符。
The transactionId attribute identifies a given transaction. It is used between client and server to manage the state of an operation. Clients MAY include a transactionID attribute in request messages. If the original request contains a transactionID attribute, all subsequent request and response messages MUST include the same transactionID attribute. A server MUST use only transactionIds in the outermost PKIdata object. TransactionIds on inner PKIdata objects are for intermediate entities.
transactionId属性标识给定的事务。它在客户端和服务器之间用于管理操作的状态。客户端可以在请求消息中包含transactionID属性。如果原始请求包含transactionID属性，则所有后续请求和响应消息必须包含相同的transactionID属性。服务器只能在最外层的PKIdata对象中使用TransactionID。内部PKIdata对象上的TransactionID用于中间实体。
Replay protection can be supported through the use of sender and recipient nonces. If nonces are used, in the first message of a transaction, no recipientNonce is transmitted; a senderNonce is instantiated by the message originator and retained for later reference. The recipient of a sender nonce reflects this value back to the originator as a recipientNonce and includes it's own senderNonce. Upon receipt by the transaction originator of this message, the originator compares the value of recipientNonce to its retained value. If the values match, the message can be accepted for further security processing. The received value for senderNonce is also retained for inclusion in the next message associated with the same transaction.
可以通过使用发送方和接收方的nonce来支持重播保护。如果使用了nonce，则在事务的第一条消息中，不传输recipientNonce；SenderOnce由消息发起人实例化并保留以供以后参考。发送方nonce的接收方将此值作为recipientNonce反射回发起方，并包括其自己的发送方nonce。交易发起人收到此消息后，发起人将recipientNonce的值与其保留值进行比较。如果值匹配，则可以接受该消息以进行进一步的安全处理。SenderOnce的接收值也将保留，以便包含在与同一事务关联的下一条消息中。
The senderNonce and recipientNonce attribute can be used to provide application-level replay prevention. Clients MAY include a senderNonce in the initial request message. Originating messages include only a value for senderNonce. If a message includes a senderNonce, the response MUST include the transmitted value of the previously received senderNonce as recipientNonce and include new value for senderNonce. A server MUST use only nonces in the outermost PKIdata object. Nonces on inner PKIdata objects are for intermediate entities.
SenderOnce和recipientNonce属性可用于提供应用程序级重播预防。客户端可以在初始请求消息中包含SenderOnce。原始消息仅包含SenderOnce的值。如果消息包含SenderOnce，则响应必须包含以前接收的SenderOnce的传输值作为recipientNonce，并包含SenderOnce的新值。服务器只能在最外层的PKIdata对象中使用nonce。内部数据对象上的nonce用于中间实体。
Everything described in this section is optional to implement, for both servers and clients. Servers MAY require this POP method be used only if another POP method is unavailable. Servers SHOULD reject all requests contained within a PKIData if any required POP is missing for any element within the PKIData.
本节中描述的所有内容对于服务器和客户端都是可选的。只有在其他POP方法不可用时，服务器才可能要求使用此POP方法。如果PKIData中的任何元素缺少任何必需的POP，则服务器应拒绝包含在PKIData中的所有请求。
Many servers require proof that an entity requesting a certificate for a public key actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
许多服务器需要证明请求公钥证书的实体实际上拥有密钥对的相应私有组件。对于可以用作签名密钥的密钥，使用私钥对证书请求进行签名将作为该密钥对上的POP。对于只能用于加密操作的密钥，必须通过强制客户端解密值来执行POP。有关POP的详细讨论，请参见[CRMF]第5节。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct phases:
根据需要，POP for encryption only密钥不能在一次往返中完成，因为有四个不同的阶段：
1. Client tells the server about the public component of a new encryption key pair. 2. Server sends the client a POP challenge, encrypted with the presented public encryption key, which the client must decrypt. 3. Client decrypts the POP challenge and sends it back to the server. 4. Server validates the decrypted POP challenge and continues processing the certificate request.
1. 客户端告诉服务器新加密密钥对的公共组件。2.服务器向客户端发送一个POP质询，该质询使用提供的公钥加密，客户端必须解密该公钥。3.客户端解密POP质询并将其发送回服务器。4.服务器验证解密的POP质询并继续处理证书请求。
CMC defines two different attributes. The first deals with the encrypted challenge sent from the server to the user in step 2. The second deals with the decrypted challenge sent from the client to the server in step 3.
CMC定义了两个不同的属性。第一个处理步骤2中从服务器发送给用户的加密质询。第二个处理步骤3中从客户端发送到服务器的解密质询。
The encryptedPOP attribute is used to send the encrypted challenge from the server to the client. As such, it is encoded as a tagged attribute within the controlSequence of a ResponseBody. (Note that we assume that the message sent in Step 1 above is an enrollment request and that the response in step 2 is a Full Enrollment Response including a failureInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP attribute.)
encryptedPOP属性用于将加密质询从服务器发送到客户端。因此，它被编码为响应库的controlSequence中的标记属性。（请注意，我们假设上面步骤1中发送的消息是注册请求，步骤2中的响应是完整注册响应，包括failureInfo，指定明确需要POP，并在encryptedPOP属性中提供POP质询。）
EncryptedPOP ::= SEQUENCE {
EncryptedPOP ::= SEQUENCE {
request TaggedRequest, cms contentInfo, thePOPAlgID AlgorithmIdentifier, witnessAlgID AlgorithmIdentifier, witness OCTET STRING
请求标记请求、cms内容信息、POPALGID算法标识符、witnessAlgID算法标识符、witness八进制字符串
}
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
加密的POP算法的工作原理如下：
1. The server generates a random value y and associates it with the request. 2. The server returns the encrypted pop with the following fields set: a. request is the certificate request in the original request message (it is included here so the client need not key a copy of the request), b. cms is an EnvelopedData object, the content type being id-data and the content being the value y. If the certificate request contains a subject key identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IsserName MUST be encoded as NULL and the SerialNumber as the bodyPartId of the certificate request, c. thePOPAlgID contains the algorithm to be used in computing the return POP value, d. witnessAlgID contains the hash algorithm used on y to create the field witness, e. witness contains the hashed value of y. 3. The client decrypts the cms field to obtain the value y. The client computes H(y) using the witnessAlgID and compares to the value of witness. If the values do not compare or the decryption is not successful, the client MUST abort the enrollment process. The client aborts the process by sending a request message containing a CMCStatusInfo control attribute with failInfo value of popFailed. 4. The client creates the decryptedPOP as part of a new PKIData message. The fields in the decryptedPOP are: a. bodyPartID refers to the certificate request in the new enrollment message, b. thePOPAlgID is copied from the encryptedPOP, c. thePOP contains the possession proof. This value is computed by thePOPAlgID using the value y and request referenced in (4a). 5. The server then re-computes the value of thePOP from its cached value of y and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY re-issue a new challenge or MAY fail
1. 服务器生成一个随机值y并将其与请求关联。2.服务器返回加密的pop，并设置以下字段：a。请求是原始请求消息中的证书请求（它包含在这里，因此客户端不需要为请求的副本设置密钥），b。cms是一个EnvelopedData对象，内容类型为id数据，内容值为y。如果证书请求包含主题密钥标识符（SKI）扩展，则收件人标识符应为SKI。如果使用issuerAndSerialNumber表单，则必须将IsserName编码为NULL，将SerialNumber编码为证书请求的bodyPartId c。POPALGID包含用于计算返回POP值d的算法。witnessAlgID包含在y上用于创建字段见证的哈希算法，e。见证包含散列值y。3.客户端解密cms字段以获得值y。客户端使用witnessAlgID计算H（y），并与witness的值进行比较。如果值不进行比较或解密不成功，则客户端必须中止注册过程。客户端通过发送一条包含CMCStatusInfo控制属性（failInfo值为popFailed）的请求消息来中止该过程。4.客户端创建解密的POP作为新PKIData消息的一部分。解密POP中的字段为：a。bodyPartID是指新注册消息b中的证书请求。POPALGID是从加密POP c复制的。这本书包含了财产证明。该值由POPALGID使用值y和（4a）中引用的请求计算得出。5.然后，服务器根据缓存的y值和请求重新计算POP值，并与POP值进行比较。如果值不匹配，则服务器不得颁发证书。服务器可能会重新发出新质询或失败
the request altogether.
我完全同意你的请求。
When defining the algorithms for thePOPAlgID and witnessAlgID care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. Clients MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for thePOPAlgID. The value of y is used as the secret value in the HMAC algorithm and the request referenced in (4a) is used as the data. If y is greater than 64 bytes, only the first 64 bytes of y are used as the secret.
定义POPALGID和WITHENSINGALGID的算法时，必须注意确保WITHENSINGALGID的结果不是使用POPALGID简化计算的有用值。客户必须为witnessAlgID实施SHA-1。客户机必须为POPALGID实现HMAC-SHA1。y的值用作HMAC算法中的秘密值，并且（4a）中引用的请求用作数据。如果y大于64字节，则仅y的前64个字节用作机密。
One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. This describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.
上述算法的一个潜在问题是CA需要保持的状态量，以验证返回的POP值。这描述了通过将CA上保留的状态量减少为单个（或一小组）值来解决问题的多种可能方法之一。
1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.) 2. For certificate request R, server computes y = F(x,R). F can be, for example, HMAC-SHA1(x,R). All that's important for statelessness is that y be consistently computable with only known state constant x and function F, other inputs coming from the cert request structure. y should not be predictable based on knowledge of R, thus the use of a OWF like HMAC-SHA1.
1. 服务器生成随机种子x，在所有请求中保持不变。（x的值通常会定期更改，并在之后保留一段短时间。）2。对于证书请求R，服务器计算y=F（x，R）。例如，F可以是HMAC-SHA1（x，R）。对于无状态而言，最重要的是，y可以仅使用已知的状态常数x和函数F，以及来自cert请求结构的其他输入来一致地计算。基于对R的了解，y不应该是可预测的，因此使用像HMAC-SHA1这样的OWF。
In an enrollment scenario involving an LRAs the CA may allow (or require) the LRA to perform the POP protocol with the entity requesting certification. In this case the LRA needs a way to inform the CA it has done the POP. This control attribute has been created to address this issue.
在涉及LRA的注册场景中，CA可允许（或要求）LRA与请求认证的实体执行POP协议。在这种情况下，LRA需要一种方式来通知CA它已完成POP。已创建此控件属性以解决此问题。
The ASN.1 structure for the LRA POP witness is as follows:
LRA POP见证人的ASN.1结构如下：
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
-- pkiDataBodyid field contains the body part id of the nested CMS body object containing the client's full request message. pkiDataBodyid is set to 0 if the request is in the current PKIRequest body.
--pkiDataBodyid字段包含嵌套CMS主体对象的主体部分id，该对象包含客户端的完整请求消息。如果请求位于当前PKIDataBody中，则pkiDataBodyid设置为0。
-- bodyIds contains a list of certificate requests for which the LRA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response or other means.
--BodyID包含LRA已执行带外身份验证的证书请求列表。认证方法可以是私钥材料存档、质询响应或其他方式。
If a certificate server does not allow for an LRA to do the POP verification, it returns an error of POPFAILURE. The CA MUST NOT start a challenge-response to re-verify the POP itself.
如果证书服务器不允许LRA执行POP验证，它将返回一个POPFILEAL错误。CA不得启动质询响应来重新验证POP本身。
Everything described in this section is optional to implement.
本节中描述的所有内容都是可选的。
The get certificate control attribute is used to retrieve previously issued certificates from a repository of certificates. A Certificate Authority, an LRA or an independent service may provide this repository. The clients expected to use this facility are those operating in a resource-constrained environment. (An example of a resource-constrained client would be a low-end IP router that does not retain its own certificate in non-volatile memory.)
get certificate control属性用于从证书存储库中检索以前颁发的证书。证书颁发机构、LRA或独立服务可以提供此存储库。预期使用此设施的客户机是那些在资源受限的环境中运行的客户机。（资源受限客户端的一个例子是低端IP路由器，它不在非易失性内存中保留自己的证书。）
The get certificate control attribute has the following ASN.1 structure:
get certificate控件属性具有以下ASN.1结构：
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The service responding to the request will place the requested certificate in the certificates field of a SignedData object. If the get certificate attribute is the only control in a Full PKI Request message, the response would be a Simple Enrollment Response.
响应请求的服务将把请求的证书放在SignedData对象的证书字段中。如果get certificate属性是完整PKI请求消息中的唯一控件，则响应将是一个简单的注册响应。
Everything described in this section is optional to implement.
本节中描述的所有内容都是可选的。
The get CRL control attribute is used to retrieve CRLs from a repository of CRLs. A Certification Authority, an LRA or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
get CRL control属性用于从CRL存储库中检索CRL。证书颁发机构、LRA或独立服务机构可以提供此存储库。预期使用此功能的客户机是那些完全部署的目录不可行或不受欢迎的客户机。
The get CRL control attribute has the following ASN.1 structure:
get CRL control属性具有以下ASN.1结构：
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings:
GetCRL中的字段具有以下含义：
-- issuerName is the name of the CRL issuer.
--issuerName是CRL发行人的名称。
-- cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value.
--cRLName可以是主体证书中CRLDistributionPoints的值，也可以是证书不包含该值时的等效值。
-- time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.
--客户机使用时间从可能存在的几个CRL问题中指定thisUpdate值小于但最接近指定时间的问题。如果没有时间组件，CA总是返回最新的CRL。
-- reasons is used to specify from among CRLs partitioned by revocation reason. Implementers should bear in mind that while a specific revocation request has a single CRLReason code--and consequently entries in the CRL would have a single CRLReason code value--a single CRL can aggregate information for one or more reasonFlags.
--原因用于从按吊销原因划分的CRL中指定。实现者应该记住，虽然一个特定的撤销请求有一个CRLReason代码——因此CRL中的条目将有一个CRLReason代码值——但单个CRL可以为一个或多个标志聚合信息。
A service responding to the request will place the requested CRL in the crls field of a SignedData object. If the get CRL attribute is the only control in a full enrollment message, the response would be a simple enrollment response.
响应请求的服务将把请求的CRL放在SignedData对象的crls字段中。如果get CRL属性是完整注册消息中的唯一控件，则响应将是一个简单的注册响应。
The revocation request control attribute is used to request that a certificate be revoked.
吊销请求控制属性用于请求吊销证书。
The revocation request control attribute has the following ASN.1 syntax:
吊销请求控制属性具有以下ASN.1语法：
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
-- issuerName contains the issuerName of the certificate to be revoked.
--issuerName包含要撤销的证书的issuerName。
-- serialNumber contains the serial number of the certificate to be revoked
--serialNumber包含要吊销的证书的序列号
-- reason contains the suggested CRLReason code for why the certificate is being revoked. The CA can use this value at its discretion in building the CRL.
--原因包含吊销证书的原因的建议CRL原因代码。CA可自行决定在构建CRL时使用此值。
-- invalidityDate contains the suggested value for the Invalidity Date CRL Extension. The CA can use this value at its discretion in building the CRL.
--无效日期包含无效日期CRL扩展的建议值。CA可自行决定在构建CRL时使用此值。
-- sharedSecret contains a secret value registered by the EE when the certificate was obtained to allow for revocation of a certificate in the event of key loss.
--sharedSecret包含EE在获取证书时注册的秘密值，以便在密钥丢失时撤销证书。
-- comment contains a human readable comment.
--注释包含人类可读的注释。
For a revocation request to become a reliable object in the event of a dispute, a strong proof of originator authenticity is required. However, in the instance when an end-entity has lost use of its signature private key, it is impossible for the end-entity to produce a digital signature (prior to the certification of a new signature key pair). The RevRequest provides for the optional transmission from the end-entity to the CA of a shared secret that may be used as an alternative authenticator in the instance of loss of use. The acceptability of this practice is a matter of local security policy.
为了使撤销请求在发生争议时成为可靠的对象，需要提供发起人真实性的有力证明。然而，在终端实体丢失其签名私钥的情况下，终端实体不可能产生数字签名（在新签名密钥对认证之前）。RevRequest提供了从终端实体到CA的共享秘密的可选传输，该共享秘密可在丢失使用的情况下用作替代认证器。这种做法的可接受性取决于当地的安全政策。
(Note that in some situations a Registration Authority may be delegated authority to revoke certificates on behalf of some population within its scope control. In these situations the CA would accept the LRA's digital signature on the request to revoke a certificate, independent of whether the end entity still had access to the private component of the key pair.)
（注意，在某些情况下，注册机构可能被授权代表其控制范围内的某些人群撤销证书。在这些情况下，CA将在撤销证书的请求时接受LRA的数字签名，而与最终实体是否仍有权访问私有组件o无关。）f钥匙对。）
Clients MUST provide the capability to produce a digitally signed revocation request control attribute. Clients SHOULD be capable of producing an unsigned revocation request containing the end-entity's shared secret. If a client provides shared secret based self-revocation, the client MUST be capable of producing a revocation request containing the shared secret. Servers MUST be capable of accepting both forms of revocation requests.
客户端必须提供生成数字签名的吊销请求控制属性的功能。客户端应该能够生成包含最终实体共享机密的未签名撤销请求。如果客户端提供基于共享秘密的自撤销，则客户端必须能够生成包含共享秘密的撤销请求。服务器必须能够接受两种形式的撤销请求。
The structure of an unsigned, shared secret based revocation request is a matter of local implementation. The shared secret does not need to be encrypted when sent in a revocation request. The shared secret
未签名、基于共享秘密的撤销请求的结构取决于本地实现。在撤销请求中发送时，不需要加密共享机密。共同的秘密
has a one-time use, that of causing the certificate to be revoked, and public knowledge of the shared secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared secret SHOULD NOT be used for multiple certificates.
一次性使用，导致证书被吊销，并且在证书被吊销后公众对共享秘密的了解不是问题。客户端需要通知用户，同一共享机密不应用于多个证书。
A full response message MUST be returned for a revocation request.
撤销请求必须返回完整的响应消息。
The regInfo control attribute is for clients and LRAs to pass additional information as part a PKI request. The regInfo control attribute uses the ASN.1 structure:
regInfo control属性用于客户端和LRA传递附加信息，作为PKI请求的一部分。regInfo控件属性使用ASN.1结构：
RegInfo ::= OCTET STRING
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
此数据的内容基于客户端和服务器之间的双边协议。
If a server (or LRA) needs to return information back to a requestor in response to data submitted in a regInfo attribute, then that data is returned as a responseInfo control attribute. The content of the OCTET STRING for response information is based on bilateral agreement between the client and server.
如果服务器（或LRA）需要将信息返回给请求者以响应RegiInfo属性中提交的数据，则该数据将作为responseInfo控件属性返回。响应信息的八位字节字符串的内容基于客户端和服务器之间的双边协议。
In some environments, process requirements for manual intervention or other identity checking can cause a delay in returning the certificate related to a certificate request. The query pending attribute allows for a client to query a server about the state of a pending certificate request. The server returns a token as part of the CMCStatusInfo attribute (in the otherInfo field). The client puts the token into the query pending attribute to identify the correct request to the server. The server can also return a suggested time for the client to query for the state of a pending certificate request.
在某些环境中，手动干预或其他身份检查的过程要求可能会导致与证书请求相关的证书返回延迟。查询挂起属性允许客户端向服务器查询挂起证书请求的状态。服务器返回一个令牌作为CMCStatusInfo属性的一部分（在otherInfo字段中）。客户端将令牌放入“查询挂起”属性中，以标识对服务器的正确请求。服务器还可以返回客户端查询挂起证书请求状态的建议时间。
The ASN.1 structure used by the query pending control attribute is:
查询挂起控制属性使用的ASN.1结构为：
QueryPending ::= OCTET STRING
QueryPending ::= OCTET STRING
If a server returns a pending state (the transaction is still pending), the otherInfo MAY be omitted. If it is not omitted then the same value MUST be returned (the token MUST NOT change during the request).
如果服务器返回挂起状态（事务仍处于挂起状态），则可以省略otherInfo。如果没有省略，则必须返回相同的值（令牌在请求期间不得更改）。
Some Certification Authorities require that clients give a positive conformation that the certificates issued to it are acceptable. The Confirm Certificate Acceptance control attribute is used for that purpose. If the CMCStatusInfo on a certificate request is confirmRequired, then the client MUST return a Confirm Certificate
一些认证机构要求客户积极确认向其颁发的证书是可接受的。“确认证书接受控制”属性用于此目的。如果证书请求上的CMCStatusInfo是confirmRequired，则客户端必须返回确认证书
Acceptance prior to any usage of the certificate. Clients SHOULD wait for the response from the server that the conformation has been received.
在使用证书之前接受。客户端应等待服务器的响应，确认已收到。
The confirm certificate acceptance structure is:
确认证书验收结构为：
CMCCertId ::= IssuerSerial
CMCCertId ::= IssuerSerial
-- CMCCertId contains the issuer and serial number of the certificate being accepted.
--CMCCertId包含正在接受的证书的颁发者和序列号。
Servers MUST return a full enrollment response for a confirm certificate acceptance control.
服务器必须返回确认证书接受控制的完整注册响应。
This specification permits the use of Local Registration Authorities (LRAs). An LRA sits between the end-entity and the Certification Authority. From the end-entity's perspective, the LRA appears to be the Certification Authority and from the server the LRA appears to be a client. LRAs receive the enrollment messages, perform local processing and then forward onto Certificate Authorities. Some of the types of local processing that an LRA can perform include:
本规范允许使用当地注册机构（LRA）。LRA位于最终实体和证书颁发机构之间。从终端实体的角度看，LRA似乎是认证机构，从服务器上看，LRA似乎是客户端。LRA接收注册消息，执行本地处理，然后转发到证书颁发机构。LRA可以执行的一些本地处理类型包括：
- batching multiple enrollment messages together, - challenge/response POP proofs, - addition of private or standardized certificate extensions to all requests, - archival of private key material, - routing of requests to different CAs.
- 将多个注册消息批处理在一起，-质询/响应POP证明，-向所有请求添加专用或标准化证书扩展，-私钥材料存档，-将请求路由到不同CA。
When an LRA receives an enrollment message it has three options: it may forward the message without modification, it may add a new wrapping layer to the message, or it may remove one or more existing layers and add a new wrapping layer.
当LRA接收到注册邮件时，它有三个选项：可以转发邮件而不进行修改，可以向邮件添加新的包装层，也可以删除一个或多个现有层并添加新的包装层。
When an LRA adds a new wrapping layer to a message it creates a new PKIData object. The new layer contains any control attributes required (for example if the LRA does the POP proof for an encryption key or the addExtension control attribute to modify an enrollment
当LRA向消息添加新的包装层时，它将创建一个新的PKIData对象。新层包含所需的任何控制属性（例如，如果LRA对加密密钥或addExtension控制属性进行POP验证以修改注册）
request) and the client enrollment message. The client enrollment message is placed in the cmsSequence if it is a Full Enrollment message and in the reqSequence if it is a Simple Enrollment message. If an LRA is batching multiple client messages together, then each client enrollment message is placed into the appropriate location in the LRA's PKIData object along with all relevant control attributes.
请求）和客户端注册消息。如果客户端注册消息是完整注册消息，则将其置于CMS序列中；如果客户端注册消息是简单注册消息，则将其置于reqSequence中。如果LRA将多个客户端消息批处理在一起，则每个客户端注册消息将与所有相关控制属性一起放置到LRA的PKIData对象中的适当位置。
(If multiple LRAs are in the path between the end-entity and the Certification Authority, this will lead to multiple wrapping layers on the message.)
（如果多个LRA位于最终实体和证书颁发机构之间的路径中，这将导致消息上出现多个包装层。）
In processing an enrollment message, an LRA MUST NOT alter any certificate request body (PKCS #10 or CRMF) as any alteration would invalidate the signature on the request and thus the POP for the private key.
在处理注册消息时，LRA不得更改任何证书请求主体（PKCS#10或CRMF），因为任何更改都会使请求上的签名以及私钥的POP无效。
An example of how this would look is illustrated by the following figure:
下图举例说明了这种情况：
SignedData (by LRA) PKIData controlSequence LRA added control statements reqSequence Zero or more Simple CertificationRequests from clients cmsSequence Zero or more Full PKI messages from clients SignedData (by client) PKIData
SignedData（按LRA）PKI数据控制序列LRA添加了控制语句reqSequence零或更多简单认证来自客户端的请求CMS序列零或更多完整PKI消息来自客户端SignedData（按客户端）PKI数据
Under some circumstances an LRA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
在某些情况下，需要LRA移除包装层。以下各节将介绍需要删除加密层和签名层时所需的处理。
There are two cases that require an LRA to remove or change encryption in an enrollment message. In the first case the encryption was applied for the purposes of protecting the entire enrollment request from unauthorized entities. If the CA does not have a recipient info entry in the encryption layer, the LRA MUST remove the encryption layer. The LRA MAY add a new encryption layer with or without adding a new signing layer.
有两种情况需要LRA删除或更改注册消息中的加密。在第一种情况下，应用加密是为了保护整个注册请求不受未经授权实体的攻击。如果CA在加密层中没有收件人信息条目，则LRA必须删除加密层。LRA可以添加新的加密层，也可以不添加新的签名层。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case the LRA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each
可能需要的第二个加密更改是更改签名层内部的加密。在这种情况下，LRA必须删除包含加密的所有签名层。必须根据本地策略规则合并所有控制语句，因为每个控制语句
signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the LRA. If the signing layer provided by the end-entity needs to be removed to the LRA can remove the layer.
签名层被删除，并且生成的合并控件必须放置在LRA提供的新签名层中。如果需要删除终端实体提供的签名层，则LRA可以删除该层。
Only two instances exist where an LRA should remove a signature layer on a Full Enrollment message. If an encryption needs to be modified within the message, or if a Certificate Authority will not accept secondary delegation (i.e. multiple LRA signatures). In all other situations LRAs SHOULD NOT remove a signing layer from a message.
只有两种情况下，LRA应删除完整注册邮件上的签名层。如果需要在消息中修改加密，或者如果证书颁发机构不接受二次委托（即多个LRA签名）。在所有其他情况下，LRA不应从消息中删除签名层。
If an LRA removes a signing layer from a message, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the LRA.
如果LRA从消息中删除签名层，则必须根据本地策略规则合并所有控制语句。生成的合并控制语句必须放置在LRA提供的新签名层中。
Not all methods of transporting data allow for sending unlabeled raw binary data, in may cases standard methods of encoding can be used to greatly ease this issue. These methods normally consist of wrapping some identification of the content around the binary data, possibly applying an encoding to the data and labeling the data. We document for use three different wrapping methods.
并非所有传输数据的方法都允许发送未标记的原始二进制数据，在可能的情况下，可以使用标准编码方法来大大缓解此问题。这些方法通常包括围绕二进制数据包装一些内容标识，可能对数据应用编码并标记数据。我们记录了三种不同的包装方法。
-- MIME wrapping is for transports that are natively MIME based such
as HTTP and E-mail.
-- Binary file transport is defined since floppy disk transport is
still very common. File transport can be done either as MIME
wrapped (section 7.1) or bare (section 7.2).
-- Socket based transport uses the raw BER encoded object.
-- MIME wrapping is for transports that are natively MIME based such
as HTTP and E-mail.
-- Binary file transport is defined since floppy disk transport is
still very common. File transport can be done either as MIME
wrapped (section 7.1) or bare (section 7.2).
-- Socket based transport uses the raw BER encoded object.
MIME wrapping is defined for those environments that are MIME native. These include E-Mail based protocols as well as HTTP.
MIME包装是为MIME本机环境定义的。这些协议包括基于电子邮件的协议以及HTTP。
The basic mime wrapping in this section is taken from [SMIMEV2] and [SMIMEV3]. Simple enrollment requests are encoded using the application/pkcs10 content type. A file name MUST be included either in a content type or content disposition statement. The extension for the file MUST be ".p10".
本节中的基本mime包装取自[SMIMEV2]和[SMIMEV3]。使用application/pkcs10内容类型对简单注册请求进行编码。文件名必须包含在内容类型或内容处置语句中。文件的扩展名必须为“.p10”。
Simple enrollment response messages MUST be encoded as content-type application/pkcs7-mime. An smime-type parameter MUST be on the content-type statement with a value of "certs-only." A file name with the ".p7c" extension MUST be specified as part of the content-type or content-disposition.
简单注册响应消息必须编码为内容类型application/pkcs7 mime。smime类型参数必须位于值为“certs only”的content type语句上。扩展名为“.p7c”的文件名必须指定为内容类型或内容处置的一部分。
Full enrollment request messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-enroll". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
完整注册请求消息必须编码为内容类型application/pkcs7 mime。smime类型参数必须包含值“CMC enroll”。扩展名为“.p7m”的文件名必须指定为内容类型或内容处置语句的一部分。
Full enrollment response messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-response." A file name with the ".p7m" extensions MUST be specified as part of the content-type or content-disposition.
完整注册响应消息必须编码为内容类型application/pkcs7 mime。smime类型参数的值必须为“CMC response”。扩展名为“.p7m”的文件名必须指定为内容类型或内容处置的一部分。
MIME TYPE File Extension SMIME-TYPE
MIME类型文件扩展名SMIME-TYPE
application/pkcs10 .p10 N/A (simple PKI request)
application/pkcs10.p10不适用（简单PKI请求）
application/pkcs7-mime .p7m CMC-request (full PKI request)
应用程序/pkcs7 mime.p7m CMC请求（完整PKI请求）
application/pkcs7-mime .p7c certs-only (simple PKI response)
仅限应用程序/pkcs7 mime.p7c证书（简单PKI响应）
application/pkcs7-mime .p7m CMC-response (full PKI response)
应用程序/pkcs7 mime.p7m CMC响应（完整PKI响应）
Enrollment messages and responses may also be transferred between clients and servers using file system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, BER-encoded Full Enrollment Request and Response messages, the following file type extensions SHOULD be used:
注册消息和响应也可以使用基于文件系统的机制在客户机和服务器之间传输，例如当为离线客户机执行注册时。当文件用于传输二进制、BER编码的完整注册请求和响应消息时，应使用以下文件类型扩展名：
Message Type File Extension
消息类型文件扩展名
Full PKI Request .crq
完整PKI请求.crq
Full PKI Response .crp
完整的PKI响应
When enrollment messages and responses are sent over sockets, no wrapping is required. Messages SHOULD be sent in their binary, BER-encoded form.
通过套接字发送注册消息和响应时，不需要包装。消息应以二进制、BER编码的形式发送。
CMC clients and servers MUST be capable of producing and processing message signatures using the Digital Signature Algorithm [DSA]. DSA signatures MUST be indicated by the DSA AlgorithmIdentifier value (as specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers SHOULD also be capable of producing and processing RSA signatures (as specified in section 7.2.1 of [PKIXCERT]).
CMC客户端和服务器必须能够使用数字签名算法[DSA]生成和处理消息签名。DSA签名必须由DSA算法标识符值表示（如[PKIXCERT]第7.2.2节所述）。PKI客户端和服务器还应能够生成和处理RSA签名（如[PKIXCERT]第7.2.1节所述）。
CMC clients and servers MUST be capable of protecting and accessing message encryption keys using the Diffie-Hellman (D-H) key exchange algorithm. D-H/3DES protection MUST be indicated by the D-H AlgorithmIdentifier value specified in [CMS]. PKI clients and servers SHOULD also be capable of producing and processing RSA key transport. When used for PKI messages, RSA key transport MUST be indicated as specified in section 7.2.1 of [PKIXCERT].
CMC客户端和服务器必须能够使用Diffie-Hellman（D-H）密钥交换算法保护和访问消息加密密钥。D-H/3DES保护必须由[CMS]中规定的D-H算法标识符值指示。PKI客户端和服务器还应该能够生成和处理RSA密钥传输。当用于PKI消息时，必须按照[PKIXCERT]第7.2.1节的规定指示RSA密钥传输。
A minimally compliant CMC server:
最低限度兼容的CMC服务器：
a) MUST accept a Full PKI Request message i) MUST accept CRMF Request Bodies within a Full PKI Request ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request b) MUST accept a Simple Enrollment Request message c) MUST be able to return a Full PKI Response. (A Full PKI Response is always a valid response, but for interoperability with downlevel clients a compliant server SHOULD use the Simple Enrollment Response whenever possible.)
a) 必须接受完整PKI请求消息i）必须接受完整PKI请求中的CRMF请求机构ii）必须接受PKC#完整PKI请求中的10个请求机构b）必须接受简单注册请求消息c）必须能够返回完整PKI响应。（完整的PKI响应始终是有效的响应，但为了与底层客户端的互操作性，兼容服务器应尽可能使用简单的注册响应。）
A minimally-complaint CMC client:
最低限度投诉CMC客户端：
a) MAY use either the Simple Enrollment Message or the Full PKI Request. i) clients MUST use PKCS#10 with the Simple Enrollment Message ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request b) MUST understand the Simple Enrollment Response. c) MUST understand the Full PKI Response.
a) 可以使用简单注册消息或完整PKI请求。i） 客户端必须在简单注册消息中使用PKCS#10 ii）客户端可以在完整PKI请求中使用PKCS#10或CRMF b）必须理解简单注册响应。c） 必须了解完整的PKI响应。
Initiation of a secure communications channel between an end-entity and a CA or LRA (and, similarly, between an LRA and another LRA or CA) necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPSEC or TLS. Many such schemes exist and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
在终端实体和CA或LRA之间（以及类似地，在LRA和另一个LRA或CA之间）发起安全通信信道必然需要带外信任发起机制。例如，可以通过IPSEC或TLS在终端实体和CA之间构建安全信道。存在许多这样的方案，并且选择任何特定的方案来发起信任超出了本文的范围。该协议的实施者被强烈鼓励考虑在整体安全体系结构中集成该能力时普遍接受的安全密钥管理原则。
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the CA maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in section 5.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.
在本协议的特定实现中，可能需要阻止重播攻击的机制，具体取决于操作环境。在CA保持重要状态信息的情况下，重放攻击可以在不包含可选的nonce机制的情况下被检测。该协议的实现者需要仔细考虑环境条件，然后选择是否实现在第5.6节中描述的StordNoice和ReliffNoice属性。强烈鼓励受状态约束的PKI客户端的开发人员使用这些属性。
Under no circumstances should a signing key be archived. Doing so allows the archiving entity to potentially use the key for forging signatures.
在任何情况下都不应存档签名密钥。这样做允许存档实体潜在地使用密钥伪造签名。
Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
在存档密钥之前，必须格外小心。一旦将密钥提供给存档实体，存档实体可能会以不利于存档实体的方式使用密钥。用户应特别注意对用于加密私钥材料的证书进行适当验证。
Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. A description of the small subgroup attack is provided in [X942]. CMC implementations ought to be aware of this attack when doing parameter validations.
在颁发证书之前，客户端和服务器需要对加密参数进行一些检查，以确保不使用弱参数。[X942]中提供了小子组攻击的描述。CMC实现在执行参数验证时应注意此攻击。
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
作者要感谢Brian LaMacchia，感谢他在开发和撰写本文中提出的许多概念方面所做的工作。作者还要感谢Alex执事和Barb Fox的贡献。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999.
[CRMF]迈尔斯，M.，亚当斯，C.，索洛，D.和D.肯普，“互联网X.509证书请求消息格式”，RFC25111999年3月。
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
[DH]B.Kaliski，“PKCS 3:Diffie-Hellman密钥协议v1.4”
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", Work in Progress.
[DH-POP]H.Prafullchandra，J.Schaad，“Diffie-Hellman占有算法证明”，正在进行中。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC 2313, March 1998.
[PKCS1]Kaliski，B.，“PKCS#1:RSA加密，1.5版”，RFC 2313，1998年3月。
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5", RFC 2315, October 1997.
[PKCS7]Kaliski，B.，“PKCS#7：加密消息语法v1.5”，RFC 2315，1997年10月。
[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax Standard, Version 1.2", November 1, 1993.
[PKCS8]RSA实验室，“PKCS#8：私钥信息语法标准，1.2版”，1993年11月1日。
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997.
[PKCS10]Kaliski，B.，“PKCS#10：认证请求语法v1.5”，RFC 2314，1997年10月。
[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[PKIXCERT]Housley，R.，Ford，W.，Polk，W.和D.Solo“Internet X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[SMIMEV2]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[SMIMEV3]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[X942]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
Michael Myers VeriSign Inc. 1350 Charleston Road Mountain View, CA, 94043
Michael Myers VeriSign Inc.加利福尼亚州查尔斯顿路1350号山景城，邮编94043
Phone: (650) 429-3402 EMail: mmyers@verisign.com
电话：（650）429-3402电子邮件：mmyers@verisign.com
Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose, CA 95134
刘晓义思科系统美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: (480) 526-7430 EMail: xliu@cisco.com
电话：（480）526-7430电子邮件：xliu@cisco.com
Jim Schaad
吉姆·沙德
EMail: jimsch@nwlink.com
EMail: jimsch@nwlink.com
Jeff Weinstein
杰夫·温斯坦
EMail: jsw@meer.net
EMail: jsw@meer.net
Appendix A ASN.1 Module
附录A ASN.1模块
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
进口
-- Information Directory Framework (X.501) Name FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) informationFramework(1) 3 }
--信息目录框架（X.501）来自InformationFramework的名称{joint-iso-itu-t ds（5）模块（1）InformationFramework（1）3}
-- Directory Authentication Framework (X.509) AlgorithmIdentifier, AttributeCertificate, Certificate, CertificateList, CertificateSerialNumber FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }
--目录身份验证框架（X.509）算法标识符、属性证书、证书、证书列表、来自身份验证框架的证书序列号{joint-iso-itu-t ds（5）模块（1）身份验证框架（7）3}
-- PKIX Part 1 - Implicit
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- PKIX Part 1 - Implicit
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- PKIX Part 1 - Explicit
SubjectPublicKeyInfo, Extension
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- PKIX Part 1 - Explicit
SubjectPublicKeyInfo, Extension
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- Cryptographic Message Syntax ContentInfo, Attribute FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
--加密消息语法ContentInfo，CryptographicMessageSyntax{1 2 840 113549 1 9 16 0 1}中的属性
-- CRMF CertReqMsg FROM CRMF { 1 3 6 1 5 5 7 0 5 };
--来自CRMF{1 3 6 1 5 7 0 5}的CRMF CertReqMsg；
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have simple type content (usually OCTET STRING)
--以下控件具有简单的类型内容（通常为八位字符串）
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
-- This is the content type used for a request message in the protocol
--这是协议中用于请求消息的内容类型
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
bodyIdMax INTEGER ::= 4294967295
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
BodyPartID ::= INTEGER(0..bodyIdMax)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
AttributeValue ::= ANY
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
}
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- Used to return status state in a response
--用于在响应中返回状态
id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF INTEGER,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF INTEGER,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL }
pendInfo pendInfo}可选}
PendInfo ::= SEQUENCE {
pendToken INTEGER,
pendTime GENERALIZEDTIME
}
PendInfo ::= SEQUENCE {
pendToken INTEGER,
pendTime GENERALIZEDTIME
}
CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
failed (2),
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
failed (2),
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCFailInfo ::= INTEGER {
badAlg (0),
-- Unrecognized or unsupported algorithm
badMessageCheck (1),
-- integrity check failed
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- Message time field was not sufficiently close to the system
time
badCertId (4),
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5),
-- A requested X.509 extension is not supported by the recipient
CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
CMCFailInfo ::= INTEGER {
badAlg (0),
-- Unrecognized or unsupported algorithm
badMessageCheck (1),
-- integrity check failed
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- Message time field was not sufficiently close to the system
time
badCertId (4),
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5),
-- A requested X.509 extension is not supported by the recipient
CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
}
-- Used for LRAs to add extensions to certificate requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
-- Used for LRAs to add extensions to certificate requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
GetCRL ::= SEQUENCE {
GetCRL ::= SEQUENCE {
issuerName Name, cRLName GeneralName OPTIONAL, time GeneralizedTime OPTIONAL, reasons ReasonFlags OPTIONAL }
issuerName Name、cRLName GeneralName可选、time GeneralizedTime可选、reasons ReasonFlags可选}
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
CMCCertId ::= IssuerSerial
CMCCertId ::= IssuerSerial
-- The following is used to request V3 extensions be added to a certificate
--以下内容用于请求将V3扩展添加到证书
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
ExtensionReq ::= SEQUENCE OF Extension
ExtensionReq ::= SEQUENCE OF Extension
-- The following exists to allow Diffie-Hellman Certificate Requests
Messages to be
-- well-formed
-- The following exists to allow Diffie-Hellman Certificate Requests
Messages to be
-- well-formed
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
NoSignatureValue ::= OCTET STRING
END
终止
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。