Network Working Group J. Schaad
Request for Comments: 5272 Soaring Hawk Consulting
Obsoletes: 2797 M. Myers
Category: Standards Track TraceRoute Security, Inc.
June 2008
Network Working Group J. Schaad
Request for Comments: 5272 Soaring Hawk Consulting
Obsoletes: 2797 M. Myers
Category: Standards Track TraceRoute Security, Inc.
June 2008
Certificate Management over CMS (CMC)
CMS（CMC）上的证书管理
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）。本备忘录的分发不受限制。
Abstract
摘要
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:
本文档定义了CMC的基本语法，CMC是一种使用加密消息语法（CMS）的证书管理协议。该协议解决了Internet公钥基础设施（PKI）社区内的两个迫切需要：
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and
1. 需要与基于CMS和PKCS#10（公钥加密标准）的公钥认证产品和服务的接口，以及
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
2. 由于算法或硬件设计，仅加密密钥需要PKI注册协议。
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.
CMC还要求使用运输文件和要求使用文件以及本文件，以获得完整定义。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Certification Request Formats . . . . . . . . . . 15
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17
3.2.1.2.3. Other Certification Request . . . . . . . . . 18
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24
5. Application of Encryption to a PKI Request/Response . . . . . 25
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30
6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32
6.2. Identification and Identity Proof Controls . . . . . . . . 33
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35
6.2.3. Identification Control . . . . . . . . . . . . . . . . 35
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36
6.3. Linking Identity and POP Information . . . . . . . . . . . 36
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38
6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Certification Request Formats . . . . . . . . . . 15
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17
3.2.1.2.3. Other Certification Request . . . . . . . . . 18
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24
5. Application of Encryption to a PKI Request/Response . . . . . 25
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30
6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32
6.2. Identification and Identity Proof Controls . . . . . . . . 33
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35
6.2.3. Identification Control . . . . . . . . . . . . . . . . 35
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36
6.3. Linking Identity and POP Information . . . . . . . . . . . 36
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38
6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39
6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40
6.5. RA Certificate Modification Controls . . . . . . . . . . . 40
6.5.1. Modify Certification Request Control . . . . . . . . . 41
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42
6.6. Transaction Identifier Control and Sender and
Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
6.12. Registration and Response Information Controls . . . . . . 52
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
6.17. Batch Request and Response Controls . . . . . . . . . . . 56
6.18. Publication Information Control . . . . . . . . . . . . . 57
6.19. Control Processed Control . . . . . . . . . . . . . . . . 58
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74
B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74
B.2. Single Certification Request, But Modified by RA . . . . . 75
B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 81
C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 81
6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40
6.5. RA Certificate Modification Controls . . . . . . . . . . . 40
6.5.1. Modify Certification Request Control . . . . . . . . . 41
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42
6.6. Transaction Identifier Control and Sender and
Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
6.12. Registration and Response Information Controls . . . . . . 52
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
6.17. Batch Request and Response Controls . . . . . . . . . . . 56
6.18. Publication Information Control . . . . . . . . . . . . . 57
6.19. Control Processed Control . . . . . . . . . . . . . . . . 58
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74
B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74
B.2. Single Certification Request, But Modified by RA . . . . . 75
B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 81
C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 81
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet PKI community:
本文档定义了CMC的基本语法，CMC是一种使用加密消息语法（CMS）的证书管理协议。该协议解决了Internet PKI社区内的两个迫切需要：
1. The need for an interface to public key certification products and services based on CMS and PKCS #10, and
1. 需要与基于CMS和PKCS#10的公钥认证产品和服务的接口，以及
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
2. 由于算法或硬件设计，仅加密密钥需要PKI注册协议。
A small number of additional services are defined to supplement the core certification request service.
定义了少量附加服务来补充核心认证请求服务。
The protocol must be based as much as possible on the existing CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format) [CRMF] specifications.
协议必须尽可能基于现有的CMS、PKCS#10[PKCS10]和CRMF（证书请求消息格式）[CRMF]规范。
The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS#7 "certs-only" response as a subset of the protocol.
该协议必须支持当前行业惯例，即PKCS#10认证请求，然后是PKCS#7“仅证书”响应，作为协议的一个子集。
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
该协议必须轻松支持S/MIME和其他组所需的多密钥注册协议。
The protocol must supply a way of doing all enrollment operations in a single round-trip. When this is not possible the number of round-trips is to be minimized.
协议必须提供在一次往返中执行所有注册操作的方法。如果不可能，则应尽量减少往返次数。
The protocol must be designed such that all key generation can occur on the client.
协议的设计必须确保所有密钥生成都可以在客户端进行。
Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents.
必须支持S/MIME使用的强制算法。应支持S/MIME核心文档引用的所有其他算法。
The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.
协议必须包含占有证明（POP）方法。如有必要，将为多次往返POP制定可选规定。
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.
对于需要外部过程来颁发证书的情况，协议必须支持对注册请求的延迟和挂起响应。
The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs).
该协议必须支持任意注册机构链（RAs）作为认证请求者和认证机构（CA）之间的中介。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
We have done a major overhaul on the layout of the document. This included two different steps. Firstly we removed some sections from the document and moved them to two other documents. Information on how to transport our messages are now found in [CMC-TRANS]. Information on which controls and sections of this document must be implemented along with which algorithms are required can now be found in [CMC-COMPL].
我们对文件的布局作了重大修改。这包括两个不同的步骤。首先，我们从文档中删除了一些部分，并将它们移动到另外两个文档中。有关如何传输邮件的信息，请参见[CMC-TRANS]。有关必须实施本文件的哪些控制和章节以及需要哪些算法的信息，请参见[CMC-COMPL]。
A number of new controls have been added in this version:
此版本中添加了许多新控件：
Extended CMC Status Info Section 6.1.1
扩展CMC状态信息第6.1.1节
Publish Trust Anchors Section 6.15
发布第6.15节
Authenticate Data Section 6.16
验证数据第6.16节
Batch Request and Response Processing Section 6.17
批处理请求和响应处理第6.17节
Publication Information Section 6.18
出版物信息第6.18节
Modify Certification Request Section 6.5.1
修改认证申请第6.5.1节
Control Processed Section 6.19
第6.19节的控制
Identity Proof Section 6.2.2
身份证明第6.2.2节
Identity POP Link Witness V2 Section 6.3.1.1
标识弹出链接见证V2第6.3.1.1节
A PKI enrollment transaction in this specification is generally composed of a single round-trip of messages. In the simplest case a PKI enrollment request, henceforth referred to as a PKI Request, is sent from the client to the server and a PKI enrollment response, henceforth referred to as a PKI Response, is then returned from the
本规范中的PKI注册事务通常由单个往返消息组成。在最简单的情况下，将PKI注册请求（以下称为PKI请求）从客户端发送到服务器，然后从服务器返回PKI注册响应（以下称为PKI响应）
server to the client. In more complicated cases, such as delayed certificate issuance, more than one round-trip is required.
将服务器连接到客户端。在更复杂的情况下，如证书颁发延迟，需要多次往返。
This specification defines two PKI Request types and two PKI Response types.
本规范定义了两种PKI请求类型和两种PKI响应类型。
PKI Requests are formed using either the PKCS #10 or CRMF structure. The two PKI Requests are:
PKI请求使用PKCS#10或CRMF结构形成。这两个PKI请求是：
Simple PKI Request: the bare PKCS #10 (in the event that no other services are needed), and
简单PKI请求：裸PKCS#10（在不需要其他服务的情况下），以及
Full PKI Request: one or more PKCS #10, CRMF or Other Request Messages structures wrapped in a CMS encapsulation as part of a PKIData.
完整PKI请求：一个或多个PKC#10、CRMF或其他请求消息结构封装在CMS封装中，作为PKI数据的一部分。
PKI Responses are based on SignedData or AuthenticatedData [CMS]. The two PKI Responses are
PKI响应基于SignedData或AuthenticatedData[CMS]。这两个PKI响应是
Simple PKI Response: a "certs-only" SignedData (in the event no other services are needed), or
简单PKI响应：“仅证书”签名数据（如果不需要其他服务），或
Full PKI Response: a PKIResponse content type wrapped in a SignedData.
完整PKI响应：包装在SignedData中的PKI响应内容类型。
No special services are provided for either renewal (i.e., a new certificate with the same key) or rekey (i.e., a new certificate with a new key) of client certificates. Instead renewal and rekey requests look the same as any certification request, except that the identity proof is supplied by existing certificates from a trusted CA. (This is usually the same CA, but could be a different CA in the same organization where naming is shared.)
对于客户端证书的续订（即使用相同密钥的新证书）或重新密钥（即使用新密钥的新证书），不提供特殊服务。相反，续订和重新密钥请求看起来与任何证书请求相同，只是身份证明由来自受信任CA的现有证书提供。（这通常是同一CA，但可以是共享命名的同一组织中的不同CA。）
No special services are provided to distinguish between a rekey request and a new certification request (generally for a new purpose). A control to unpublish a certificate would normally be included in a rekey request, and be omitted in a new certification request. CAs or other publishing agents are also expected to have policies for removing certificates from publication either based on new certificates being added or the expiration or revocation of a certificate.
没有提供特殊服务来区分密钥更新请求和新认证请求（通常用于新目的）。取消发布证书的控件通常会包含在重新密钥请求中，而在新的证书请求中会被忽略。CAs或其他发布代理还应具有基于添加的新证书或证书过期或吊销从发布中删除证书的策略。
A provision exists for RAs to participate in the protocol by taking PKI Requests, wrapping them in a second layer of PKI Request with additional requirements or statements from the RA and then passing this new expanded PKI Request on to the CA.
有一项规定规定，RAs可以通过接受PKI请求，将它们包装在第二层PKI请求中，并使用RA的附加要求或声明，然后将此新扩展的PKI请求传递给CA，从而参与协议。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS does not imply an email-based transport. Several different possible transport methods are defined in [CMC-TRANS].
本规范不对底层传输机制进行任何假设。CMS的使用并不意味着基于电子邮件的传输。[CMC-TRANS]中定义了几种不同的可能传输方法。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/certificate revocation list (CRL) retrieval.
本规范提供的可选服务包括事务管理、重播检测（通过nonce）、延迟证书颁发、证书撤销请求和证书/证书撤销列表（CRL）检索。
There are several different terms, abbreviations, and acronyms used in this document. These are defined here, in no particular order, 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.
终端实体（EE）是指拥有密钥对并为其颁发证书的实体。
Registration Authority (RA) or Local RA (LRA) refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the end-entity and the Certification Authority. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.
注册机构（RA）或本地RA（LRA）是指在EE和CA之间充当中介的实体。最终实体和认证机构之间可以存在多个RA。RAs可以执行额外的服务，例如密钥生成或密钥存档。本文件使用术语RA表示RA和LRA。
Certification Authority (CA) refers to the entity that issues certificates.
证书颁发机构（CA）是指颁发证书的实体。
Client refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients.
客户端是指创建PKI请求的实体。在本文档中，RAs和EEs都可以是客户机。
Server refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
服务器是指处理PKI请求和创建PKI响应的实体。在本文档中，CAs和RAs都可以是服务器。
PKCS #10 refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.
PKCS#10是指公钥加密标准#10[PKCS10]，它定义了一种认证请求语法。
CRMF refers to the Certificate Request Message Format RFC [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.
CRMF指证书请求消息格式RFC[CRMF]。CMC使用本文档中定义的此认证请求语法作为协议的一部分。
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.
CMS是指加密消息语法RFC[CMS]。本文档提供了基本的加密服务，包括加密和签名（使用和不使用密钥管理）。
PKI Request/Response refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.
PKI请求/响应指本文件中描述的请求/响应。PKI请求包括认证请求、撤销请求等。PKI响应包括仅证书消息、失败消息等。
Proof-of-Identity refers to the client proving they are who they say that they are to the server.
身份证明是指客户端向服务器证明他们是他们所说的那个人。
Enrollment or certification request refers to the process of a client requesting a certificate. A certification request is a subset of the PKI Requests.
注册或证书请求是指客户端请求证书的过程。认证请求是PKI请求的子集。
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. The different types of POP are:
占有证明（POP）是指可用于证明与公钥对应的私钥处于占有状态并可由最终实体使用的值。不同类型的流行音乐包括：
Signature provides the required POP by a signature operation over some data.
签名通过对某些数据执行签名操作来提供所需的POP。
Direct provides the required POP operation by an encrypted challenge/response mechanism.
Direct通过加密的质询/响应机制提供所需的POP操作。
Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.)
间接通过以加密状态返回已颁发的证书来提供所需的POP操作。（CMC不使用此方法。）
Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.)
Publish通过向证书颁发者提供私钥来提供所需的POP操作。（CMC当前未使用此方法。密钥生成或密钥托管扩展将使用此方法。）
Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods.
通过允许受信任实体断言POP已通过上述方法之一得到验证，证明提供了所需的POP操作。
Object IDentifier (OID) is a primitive type in Abstract Syntax Notation One (ASN.1).
对象标识符（OID）是抽象语法表示法1（ASN.1）中的一种基本类型。
Figure 1 shows the Simple PKI Requests and Responses. The contents of Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.
图1显示了简单的PKI请求和响应。简单PKI请求和响应的内容详见第3.1节和第4.1节。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Requests and Responses
图1：简单的PKI请求和响应
Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.
图2显示了完整的PKI请求和响应。完整PKI请求和响应的内容详见第3.2节和第4.2节。
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Figure 2: Full PKI Requests and Responses
图2：完整的PKI请求和响应
Two types of PKI Requests exist. This section gives the details for both types.
存在两种类型的PKI请求。本节给出了这两种类型的详细信息。
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].
一个简单的PKI请求使用PKCS#10语法CertificationRequest[PKCS10]。
When a server processes a Simple PKI Request, the PKI Response returned is:
当服务器处理简单的PKI请求时，返回的PKI响应为：
Simple PKI Response on success.
成功时简单的PKI响应。
Full PKI Response on failure. The server MAY choose not to return a PKI Response in this case.
失败时的完整PKI响应。在这种情况下，服务器可以选择不返回PKI响应。
The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included.
如果需要包括身份证明，则不得使用简单的PKI请求。
The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature (i.e., Diffie-Hellman (DH) keys can use the signature algorithms in [DH-POP] for production of the signature).
如果私钥不能生成某种类型的签名（即Diffie-Hellman（DH）密钥可以使用[DH-POP]中的签名算法生成签名），则不能使用简单的PKI请求。
The Simple PKI Request cannot be used for any of the advanced services specified in this document.
简单PKI请求不能用于本文档中指定的任何高级服务。
The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:
客户机可以将一个或多个X.509v3扩展作为ExtensionReq属性合并到基于PKCS#10的任何认证请求中。ExtensionReq属性定义为：
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is identified by:
其中扩展从[PKIXCERT]导入，扩展请求由以下内容标识：
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}
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process 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 keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt.
服务器必须能够处理[PKIXCERT]中定义但未被禁止的所有扩展。服务器不需要能够处理使用此协议传输的其他X.509v3扩展，也不需要能够处理专用扩展。服务器不需要将所有客户端请求的扩展放入证书中。允许服务器修改客户端请求的扩展。服务器不得更改扩展以使客户端请求的扩展的原始意图无效。（例如，将密钥使用从keyAgreement更改为digitalSignature。）如果由于无法处理请求的扩展而拒绝了认证请求，并且返回了PKI响应，则服务器必须返回一个带有CMCFailInfo值和值unsupportedExt的PKI响应。
The Full PKI Request provides the most functionality and flexibility.
完整的PKI请求提供了最大的功能性和灵活性。
The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).
完整的PKI请求封装在SignedData或AuthenticatedData中，封装的内容类型为id cct PKIData（第3.2.1节）。
When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:
当服务器处理完整的PKI请求时，必须返回PKI响应。返回的PKI响应是：
Simple PKI Response if the enrollment was successful and only certificates are returned. (A CMCStatusInfoV2 control with success is implied.)
如果注册成功且仅返回证书，则简单PKI响应。（暗示CMCStatusInfoV2控件成功。）
Full PKI Response if the enrollment was successful and information is returned in addition to certificates, if the enrollment is pending, or if the enrollment failed.
如果注册成功并且除了证书之外还返回了信息、注册处于挂起状态或注册失败，则为完整PKI响应。
If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (i.e., included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:
如果使用SignedData，则可以使用嵌入式签名认证请求的私钥材料（即，包含在TaggedRequest tcr或crm字段中）或先前认证的签名密钥生成签名。如果使用签名认证请求的私钥，则：
a. The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.
a. 包含相应公钥的认证请求必须包含主题密钥标识符扩展。
b. The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.
b. 必须使用SignerInfo中signerIdentifier的subjectKeyIdentifier表单。
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (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 in the SignedData.
c. SignerInfo的subjectKeyIdentifier表单的值必须是相应证书请求中指定的subjectKeyIdentifier。（此处使用SignerInfo的subjectKeyIdentifier表单，因为尚未为签名密钥颁发证书。）如果请求密钥用于签名，则SignedData中必须只有一个SignerInfo。
If AuthenticatedData is used, then:
如果使用了AuthenticatedData，则：
a. The Password Recipient Info option of RecipientInfo MUST be used.
a. 必须使用RecipientInfo的密码收件人信息选项。
b. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.
b. 随机生成的密钥用于计算封装内容上的消息认证码（MAC）值。
c. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF8) and the shared-secret.
c. 密钥派生算法的输入是标识符（编码为UTF8）和共享密钥的串联。
When creating a PKI Request to renew or rekey a certificate:
创建PKI请求以续订或重新设置证书密钥时：
a. The Identification and Identity Proof controls are absent. The same information is provided by the use of an existing certificate from a CA when signing the PKI Request. In this case, the CA that issued the original certificate and the CA the request is made to will usually be the same, but could have a common operator.
a. 没有身份识别和身份证明控制。在签署PKI请求时，使用CA的现有证书可以提供相同的信息。在这种情况下，颁发原始证书的CA和向其发出请求的CA通常是相同的，但可以有一个公共的操作员。
b. CAs and RAs can impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for a client be used.
b. CAs和RAs可以对使用的签名证书施加附加限制。他们可能要求使用最近颁发的客户端签名证书。
c. Some CAs may prevent renewal operations (i.e., reuse of the same keys). In this case the CA MUST return a PKI Response with noKeyReuse as the CMCFailInfo failure code.
c. 某些CA可能会阻止续订操作（即重复使用相同的密钥）。在这种情况下，CA必须返回一个PKI响应，其中noKeyReuse作为CMCFailInfo故障代码。
The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:
PKIData内容类型用于完整的PKI请求。PKI数据内容类型由以下各项标识：
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
The ASN.1 structure corresponding to the PKIData content type is:
与PKIData内容类型对应的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
}
The fields in PKIData have the following meaning:
PKIData中的字段具有以下含义：
controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure can be found in Section 3.2.1.1.
controlSequence是一系列控件。本文件中定义的控制见第6节。控制可由其他方定义。有关TaggedAttribute结构的详细信息，请参见第3.2.1.1节。
reqSequence is a sequence of certification requests. The certification requests can be a CertificationRequest (PKCS #10), a CertReqMsg (CRMF), or an externally defined PKI request. Full details are found in Section 3.2.1.2. If an externally defined certification request is present, but the server does not understand the certification request (or will not process it), a CMCStatus of noSupport MUST be returned for the certification request item and no other certification requests are processed.
reqSequence是一系列认证请求。认证请求可以是CertificationRequest（PKCS#10）、CertReqMsg（CRMF）或外部定义的PKI请求。详细信息见第3.2.1.2节。如果存在外部定义的认证请求，但服务器不理解该认证请求（或不处理该请求），则必须为该认证请求项返回CMCStatus of noSupport，并且不处理其他认证请求。
cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
cmsSequence是[CMS]消息对象的序列。详见第3.2.1.3节。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
otherMsgSequence是任意数据对象的序列。放置在此处的数据对象由一个或多个控件引用。这允许控件使用大量数据，而无需将数据嵌入控件中。详见第3.2.1.4节。
All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see Section 6.17) are expected to place the PKI Requests received into the cmsSequence of a PKIData.
编码到单个PKI数据中的所有认证请求都应具有相同的身份。RAs表示，批处理（见第6.17节）预计会将收到的PKI请求放入PKI数据的CMS序列中。
Processing of the PKIData by a recipient is as follows:
收件人对PKI数据的处理如下：
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing. Controls can be processed in any order; the order in the sequence is not significant.
1. 应以适当的方式检查和处理所有控制措施。适当的处理方法是此时完成处理，忽略该控件，或将该控件放在待办事项列表上以供以后处理。控件可以按任何顺序处理；序列中的顺序并不重要。
2. Items in the reqSequence are not referenced by a control. These items, which are certification requests, also need to be processed. As with controls, the appropriate processing can be either immediate processing or addition to a to-do list for later processing.
2. reqSequence中的项未被控件引用。这些项目是认证请求，也需要处理。与控件一样，适当的处理可以是立即处理，也可以是添加到待办事项列表以供以后处理。
3. Finally, the to-do list is processed. In many cases, the to-do list will be ordered by grouping specific tasks together.
3. 最后，处理待办事项列表。在许多情况下，待办事项列表将通过将特定任务分组在一起来排序。
No processing is required for cmsSequence or otherMsgSequence members of PKIData if they are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are ignored.
如果cmsSequence或PKIData的其他MSGSequence成员存在且未被控件引用，则无需对其进行处理。在这种情况下，将忽略cmsSequence和其他MSGSequence成员。
The actions to be performed for a PKI Request/Response are based on the included controls. Each control consists of an object identifier and a value based on the object identifier.
对PKI请求/响应执行的操作基于包含的控件。每个控件由一个对象标识符和一个基于对象标识符的值组成。
The syntax of a control is:
控件的语法为：
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
The fields in TaggedAttribute have the following meaning:
TaggedAttribute中的字段具有以下含义：
bodyPartID is a unique integer that identifies this control.
bodyPartID是标识此控件的唯一整数。
attrType is the OID that identifies the control.
attrType是标识控件的OID。
attrValues is the data values used in processing the control. The structure of the data is dependent on the specific control.
attrValues是处理控件时使用的数据值。数据的结构取决于特定控件。
The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19) and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
如果未识别任何包含的控件，该控件尚未标记为已由控件处理的控件处理（参见第6.19节），并且未生成其他错误，则最终服务器必须使整个PKI数据的处理失败。PKI响应必须包含一个CMCFailInfo值和一个badRequest值，并且bodyList必须包含无效或无法识别控件的bodyPartID。当且仅当服务器未将PKI请求传递给另一台服务器时，服务器才是最终服务器。如果服务器在上传递了PKI请求，则不认为该服务器是最终服务器，而是返回了一个处理错误。
The controls defined by this document are found in Section 6.
本文件定义的控制见第6节。
Certification Requests are based on PKCS #10, CRMF, or Other Request formats. Section 3.2.1.2.1 specifies the requirements for clients and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the requirements for clients and servers dealing with CRMF. Section 3.2.1.2.3 specifies the requirements for clients and servers dealing with Other Request.
认证请求基于PKCS#10、CRMF或其他请求格式。第3.2.1.2.1节规定了处理PKCS#10的客户端和服务器的要求。第3.2.1.2.2节规定了处理CRMF的客户端和服务器的要求。第3.2.1.2.3节规定了处理其他请求的客户端和服务器的要求。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
The fields in TaggedRequest have the following meaning:
TaggedRequest中的字段具有以下含义：
tcr is a certification request that uses the PKCS #10 syntax. Details on PKCS #10 are found in Section 3.2.1.2.1.
tcr是一种使用PKCS#10语法的认证请求。PKCS#10的详细信息见第3.2.1.2.1节。
crm is a certification request that uses the CRMF syntax. Details on CRMF are found in Section 3.2.1.2.2.
crm是使用CRMF语法的认证请求。有关CRMF的详细信息，请参见第3.2.1.2.2节。
orm is an externally defined certification request. One example is an attribute certification request. The fields of this structure are:
orm是一个外部定义的认证请求。一个例子是属性认证请求。此结构的字段包括：
bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
bodyPartID是此认证请求的标识号。有关车身部件标识符的详细信息，请参见第3.2.2节。
requestMessageType identifies the other request type. These values are defined outside of this document.
requestMessageType标识其他请求类型。这些值在本文档之外定义。
requestMessageValue is the data associated with the other request type.
requestMessageValue是与其他请求类型关联的数据。
A certification request based on PKCS #10 uses the following ASN.1 structure:
基于PKCS#10的认证请求使用以下ASN.1结构：
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
The fields in TaggedCertificationRequest have the following meaning:
TaggedCertificationRequest中的字段具有以下含义：
bodyPartID is the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.
bodyPartID是此认证请求的标识号。有关车身部件标识符的详细信息，请参见第3.2.2节。
certificationRequest contains the PKCS-#10-based certification request. Its fields are described in [PKCS10].
certificationRequest包含基于PKCS-#10的认证请求。其字段如[PKCS10]所述。
When producing a certification request based on PKCS #10, clients MUST produce the certification request with a subject name and public key. Some PKI products are operated using a central repository of information to assign subject names upon receipt of a certification request. To accommodate this mode of operation, the subject field in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject field MAY reject such certification requests. If rejected and a PKI Response is returned, the CA MUST return a PKI Response with the CMCFailInfo value with the value badRequest.
基于PKCS#10生成认证请求时，客户端必须生成具有主体名称和公钥的认证请求。一些PKI产品在收到认证请求时使用中央信息库来分配主题名称。为了适应这种操作模式，CertificationRequest中的subject字段可以为NULL，但必须存在。接收带有空主题字段的CertificationRequest的CA可以拒绝此类认证请求。如果拒绝并返回PKI响应，CA必须返回带有CMCFailInfo值和badRequest值的PKI响应。
A CRMF message uses the following ASN.1 structure (defined in [CRMF] and included here for convenience):
CRMF消息使用以下ASN.1结构（在[CRMF]中定义，为方便起见包括在此处）：
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
The fields in CertReqMsg are explained in [CRMF].
[CRMF]中解释了CertReqMsg中的字段。
This document imposes the following additional restrictions on the construction and processing of CRMF certification requests:
本文件对CRMF认证申请的构建和处理施加了以下附加限制：
When a Full PKI Request includes a CRMF certification request, both the subject and publicKey fields in the CertTemplate MUST be defined. The subject field can be encoded as NULL, but MUST be present.
当完整PKI请求包括CRMF认证请求时，必须定义CertTemplate中的subject和publicKey字段。主题字段可以编码为空，但必须存在。
When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control.
当CRMF和CMC控件具有同等功能时，应使用CMC控件。CMC控件必须覆盖CRMF控件。
The regInfo field MUST NOT be used on a CRMF certification request. Equivalent functionality is provided in the CMC regInfo control (Section 6.12).
regInfo字段不得用于CRMF认证请求。CMC regInfo控件中提供了等效功能（第6.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. The value of encrCert in SubsequentMessage MUST NOT be used.
本协议不支持证明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 CRMF certification request. Servers MUST be able to process all extensions defined, but not prohibited in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process 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 keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension, the server MUST respond with a Full PKI Response with a CMCFailInfo value with the value of unsupportedExt.
服务器不需要使用客户机在CRMF认证请求中建议的所有值。服务器必须能够处理[PKIXCERT]中定义但未禁止的所有扩展。服务器不需要能够处理使用此协议传输的其他X.509v3扩展，也不需要能够处理专用扩展。允许服务器修改客户端请求的扩展。服务器不得更改扩展以使客户端请求的扩展的原始意图无效。（例如，将密钥使用从keyAgreement更改为digitalSignature。）如果由于无法处理请求的扩展而拒绝了认证请求，则服务器必须使用值为unsupportedExt的CMCFailInfo值响应完整的PKI响应。
This document allows for other certification request formats to be defined and used as well. An example of an other certification request format is one for Attribute Certificates. These other certification request formats are defined by specifying an OID for identification and the structure to contain the data to be passed.
本文件还允许定义和使用其他认证申请格式。其他证书请求格式的一个示例是属性证书格式。这些其他认证请求格式是通过指定标识的OID和包含要传递的数据的结构来定义的。
The cmsSequence field of the PKIData and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is:
PKIData和PKIResponse消息的cmsSequence字段包含零个或多个标记的内容信息对象。此结构的语法为：
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
The fields in TaggedContentInfo have the following meaning:
TaggedContentInfo中的字段具有以下含义：
bodyPartID is a unique integer that identifies this content info object.
bodyPartID是标识此内容信息对象的唯一整数。
contentInfo is a ContentInfo object (defined in [CMS]).
contentInfo是一个contentInfo对象（在[CMS]中定义）。
The four content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData, and SignedData. All of these content types are defined in [CMS].
cmsSequence中使用的四种内容类型是AuthenticatedData、Data、EnvelopedData和SignedData。所有这些内容类型都在[CMS]中定义。
The AuthenticatedData content type provides a method of doing pre-shared-secret-based validation of data being sent between two parties. Unlike SignedData, it does not specify which party actually generated the information.
AuthenticatedData内容类型提供了一种对双方之间发送的数据进行预共享的基于秘密的验证的方法。与SignedData不同，它没有指定实际生成信息的一方。
AuthenticatedData provides origination authentication in those circumstances where a shared-secret exists, but a PKI-based trust has not yet been established. No PKI-based trust may have been established because a trust anchor has not been installed on the client or no certificate exists for a signing key.
AuthenticatedData在存在共享秘密但尚未建立基于PKI的信任的情况下提供发起身份验证。可能未建立基于PKI的信任，因为客户端上未安装信任锚，或者不存在签名密钥的证书。
AuthenticatedData content type is used by this document for:
此文档将AuthenticatedData内容类型用于：
The id-cmc-authData control (Section 6.16), and
id cmc authData控件（第6.16节），以及
The top-level wrapper in environments where an encryption-only key is being certified.
在仅加密密钥被认证的环境中的顶级包装器。
This content type can include both PKIData and PKIResponse as the encapsulated content types. These embedded content types can contain additional controls that need to be processed.
此内容类型可以包括PKIData和PKIResponse作为封装的内容类型。这些嵌入的内容类型可以包含需要处理的其他控件。
The Data content type allows for general transport of unstructured data.
数据内容类型允许非结构化数据的常规传输。
The Data content type is used by this document for:
本文档将数据内容类型用于：
Holding the encrypted random value y for POP proof in the encrypted POP control (see Section 6.7).
在加密的POP控件中保存用于POP验证的加密随机值y（参见第6.7节）。
The EnvelopedData content type provides for shrouding of data.
EnvelopedData内容类型用于覆盖数据。
The EnvelopedData content type is the primary confidentiality method for sensitive information in this protocol. EnvelopedData can provide encryption of an entire PKI Request (see Section 5). EnvelopedData can also be used to wrap private key material for key archival. If the decryption on an EnvelopedData fails, a Full PKI Response is returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
信封数据内容类型是本协议中敏感信息的主要保密方法。EnvelopedData可以为整个PKI请求提供加密（请参见第5节）。EnvelopedData还可用于包装密钥存档的私钥材料。如果对EnvelopedData的解密失败，将返回完整的PKI响应，其中CMCFailInfo值为badMessageCheck，bodyPartID为0。
The SignedData content type provides for authentication and integrity.
SignedData内容类型提供身份验证和完整性。
The SignedData content type is used by this document for:
本文档将SignedData内容类型用于：
The outer wrapper for a PKI Request.
PKI请求的外部包装。
The outer wrapper for a PKI Response.
PKI响应的外部包装。
As part of processing a PKI Request/Response, the signature(s) MUST be verified. If the signature does not verify and the PKI Request/ Response contains anything other than a CMC Status Info control, a Full PKI Response containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPartID of 0.
作为处理PKI请求/响应的一部分，必须验证签名。如果签名未验证且PKI请求/响应包含CMC状态信息控件以外的任何内容，则必须使用值为badMessageCheck且bodyPartID为0的CMCFailInfo返回包含CMC状态信息控件的完整PKI响应。
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields are not populated.
对于PKI响应，SignedData允许服务器对返回的数据（如果存在）进行签名，并携带与PKI请求相对应的证书和CRL。如果在证书和CRL之外没有返回任何数据，则不会填充封装的信息和签名信息字段。
The otherMsgSequence field of the PKI Request/Response allows for arbitrary data objects to be carried as part of a PKI Request/ Response. This is intended to contain a data object that is not already wrapped in a cmsSequence field (Section 3.2.1.3). The data object is ignored unless a control references the data object by bodyPartID.
PKI请求/响应的otherMsgSequence字段允许作为PKI请求/响应的一部分携带任意数据对象。这旨在包含尚未包装在cmsSequence字段中的数据对象（第3.2.1.3节）。除非控件按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 }
The fields in OtherMsg have the following meaning:
OtherMsg中的字段具有以下含义：
bodyPartID is the unique id identifying this data object.
bodyPartID是标识此数据对象的唯一id。
otherMsgType is the OID that defines the type of message body.
otherMsgType是定义消息正文类型的OID。
otherMsgValue is the data.
otherMsgValue是数据。
Each element of a PKIData or PKIResponse has an associated body part identifier. The body part identifier is a 4-octet integer using the ASN.1 of:
PKIData或PKIResponse的每个元素都有一个关联的主体部分标识符。身体部位标识符是使用ASN.1的4个八位整数：
bodyIdMax INTEGER ::= 4294967295
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
BodyPartID ::= INTEGER(0..bodyIdMax)
Body part identifiers are 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. Body part identifiers can be duplicated in different layers (for example, a PKIData embedded within another).
身体部位标识符编码在CertReqMsg对象的CertReqID字段（在TaggedRequest中）或其他对象的bodyPartID字段中。在单个PKIData或PKIResponse中，正文部分标识符必须是唯一的。身体部位标识符可以在不同的层中复制（例如，嵌入另一层中的PKI数据）。
The bodyPartID value of 0 is reserved for use as the reference to the current PKIData object.
bodyPartID值0保留用作对当前PKIData对象的引用。
Some controls, such as the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to refer to a PKI Request in the current PKIData. Some controls, such as the Extended CMC Status Info control (Section 6.1.1), will also use body part identifiers to refer to elements in the previous PKI Request/
某些控件，例如添加扩展控件（第6.5.2节），使用pkiDataReference字段中的主体部分标识符来引用当前PKIData中的PKI请求。某些控件，如扩展CMC状态信息控件（第6.1.1节），也将使用身体部位标识符来引用先前PKI请求中的元素/
Response. This allows an error to be explicit about the control or PKI Request to which the error applies.
回答这使得错误可以明确表示应用错误的控件或PKI请求。
A BodyPartList contains a list of body parts in a PKI Request/ Response (i.e., the Batch Request control in Section 6.17). The ASN.1 type BodyPartList is defined as:
BodyPartList包含PKI请求/响应中的BodyPart列表（即第6.17节中的批量请求控制）。ASN.1类型BodyPartList定义为：
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
A BodyPartPath contains a path of body part identifiers moving through nesting (i.e., the Modify Certification Request control in Section 6.5.1). The ASN.1 type BodyPartPath is defined as:
BodyPartPath包含通过嵌套移动的车身零件标识符路径（即第6.5.1节中的修改认证请求控制）。ASN.1类型BodyPartPath定义为：
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
There is sometimes a need to include data in a PKI Request designed to be removed by an RA during processing. An example of this is the inclusion of an encrypted private key, where a Key Archive Agent removes the encrypted private key before sending it on to the CA. One side effect of this desire is that every RA that encapsulates this information needs to move the data so that it is not covered by that RA's signature. (A client PKI Request encapsulated by an RA cannot have a signed control removed by the Key Archive Agent without breaking the RA's signature.) The CMC Unsigned Data attribute addresses this problem.
有时需要在PKI请求中包含数据，以便RA在处理过程中删除。这方面的一个例子是包含加密私钥，其中密钥存档代理在将加密私钥发送到CA之前删除该私钥。这种愿望的一个副作用是，封装该信息的每个RA都需要移动数据，以便该RA的签名不覆盖该数据。（由RA封装的客户端PKI请求不能在不破坏RA签名的情况下由密钥存档代理删除签名控件。）CMC Unsigned Data属性解决了此问题。
The CMC Unsigned Data attribute contains information that is not directly signed by a client. When an RA encounters this attribute in the unsigned or unauthenticated attribute field of a request it is aggregating, the CMC Unsigned Data attribute is removed from the request prior to placing the request in a cmsSequence and placed in the unsigned or unauthenticated attributes of the RA's signed or authenticated data wrapper.
CMC Unsigned Data属性包含未经客户端直接签名的信息。当RA在其聚合的请求的未签名或未经验证的属性字段中遇到此属性时，在将请求放入CMS序列之前，会从请求中删除CMC未签名数据属性，并将其放入RA的已签名或已验证数据包装器的未签名或未经验证的属性中。
The CMC Unsigned Data attribute is identified by:
CMC未签名数据属性由以下内容标识：
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
The CMC Unsigned Data attribute has the ASN.1 definition:
CMC Unsigned Data属性具有ASN.1定义：
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
The fields in CMCUnsignedData have the following meaning:
CMCUnsignedData中的字段具有以下含义：
bodyPartPath is the path pointing to the control associated with this data. When an RA moves the control in an unsigned or unauthenticated attribute up one level as part of wrapping the data in a new SignedData or AuthenticatedData, the body part identifier of the embedded item in the PKIData is prepended to the bodyPartPath sequence.
bodyPartPath是指向与此数据关联的控件的路径。当RA将未签名或未经验证属性中的控件上移一级，作为将数据包装到新的SignedData或AuthenticatedData中的一部分时，PKIData中嵌入项的主体部分标识符将前置到bodyPartPath序列。
identifier is the OID that defines the associated data.
标识符是定义关联数据的OID。
content is the data.
内容就是数据。
There MUST be at most one CMC Unsigned Data attribute in the UnsignedAttribute sequence of a SignerInfo or in the UnauthenticatedAttribute sequence of an AuthenticatedData. UnsignedAttribute consists of a set of values; the attribute can have any number of values greater than zero in that set. If the CMC Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it MUST appear with the same values(s) in all SignerInfo and AuthenticatedData items.
SignerInfo的UnsignedAttribute序列或AuthenticatedData的UnauthenticatedAttribute序列中最多必须有一个CMC Unsigned Data属性。UnsignedAttribute由一组值组成；该属性在该集中可以有任意数量大于零的值。如果CMC Unsigned Data属性位于一个SignerInfo或AuthenticatedData中，则它必须在所有SignerInfo和AuthenticatedData项中显示相同的值。
Two types of PKI Responses exist. This section gives the details on both types.
存在两种类型的PKI响应。本节给出了这两种类型的详细信息。
Clients MUST be able to process the Simple PKI Response. The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response are returned in the certificate field of the SignedData.
客户端必须能够处理简单的PKI响应。简单的PKI响应由SignedData组成，其中不包含封装的ContentInfo和SignerinInfo。PKI响应中请求的证书将在SignedData的证书字段中返回。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, 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 use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) should be used in the event that the server intends the client to accept one or more certificates as trust anchors. This requires the use of the Full PKI Response message.)
客户端不得假定证书是按任何顺序排列的。服务器应包括形成到一个或多个信任锚的完整证书路径所需的所有中间证书，而不仅仅是新颁发的证书。服务器还可以在CRL包中返回CRL。服务器可能包括自签名证书。客户端不能仅仅因为其存在于证书包中而隐式信任包含的自签名证书。如果客户端从服务器接收到新的自签名证书，客户端应提供一种机制，使用户能够将该证书用作信任锚。（如果服务器希望客户端接受一个或多个证书作为信任锚，则应使用发布信任锚控件（第6.15节）。这需要使用完整的PKI响应消息。）
Clients MUST be able to process a Full PKI Response.
客户端必须能够处理完整的PKI响应。
The Full PKI Response consists of a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.
完整的PKI响应由封装PKI响应内容类型的SignedData或AuthenticatedData组成。PKI响应中颁发的证书将在立即封装的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 trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include 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 MAY provide a mechanism to enable the user to explicitly use the certificate as a trust anchor. (The Publish Trust Anchors control (Section 6.15) exists for the purpose of allowing for distribution of trust anchor certificates. If a trusted anchor publishes a new trusted anchor, this is one case where automated trust of the new trust anchor could be allowed.)
客户端不得假定证书是按任何顺序排列的。服务器应包括形成到一个或多个信任锚的完整链所需的所有中间证书，而不仅仅是新颁发的证书。服务器还可以在CRL包中返回CRL。服务器可能包括自签名证书。客户端不能仅仅因为其存在于证书包中而隐式信任包含的自签名证书。在客户端从服务器接收到新的自签名证书的情况下，客户端可以提供一种机制，使用户能够显式地将该证书用作信任锚。（发布信任锚控件（第6.15节）的存在是为了允许分发信任锚证书。如果受信任锚发布新的受信任锚，这是允许自动信任新信任锚的一种情况。）
The PKIResponse content type is used for the Full PKI Response. The PKIResponse content type is identified by:
PKI响应内容类型用于完整的PKI响应。PKI响应内容类型由以下内容标识：
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
The ASN.1 structure corresponding to the PKIResponse content type is:
与PKI响应内容类型对应的ASN.1结构为：
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ReponseBody ::= PKIResponse
ReponseBody ::= PKIResponse
Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has been renamed to PKIResponse for clarity and the old name kept as a synonym.
注意：在[RFC2797]中，这个ASN.1类型被命名为ResponseBody。为了清晰起见，它被重命名为PKIResponse，旧名称作为同义词保留。
The fields in PKIResponse have the following meaning:
PKI响应中的字段具有以下含义：
controlSequence is a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure are found in Section 3.2.1.1.
controlSequence是一系列控件。本文件中定义的控制见第6节。控制可由其他方定义。有关TaggedAttribute结构的详细信息，请参见第3.2.1.1节。
cmsSequence is a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.
cmsSequence是[CMS]消息对象的序列。详见第3.2.1.3节。
otherMsgSequence is a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
otherMsgSequence是任意数据对象的序列。放置在此处的数据对象由一个或多个控件引用。这允许控件使用大量数据，而无需将数据嵌入控件中。详见第3.2.1.4节。
Processing of PKIResponse by a recipient is as follows:
收件人对PKI响应的处理如下：
1. All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing.
1. 应以适当的方式检查和处理所有控制措施。适当的处理方法是此时完成处理，忽略该控件，或将该控件放在待办事项列表上以供以后处理。
2. Additional processing of non-element items includes the saving of certificates and CRLs present in wrapping layers. This type of processing is based on the consumer of the element and should not be relied on by generators.
2. 非元素项的附加处理包括保存包装层中的证书和CRL。这种类型的处理基于元件的使用者，不应依赖于生成器。
No processing is required for cmsSequence or otherMsgSequence members of the PKIResponse, if items are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are to be ignored.
如果项存在且未被控件引用，则无需对PKI响应的cmsSequence或其他MSGSequence成员进行处理。在这种情况下，将忽略cmsSequence和其他MSGSequence成员。
There are occasions when a PKI Request or Response must be encrypted in order to prevent disclosure of information in the PKI Request/ Response from being accessible to unauthorized entities. This section describes the means to encrypt Full PKI Requests and Responses (Simple PKI Requests cannot be encrypted). Data portions of PKI Requests and Responses that are placed in the cmsSequence field can be encrypted separately.
有时，必须对PKI请求或响应进行加密，以防止未经授权的实体访问PKI请求/响应中的信息。本节介绍加密完整PKI请求和响应的方法（无法加密简单的PKI请求）。放置在cmsSequence字段中的PKI请求和响应的数据部分可以单独加密。
Confidentiality is provided by wrapping the PKI Request/Response (a SignedData) in an EnvelopedData. 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. It is recommended that if an EnvelopedData layer is
通过将PKI请求/响应（签名数据）包装在信封数据中来提供机密性。信封数据中的嵌套内容类型为id SignedData。请注意，这与S/MIME不同，S/MIME在加密和签名数据之间放置了MIME层。建议如果使用EnvelopedData层
applied to a PKI Request/Response, a second signature layer be placed outside of the EnvelopedData layer. The following figure shows how this nesting would be done:
应用于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
Note: PKIResponse can be substituted for PKIData in the above figure.
注：上图中PKIResponse可以替代PKIData。
Options 1 and 2 prevent leakage of sensitive data by encrypting the Full PKI Request/Response. An RA that receives a PKI Request that it cannot decrypt MAY reject the PKI Request unless it can process the PKI Request without knowledge of the contents (i.e., all it does is amalgamate multiple PKI Requests and forward them to a server).
选项1和2通过加密完整的PKI请求/响应来防止敏感数据泄漏。接收到无法解密的PKI请求的RA可能会拒绝PKI请求，除非其能够在不知道内容的情况下处理PKI请求（即，它所做的只是合并多个PKI请求并将其转发到服务器）。
After the RA removes the envelope and completes processing, it may then apply a new EnvelopedData layer to protect PKI Requests for transmission to the next processing agent. Section 7 contains more information about RA processing.
RA移除信封并完成处理后，可能会应用新的EnvelopedData层来保护PKI请求，以便传输到下一个处理代理。第7节包含有关RA处理的更多信息。
Full PKI Requests/Responses can be encrypted or transmitted in the clear. Servers MUST provide support for all three options.
完整的PKI请求/响应可以以明文形式加密或传输。服务器必须为所有三个选项提供支持。
Alternatively, an authenticated, secure channel could exist between the parties that require confidentiality. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of Simple and Full PKI Requests/ Responses.
或者，需要保密的各方之间可以存在经过身份验证的安全通道。客户机和服务器可以使用此类信道而不是上述技术来提供简单和完整的PKI请求/响应的安全、私有通信。
Controls are carried as part of both Full PKI Requests and Responses. Each control is encoded as a unique OID followed by the data for the control (see syntax in Section 3.2.1.1. The encoding of the data is based on the control. Processing systems would first detect the OID (TaggedAttribute attrType) and process the corresponding control value (TaggedAttribute attrValues) prior to processing the message body.
控制作为完整PKI请求和响应的一部分进行。每个控件被编码为一个唯一的OID，后跟控件的数据（参见第3.2.1.1节中的语法）。数据的编码基于控件。处理系统将首先检测OID（TaggedAttribute attrType）并在处理消息体之前处理相应的控件值（TaggedAttribute AttrValue）。
The OIDs are all defined under the following arc:
OID均在以下圆弧下定义：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
The following table lists the names, OID, and syntactic structure for each of the controls described in this document.
下表列出了本文档中描述的每个控件的名称、OID和语法结构。
Identifier Description OID ASN.1 Structure Section
--------------------------------------------------------------------
id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2
id-cmc-identification id-cmc 2 UTF8String 6.2.3
id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2
id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4
id-cmc-transactionId id-cmc 5 INTEGER 6.6
id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6
id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6
id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2
id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7
id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7
id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8
id-cmc-getCert id-cmc 15 GetCert 6.9
id-cmc-getCRL id-cmc 16 GetCRL 6.10
id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11
id-cmc-regInfo id-cmc 18 OCTET STRING 6.12
id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12
id-cmc-queryPending id-cmc 21 OCTET STRING 6.13
id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1
id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1
id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1
id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14
id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1
id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15
id-cmc-authData id-cmc 27 AuthPublish 6.16
id-cmc-batchRequests id-cmc 28 BodyPartList 6.17
id-cmc-batchResponses id-cmc 29 BodyPartList 6.17
id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18
id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1
id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19
id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1
Identifier Description OID ASN.1 Structure Section
--------------------------------------------------------------------
id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2
id-cmc-identification id-cmc 2 UTF8String 6.2.3
id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2
id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4
id-cmc-transactionId id-cmc 5 INTEGER 6.6
id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6
id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6
id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2
id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7
id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7
id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8
id-cmc-getCert id-cmc 15 GetCert 6.9
id-cmc-getCRL id-cmc 16 GetCRL 6.10
id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11
id-cmc-regInfo id-cmc 18 OCTET STRING 6.12
id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12
id-cmc-queryPending id-cmc 21 OCTET STRING 6.13
id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1
id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1
id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1
id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14
id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1
id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15
id-cmc-authData id-cmc 27 AuthPublish 6.16
id-cmc-batchRequests id-cmc 28 BodyPartList 6.17
id-cmc-batchResponses id-cmc 29 BodyPartList 6.17
id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18
id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1
id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19
id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1
Table 1: CMC Control Attributes
表1:CMC控件属性
The CMC Status Info controls return information about the status of a client/server request/response. Two controls are described in this section. The Extended CMC Status Info control is the preferred control; the CMC Status Info control is included for backwards compatibility with RFC 2797.
CMC状态信息控制返回有关客户端/服务器请求/响应状态的信息。本节介绍了两个控件。扩展CMC状态信息控件是首选控件；包含CMC状态信息控件是为了向后兼容RFC 2797。
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 PKI Response. Servers MUST use the Extended CMC Status Info control, but MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended
服务器可能会发出多个CMC状态信息控件，这些控件引用单个主体部分。客户端必须能够在PKI响应中处理多个CMC状态信息控件。服务器必须使用扩展的CMC状态信息控件，但还可以使用CMC状态信息控件。客户端必须能够处理扩展的
CMC Status Info control.
CMC状态信息控件。
The Extended CMC Status Info control is identified by the OID:
扩展CMC状态信息控件由OID标识：
id-cmc-statusInfoV2 ::= { id-cmc 25 }
id-cmc-statusInfoV2 ::= { id-cmc 25 }
The Extended CMC Status Info control has the ASN.1 definition:
扩展CMC状态信息控件具有ASN.1定义：
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
The fields in CMCStatusInfoV2 have the following meaning:
CMCStatusInfoV2中的字段具有以下含义：
cMCStatus contains the returned status value. Details are in Section 6.1.3.
cMCStatus包含返回的状态值。详情见第6.1.3节。
bodyList identifies the controls or other elements to which the status value applies. If an error is returned for a Simple PKI Request, this field is the bodyPartID choice of BodyPartReference with the single integer of value 1.
bodyList标识应用状态值的控件或其他元素。如果简单PKI请求返回错误，则此字段是BodyPartReference的bodyPartID选项，其单个整数的值为1。
statusString contains additional description information. This string is human readable.
statusString包含其他描述信息。此字符串是可读的。
otherInfo contains additional information that expands on the CMC status code returned in the cMCStatus field.
otherInfo包含扩展cMCStatus字段中返回的CMC状态代码的附加信息。
The fields in OtherStatusInfo have the following meaning:
OtherStatusInfo中的字段具有以下含义：
failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.
故障信息如第6.1.4节所述。它提供了一个错误代码，详细说明了发生的故障。仅当cMCStatus包含值failed时，此选项才存在。
pendInfo contains information about when and how the client should request the result of this request. It is present when the cMCStatus is either pending or partial. pendInfo uses the structure PendInfo, which has the fields:
pendInfo包含有关客户端何时以及如何请求此请求结果的信息。当cMCStatus处于挂起状态或部分状态时，它存在。pendInfo使用结构pendInfo，该结构包含以下字段：
pendToken is the token used in the Query Pending control (Section 6.13).
pendToken是查询挂起控制中使用的令牌（第6.13节）。
pendTime contains the suggested time the server wants to be queried about the status of the certification request.
pendTime包含服务器希望查询认证请求状态的建议时间。
extendedFailInfo includes application-dependent detailed error information. This choice is present only if cMCStatus contains the value failed. Caution should be used when defining new values as they may not be correctly recognized by all clients and servers. The CMCFailInfo value of internalCAError may be assumed if the extended error is not recognized. This field uses the type ExtendedFailInfo. ExtendedFailInfo has the fields:
extendedFailInfo包括依赖于应用程序的详细错误信息。仅当cMCStatus包含值failed时，此选项才存在。定义新值时应小心，因为它们可能无法被所有客户端和服务器正确识别。如果无法识别扩展错误，则可以假定internalCAError的CMCFailInfo值。此字段使用ExtendedFailInfo类型。ExtendedFailInfo包含以下字段：
failInfoOID contains an OID that is associated with a set of extended error values.
failInfoOID包含与一组扩展错误值关联的OID。
failInfoValue contains an extended error code from the defined set of extended error codes.
failInfoValue包含定义的扩展错误代码集中的扩展错误代码。
If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.
如果cMCStatus字段为success，则扩展CMC状态信息控件可能会被忽略，除非它是响应中的唯一项。
The CMC Status Info control is identified by the OID:
CMC状态信息控件由OID标识：
id-cmc-statusInfo ::= { id-cmc 1 }
id-cmc-statusInfo ::= { id-cmc 1 }
The CMC Status Info control has the ASN.1 definition:
CMC状态信息控件具有ASN.1定义：
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
The fields in CMCStatusInfo have the following meaning:
CMCStatusInfo中的字段具有以下含义：
cMCStatus contains the returned status value. Details are in Section 6.1.3.
cMCStatus包含返回的状态值。详情见第6.1.3节。
bodyList contains the list of controls or other elements to which the status value applies. If an error is being returned for a Simple PKI Request, this field contains a single integer of value 1.
bodyList包含应用状态值的控件或其他元素的列表。如果简单PKI请求返回错误，则此字段包含一个值为1的整数。
statusString contains additional description information. This string is human readable.
statusString包含其他描述信息。此字符串是可读的。
otherInfo provides additional information that expands on the CMC status code returned in the cMCStatus field.
otherInfo提供了扩展cMCStatus字段中返回的CMC状态代码的附加信息。
failInfo is described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus is failed.
故障信息如第6.1.4节所述。它提供了一个错误代码，详细说明了发生的故障。仅当cMCStatus失败时，此选项才存在。
pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It contains information about when and how the client should request results of this request. The pendInfo field MUST be populated for a cMCStatus value of pending or partial. Further
pendInfo使用第6.1.1节中的pendInfo ASN.1结构。它包含有关客户端何时以及如何请求此请求结果的信息。必须为pending或partial的cMCStatus值填充pendInfo字段。进一步的
details can be found in Section 6.1.1 (Extended CMC Status Info Control) and Section 6.13 (Query Pending Control ).
有关详细信息，请参见第6.1.1节（扩展CMC状态信息控制）和第6.13节（查询挂起控制）。
If the cMCStatus field is success, the CMC Status Info control MAY be omitted unless it is the only item in the response. If no status exists for a Simple or Full PKI Request, then the value of success is assumed.
如果cMCStatus字段为success，则可以省略CMC状态信息控件，除非它是响应中的唯一项。如果简单或完整PKI请求的状态不存在，则假定成功值。
CMCStatus is a field in the Extended CMC Status Info and CMC Status Info controls. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure:
CMCStatus是扩展CMC状态信息和CMC状态信息控件中的一个字段。此字段包含表示特定操作成功或失败的代码。CMCStatus具有ASN.1结构：
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
The values of CMCStatus have the following meaning:
CMCStatus的值具有以下含义：
success indicates the request was granted or the action was completed.
成功表示请求已被批准或操作已完成。
failed indicates the request was not granted or the action was not completed. More information is included elsewhere in the response.
failed表示请求未被批准或操作未完成。答复的其他部分包括了更多信息。
pending indicates the PKI Request has yet to be processed. The requester is responsible to poll back on this Full PKI request. pending may only be returned for certification request operations.
挂起表示尚未处理PKI请求。请求者负责轮询此完整PKI请求。只能为证书请求操作返回挂起。
noSupport indicates the requested operation is not supported.
noSupport表示不支持请求的操作。
confirmRequired indicates a Confirm Certificate Acceptance control (Section 6.14) must be returned before the certificate can be used.
confirmRequired表示在使用证书之前，必须返回确认证书验收控制（第6.14节）。
popRequired indicates a direct POP operation is required (Section 6.3.1.3).
popRequired表示需要直接POP操作（第6.3.1.3节）。
partial indicates a partial PKI Response is returned. The requester is responsible to poll back for the unfulfilled portions of the Full PKI Request.
partial表示返回部分PKI响应。请求者负责轮询完整PKI请求的未完成部分。
CMCFailInfo is a field in the Extended CMC Status Info and CMC Status Info controls. CMCFailInfo conveys more detailed information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfo是扩展CMC状态信息和CMC状态信息控件中的一个字段。CMCFailInfo传达了与故障条件解释相关的更详细信息。CMCFailInfo具有以下ASN.1结构：
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
The values of CMCFailInfo have the following meanings:
CMCFailInfo的值具有以下含义：
badAlg indicates unrecognized or unsupported algorithm.
badAlg表示无法识别或不支持的算法。
badMessageCheck indicates integrity check failed.
badMessageCheck表示完整性检查失败。
badRequest indicates transaction was not permitted or supported.
badRequest表示不允许或不支持事务。
badTime indicates message time field was not sufficiently close to the system time.
badTime表示消息时间字段与系统时间不够接近。
badCertId indicates no certificate could be identified matching the provided criteria.
badCertId表示无法识别符合所提供标准的证书。
unsupportedExt indicates a requested X.509 extension is not supported by the recipient CA.
unsupportedExt表示收件人CA不支持请求的X.509扩展。
mustArchiveKeys indicates private key material must be supplied.
mustArchiveKeys表示必须提供私钥材料。
badIdentity indicates identification control failed to verify.
badIdentity表示标识控制无法验证。
popRequired indicates server requires a POP proof before issuing certificate.
popRequired表示服务器在颁发证书之前需要POP证明。
popFailed indicates POP processing failed.
popFailed表示POP处理失败。
noKeyReuse indicates server policy does not allow key reuse.
noKeyReuse表示服务器策略不允许密钥重用。
internalCAError indicates that the CA had an unknown internal failure.
internalCAError表示CA存在未知的内部故障。
tryLater indicates that the server is not accepting requests at this time and the client should try at a later time.
tryLater表示服务器此时不接受请求，客户端应稍后再试。
authDataFail indicates failure occurred during processing of authenticated data.
authDataFail表示在处理经过身份验证的数据期间发生的故障。
If additional failure reasons are needed, they SHOULD use the ExtendedFailureInfo item in the Extended CMC Status Info control. However, for closed environments they can be defined using this type. Such codes MUST be in the range from 1000 to 1999.
如果需要其他故障原因，他们应使用扩展CMC状态信息控件中的ExtendedFailureInfo项。但是，对于封闭环境，可以使用此类型定义它们。此类代码必须介于1000到1999之间。
Some CAs and RAs 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 are familiar with a bank's request to provide your mother's maiden name as a form of identity proof. The reasoning behind requiring a proof-of-identity can be found in Appendix C of [CRMF].
一些CA和RA要求在认证请求中包含身份证明。许多不同的方法都有不同程度的安全性和可靠性。大多数人都熟悉银行要求提供你母亲的婚前姓作为身份证明的要求。要求提供身份证明的理由见[CRMF]附录C。
CMC provides a method to prove the client's identity based on a client/server shared-secret. If clients support the Full PKI Request, clients MUST implement this method of identity proof (Section 6.2.2). Servers MUST provide this method, but MAY additionally support bilateral methods of similar strength.
CMC提供了一种基于客户机/服务器共享机密证明客户机身份的方法。如果客户端支持完整的PKI请求，则客户端必须实现此身份证明方法（第6.2.2节）。服务器必须提供这种方法，但还可以支持类似强度的双边方法。
This document also provides an Identification control (Section 6.2.3). This control is a simple method to allow a client to state who they are to the server. Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier is placed in the Identification control, and the shared-secret is used to compute the Identity Proof control.
本文件还提供了识别控制（第6.2.3节）。此控件是一种简单的方法，允许客户端向服务器声明他们是谁。通常，共享机密和该共享机密的标识符从服务器传递到客户端。标识符放置在标识控件中，共享秘密用于计算身份验证控件。
The Identity Proof Version 2 control is identified by the OID:
身份验证版本2控件由OID标识：
id-cmc-identityProofV2 ::= { id-cmc 34 }
id-cmc-identityProofV2 ::= { id-cmc 34 }
The Identity Proof Version 2 control has the ASN.1 definition:
身份验证版本2控件具有ASN.1定义：
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}
}
The fields of IdentityProofV2 have the following meaning:
IdentityProofV2字段具有以下含义：
hashAlgID is the identifier and parameters for the hash algorithm used to convert the shared-secret into a key for the MAC algorithm.
hashAlgID是哈希算法的标识符和参数，用于将共享密钥转换为MAC算法的密钥。
macAlgID is the identifier and the parameters for the message authentication code algorithm used to compute the value of the witness field.
macAlgID是用于计算见证字段值的消息身份验证代码算法的标识符和参数。
witness is the identity proof.
证人是身份证明。
The required method starts with an out-of-band transfer of a token (the shared-secret). The shared-secret should be generated in a random manner. The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
所需的方法从令牌（共享密钥）的带外传输开始。共享秘密应以随机方式生成。此令牌的分发超出了本文档的范围。然后，客户端使用此令牌进行身份验证，如下所示：
1. The PKIData reqSequence field (encoded exactly as it appears in the Full PKI Request including the sequence type and length) is the value to be validated.
1. PKIData reqSequence字段（编码与完整PKI请求中显示的完全相同，包括序列类型和长度）是要验证的值。
2. A hash of the shared-secret as a UTF8 string is computed using hashAlgID.
2. 使用hashAlgID计算UTF8字符串形式的共享秘密哈希。
3. A MAC is then computed using the value produced in Step 1 as the message and the value from Step 2 as the key.
3. 然后，使用步骤1中产生的值作为消息，使用步骤2中的值作为密钥来计算MAC。
4. The result from Step 3 is then encoded as the witness value in the Identity Proof Version 2 control.
4. 然后将步骤3的结果编码为身份验证版本2控件中的见证值。
When the server verifies the Identity Proof Version 2 control, it computes the MAC value in the same way and compares it to the witness value contained in the PKI Request.
当服务器验证身份验证版本2控件时，它以相同的方式计算MAC值，并将其与PKI请求中包含的见证值进行比较。
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
如果服务器未通过身份验证版本2控件的验证，则完整PKI响应中必须存在CMCFailInfo值，并且该值必须为badIdentity。
Reuse of the shared-secret on certification request retries allows the client and server to maintain the same view of acceptable identity proof values. However, reuse of the shared-secret can potentially open the door for some types of attacks.
在认证请求重试时重用共享机密允许客户端和服务器维护可接受的身份证明值的相同视图。然而，重用共享秘密可能会为某些类型的攻击打开大门。
Implementations MUST be able to support tokens at least 16 characters long. Guidance on the amount of entropy actually obtained from a given length token based on character sets can be found in Appendix A of [PASSWORD].
实现必须能够支持至少16个字符长的令牌。关于基于字符集从给定长度令牌实际获得的熵量的指导，请参见[密码]的附录a。
The Identity Proof control is identified by the OID:
身份验证控件由OID标识：
id-cmc-identityProof ::= { id-cmc 3 }
id-cmc-identityProof ::= { id-cmc 3 }
The Identity Proof control has the ASN.1 definition:
身份验证控件具有ASN.1定义：
IdentifyProof ::= OCTET STRING
IdentifyProof ::= OCTET STRING
This control is processed in the same way as the Identity Proof Version 2 control. In this case, the hash algorithm is fixed to SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.
此控件的处理方式与身份验证版本2控件相同。在这种情况下，哈希算法固定为SHA-1，MAC算法固定为HMAC-SHA1。
Optionally, servers MAY require the inclusion of the unprotected Identification control with an Identification Proof control. The Identification control is intended to contain a text string that assists the server in locating the shared-secret needed to validate the contents of the Identity Proof control. If the Identification control is included in the Full PKI Request, the derivation of the key in Step 2 (from Section 6.2.1) is altered so that the hash of the concatenation of the shared-secret and the UTF8 identity value (without the type and length bytes) are hashed rather than just the shared-secret.
可选地，服务器可能需要将未受保护的标识控件包含在标识验证控件中。Identification控件旨在包含一个文本字符串，该字符串帮助服务器定位验证身份验证控件内容所需的共享机密。如果完整PKI请求中包含标识控制，则步骤2中密钥的推导（来自第6.2.1节）将被更改，以便对共享密钥和UTF8标识值（不含类型和长度字节）的串联哈希进行哈希，而不仅仅是共享密钥。
The Identification control is identified by the OID:
标识控制由OID标识：
id-cmc-identification ::= { id-cmc 2 }
id-cmc-identification ::= { id-cmc 2 }
The Identification control has the ASN.1 definition:
识别控制具有ASN.1的定义：
Identification ::= UTF8String
Identification ::= UTF8String
The shared-secret between the EE and the server is sometimes computed using a hardware device that generates a series of tokens. The EE can therefore prove its 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:
EE和服务器之间的共享秘密有时使用生成一系列令牌的硬件设备进行计算。因此，EE可以通过以纯文本和名称字符串传输此令牌来证明其身份。通过以下修改，上述协议可与硬件共享秘密令牌生成设备一起使用：
1. The Identification control MUST be included and MUST contain the hardware-generated token.
1. 必须包括标识控件，并且必须包含硬件生成的令牌。
2. The shared-secret value used above is the same hardware-generated token.
2. 上面使用的共享密钥值与硬件生成的令牌相同。
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.
3. 所有认证请求必须具有使用者名称，使用者名称必须包含标识硬件令牌设备持有者所需的字段。
4. The entire certification request MUST be shrouded in some fashion to prevent eavesdropping. Although the token is time critical, an active eavesdropper cannot be permitted to extract the token and submit a different certification request with the same token value.
4. 必须以某种方式覆盖整个认证请求，以防止窃听。尽管令牌是时间关键型的，但不允许主动窃听者提取令牌并提交具有相同令牌值的不同认证请求。
In a Full PKI Request, identity information about the client is carried in the signature of the SignedData containing all of the certification requests. Proof-of-possession information for key pairs, however, is carried separately for each PKCS #10 or CRMF certification request. (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 6.7 are used.) In order to prevent substitution-style attacks, the protocol must guarantee that the same entity generated both the POP and proof-of-identity information.
在完整的PKI请求中，有关客户端的身份信息包含在包含所有认证请求的已签名数据的签名中。但是，对于每个PKCS#10或CRMF认证请求，都会单独携带钥匙对的持有证明信息。（对于能够生成数字签名的密钥，POP由PKCS#10或CRMF请求上的签名提供。对于仅加密密钥，使用第6.7节中描述的控件。）为了防止替换式攻击，协议必须保证同一实体同时生成POP和身份证明信息。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 6.3.1.3) and shared-secret/subject distinguished name (DN) matching (Section 6.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 certification request that can be directly associated with the
本节描述了链接身份和POP信息的两种机制：以加密方式从共享机密（第6.3.1.3节）和共享机密/主题可分辨名称（DN）匹配（第6.3.2节）派生的见证值。客户端和服务器必须支持见证值技术。客户端和服务器可支持共享秘密/主题DN匹配或其他类似强度的双边技术。这两种机制背后的思想都是强制客户机在每个认证请求中签署一些数据，这些数据可以直接与
shared-secret; this will defeat attempts to include certification requests from different entities in a single Full PKI Request.
共享秘密；这将挫败在单个完整PKI请求中包含来自不同实体的认证请求的尝试。
The first technique that links identity and POP information forces the client to include a piece of information cryptographically derived from the shared-secret as a signed extension within each certification request (PKCS #10 or CRMF).
第一种链接身份和POP信息的技术迫使客户机在每个认证请求（PKCS#10或CRMF）中包含一条从共享机密加密派生的信息，作为签名扩展。
The POP Link Witness Version 2 control is identified by the OID:
POP链接见证版本2控件由OID标识：
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
The POP Link Witness Version 2 control has the ASN.1 definition:
POP链接见证版本2控件具有ASN.1定义：
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
The fields of PopLinkWitnessV2 have the following meanings:
PopLinkWitnessV2的字段具有以下含义：
keyGenAlgorithm contains the algorithm used to generate the key for the MAC algorithm. This will generally be a hash algorithm, but could be a more complex algorithm.
keyGenAlgorithm包含用于为MAC算法生成密钥的算法。这通常是一个哈希算法，但可能是一个更复杂的算法。
macAlgorithm contains the algorithm used to create the witness value.
macAlgorithm包含用于创建见证值的算法。
witness contains the computed witness value.
见证包含计算的见证值。
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 out-of-band from the server. The client then computes the following values:
如果使用空主题DN，此技术非常有用（因为，例如，服务器可以仅基于共享机密生成证书的主题DN）。当客户端从服务器接收到带外共享机密时，处理开始。然后，客户端计算以下值：
1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.
1. 客户端生成一个随机字节字符串R，长度至少为512位。
2. The key is computed from the shared-secret using the algorithm in keyGenAlgorithm.
2. 使用keyGenAlgorithm中的算法从共享密钥计算密钥。
3. A MAC is then computed over the random value produced in Step 1, using the key computed in Step 2.
3. 然后，使用在步骤2中计算的密钥，在步骤1中产生的随机值上计算MAC。
4. The random value produced in Step 1 is encoded as the value of a POP Link Random control. This control MUST be included in the Full PKI Request.
4. 在步骤1中产生的随机值被编码为POP-Link随机控件的值。此控件必须包含在完整的PKI请求中。
5. The MAC value produced in Step 3 is placed in either the POP Link Witness control or the witness field of the POP Link Witness V2 control.
5. 在步骤3中生成的MAC值放置在POP链接见证控件或POP链接见证V2控件的见证字段中。
* For CRMF, the POP Link Witness/POP Link Witness V2 control is included in the controls field of the CertRequest structure.
* 对于CRMF，CertRequest结构的控件字段中包含POP-Link见证/POP-Link见证V2控件。
* For PKCS #10, the POP Link Witness/POP Link Witness V2 control is included in the attributes field of the CertificationRequestInfo structure.
* 对于PKCS#10，在CertificationRequestInfo结构的属性字段中包含POP-Link见证/POP-Link见证V2控件。
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness/POP Link Witness V2 control and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control.
收到后，服务器必须验证每个认证请求是否包含POP-Link-Witness/POP-Link-Witness V2控件的副本，以及其值是否使用上述方法从POP-Link随机控件中包含的共享机密和随机字符串中派生。
The Identification control (see Section 6.2.3) or the subject DN of a certification request can be used to help identify which shared-secret was used.
身份控制（见第6.2.3节）或认证请求的主题DN可用于帮助识别使用了哪个共享机密。
The POP Link Witness control is identified by the OID:
POP链接见证控件由OID标识：
id-cmc-popLinkWitness ::= { id-cmc 23 }
id-cmc-popLinkWitness ::= { id-cmc 23 }
The POP Link Witness control has the ASN.1 definition:
POP链接见证控件具有ASN.1定义：
PopLinkWitness ::= OCTET STRING
PopLinkWitness ::= OCTET STRING
For this control, SHA-1 is used as the key generation algorithm. HMAC-SHA1 is used as the mac algorithm.
对于该控件，使用SHA-1作为密钥生成算法。mac算法采用HMAC-SHA1。
The POP Link Random control is identified by the OID:
POP-Link随机控件由OID标识：
id-cmc-popLinkRandom ::= { id-cmc 22 }
id-cmc-popLinkRandom ::= { id-cmc 22 }
The POP Link Random control has the ASN.1 definition:
POP-Link随机控件具有ASN.1定义：
PopLinkRandom ::= OCTET STRING
PopLinkRandom ::= OCTET STRING
The second technique to link identity and POP information 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 certification request. It is expected that many client-server connections that use shared-secret-based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certification request.)
链接身份和POP信息的第二种技术是将特定的主题可分辨名称（主题DN）链接到带外分发的共享机密，并要求使用共享机密来证明身份的客户端在每个认证请求中都包含该确切的主题DN。预计许多使用基于共享秘密的身份证明的客户机-服务器连接将使用此机制。（通常不会从认证请求中忽略主题DN信息。）
When the shared-secret is generated and transferred out-of-band to initiate the registration process (Section 6.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 accordance with the 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, it MUST use these two pieces of information as follows:
当生成共享密钥并将其传输到带外以启动注册过程（第6.2节）时，特定的主体DN也与共享密钥关联并与客户端通信。（根据CA策略，每个实体生成的主题DN必须是唯一的；不能使用空的主题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 certification request (PKCS #10 and/or CRMF) in the Full PKI Request. The subject names in the certification requests MUST NOT be null.
1. 客户机必须在完整PKI请求中的每个认证请求（PKCS#10和/或CRMF）中包含其收到的特定主题DN以及共享机密作为主题名称。认证请求中的使用者名称不得为空。
2. The client MUST include an Identity Proof control (Section 6.2.2) or Identity Proof Version 2 control (Section 6.2.1), derived from the shared-secret, in the Full PKI Request.
2. 客户端必须在完整的PKI请求中包含一个身份验证控件（第6.2.2节）或身份验证版本2控件（第6.2.1节），该控件源自共享机密。
The server receiving this message MUST (a) validate the Identity Proof control and then, (b) check that the subject DN included in each certification request matches that associated with the shared-secret. If either of these checks fails, the certification request MUST be rejected.
接收此消息的服务器必须（a）验证身份验证控件，然后（b）检查每个认证请求中包含的主题DN是否与共享机密相关联。如果其中任何一项检查失败，则必须拒绝认证请求。
When doing a renewal or rekey certification request, linking identity and POP information is simple. The client copies the subject DN for a current signing certificate into the subject name field of each certification request that is made. The POP for each certification request will now cover that information. The outermost signature layer is created using the current signing certificate, which allows
在执行续订或重新密钥认证请求时，链接身份和POP信息很简单。客户端将当前签名证书的使用者DN复制到每个证书请求的使用者名称字段中。每个认证请求的POP现在将涵盖该信息。最外层的签名层是使用当前签名证书创建的，该证书允许
the original identity to be associated with the certification request. Since the name in the current signing certificate and the names in the certification requests match, the necessary linking has been achieved.
要与认证请求关联的原始标识。由于当前签名证书中的名称与证书请求中的名称匹配，因此实现了必要的链接。
The Data Return control 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 Full PKI Response. Data placed in a Data Return control is considered to be opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response.
数据返回控件允许客户端向服务器发送任意数据（通常是某种类型的内部状态信息），并将数据作为完整PKI响应的一部分返回。放置在数据返回控件中的数据对于服务器来说是不透明的。完整PKI请求和响应都使用相同的控件。如果数据返回控件出现在完整PKI请求中，则服务器必须将其作为PKI响应的一部分返回。
In the event that the information in the Data Return control 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.
如果数据返回控制中的信息需要保密，预计客户会对包含的数据应用某种类型的加密，但其细节不在本规范的范围内。
The Data Return control is identified by the OID:
数据返回控制由OID标识：
id-cmc-dataReturn ::= { id-cmc 4 }
id-cmc-dataReturn ::= { id-cmc 4 }
The Data Return control has the ASN.1 definition:
数据返回控件具有ASN.1定义：
DataReturn ::= OCTET STRING
DataReturn ::= OCTET STRING
A client could use this control 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.
客户端可以使用此控件放置一个标识符，标记私钥材料的确切来源。这可能是包含私钥的硬件设备的标识符。
These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons. These include addition of certificate extensions or modification of subject and/or subject alternative names.
这些控件的存在使RAs能够修改认证请求的内容。出于各种原因，可能需要进行修改。其中包括增加证书扩展或修改受试者和/或受试者备选名称。
Two controls exist for this purpose. The first control, Modify Certification Request (Section 6.5.1), allows the RA to replace or remove any field in the certificate. The second control, Add Extensions (Section 6.5.2), only allows for the addition of extensions.
为此目的，有两种控制措施。第一个控件，修改认证请求（第6.5.1节），允许RA替换或删除证书中的任何字段。第二个控件“添加扩展”（第6.5.2节）仅允许添加扩展。
The Modify Certification Request control is used by RAs to change fields in a requested certificate.
RAs使用修改证书请求控件来更改所请求证书中的字段。
The Modify Certification Request control is identified by the OID:
修改认证请求控制由OID标识：
id-cmc-modCertTemplate ::= { id-cmc 31 }
id-cmc-modCertTemplate ::= { id-cmc 31 }
The Modify Certification Request has the ASN.1 definition:
修改认证请求具有ASN.1定义：
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
The fields in ModCertTemplate have the following meaning:
ModCertTemplate中的字段具有以下含义：
pkiDataReference is the path to the PKI Request containing certification request(s) to be modified.
pkiDataReference是指向包含要修改的证书请求的PKI请求的路径。
certReferences refers to one or more certification requests in the PKI Request referenced by pkiDataReference to be modified. Each BodyPartID of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the certificate extensions included in the certTemplate field are applied to every certification request referenced in the certReferences sequence. If a request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned that references this control.
certReferences是指PKI请求中的一个或多个证书请求，该请求由要修改的pkiDataReference引用。certReferences序列的每个BodyPartID必须等于TaggedCertificationRequest（PKCS#10）的BodyPartID或CertReqMsg（CRMF）中CertRequest的certReqId。根据定义，certTemplate字段中包含的证书扩展应用于certReferences序列中引用的每个证书请求。如果找不到与bodyPartID对应的请求，则返回引用此控件的值为badRequest的CMCFailInfo。
replace specifies if the target certification request is to be modified by replacing or deleting fields. If the value is TRUE, the data in this control replaces the data in the target certification request. If the value is FALSE, the data in the target certification request is deleted. The action is slightly different for the extensions field of certTemplate; each extension is treated individually rather than as a single unit.
replace指定是否通过替换或删除字段来修改目标认证请求。如果该值为TRUE，则此控件中的数据将替换目标认证请求中的数据。如果该值为FALSE，则删除目标认证请求中的数据。certTemplate的extensions字段的操作略有不同；每个扩展都单独处理，而不是作为单个单元处理。
certTemplate is a certificate template object [CRMF]. If a field is present and replace is TRUE, it replaces that field in the certification request. If the field is present and replace is FALSE, the field in the certification request is removed. If the field is absent, no action is performed. Each extension is treated as a single field.
certTemplate是一个证书模板对象[CRMF]。如果存在字段且“替换”为TRUE，则它将替换认证请求中的该字段。如果该字段存在且“替换”为FALSE，则将删除认证请求中的字段。如果该字段不存在，则不执行任何操作。每个扩展都被视为单个字段。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-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 Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
服务器必须能够处理[PKIXCERT]中定义但未被禁止的所有扩展。服务器不需要能够处理使用此协议传输的每个X.509v3扩展，也不需要能够处理其他专用扩展。服务器不需要将所有RA请求的扩展放入证书中。允许服务器修改RA请求的扩展。服务器不得更改扩展以反转客户端请求的扩展的含义。如果由于无法处理请求的扩展而拒绝证书请求，并且返回完整的PKI响应，则服务器必须返回值为unsupportedExt的CMCFailInfo值。
If a certification request is the target of multiple Modify Certification Request controls, the behavior is:
如果一个认证请求是多个修改认证请求控件的目标，则行为为：
o If control A exists in a layer that contains the layer of control B, control A MUST override control B. In other words, controls should be applied from the innermost layer to the outermost layer.
o 如果控件A存在于包含控件B层的层中，则控件A必须覆盖控件B。换句话说，控件应从最内层应用到最外层。
o If control A and control B are in the same PKIData (i.e., the same wrapping layer), the order of application is non-determinate.
o 如果控件A和控件B位于相同的PKI数据中（即，相同的包装层），则应用顺序是不确定的。
The same order of application is used if a certification request is the target of both a Modify Certification Request control and an Add Extensions control.
如果认证请求是修改认证请求控件和添加扩展控件的目标，则使用相同的应用程序顺序。
The Add Extensions control has been deprecated in favor of the Modify Certification Request control. It was replaced so that fields in the certification request other than extensions could be modified.
添加扩展控件已被弃用，取而代之的是修改证书请求控件。它已被替换，以便可以修改认证请求中除扩展以外的字段。
The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.
RAs使用Add Extensions控件指定要包含在证书中的其他扩展。
The Add Extensions control is identified by the OID:
添加扩展控件由OID标识：
id-cmc-addExtensions ::= { id-cmc 8 }
id-cmc-addExtensions ::= { id-cmc 8 }
The Add Extensions control has the ASN.1 definition:
添加扩展控件具有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
}
The fields in AddExtensions have the following meaning:
AddExtensions中的字段具有以下含义：
pkiDataReference contains the body part identity of the embedded certification request.
pkiDataReference包含嵌入式证书请求的主体部分标识。
certReferences is a list of references to one or more of the certification requests contained within a PKIData. Each body part identifier of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the listed extensions are to be applied to every certification request referenced in the certReferences sequence. If a certification request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned referencing this control.
certReferences是对PKIData中包含的一个或多个认证请求的引用列表。certReferences序列的每个主体部分标识符必须等于TaggedCertificationRequest（PKCS#10）的bodyPartID或CertReqMsg（CRMF）中CertRequest的certReqId。根据定义，列出的扩展将应用于certReferences序列中引用的每个认证请求。如果找不到与bodyPartID对应的认证请求，则将引用此控件返回值为badRequest的CMCFailInfo。
extensions is a sequence of extensions to be applied to the referenced certification requests.
扩展是应用于引用的认证请求的一系列扩展。
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-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 CMCFailInfo with the value of unsupportedExt.
服务器必须能够处理[PKIXCERT]中定义但未被禁止的所有扩展。服务器不需要能够处理使用此协议传输的每个X.509v3扩展，也不需要能够处理其他专用扩展。服务器不需要将所有RA请求的扩展放入证书中。允许服务器修改RA请求的扩展。服务器不得更改扩展以反转客户端请求的扩展的含义。如果由于无法处理请求的扩展而拒绝了认证请求并返回了响应，则服务器必须返回值为unsupportedExt的CMCFailInfo。
If multiple Add Extensions controls exist in a Full PKI Request, the exact behavior is left up to the CA policy. However, it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control (as opposed to an "all or nothing" approach).
如果一个完整的PKI请求中存在多个添加扩展控件，则具体行为由CA策略决定。但是，建议使用以下策略。这些规则将应用于addextensions控件中的单个扩展（与“全部或无”方法相反）。
1. If the conflict is within a single PKIData, the certification request would be rejected with a CMCFailInfo value of badRequest.
1. 如果冲突发生在单个PKIData中，则将使用CMCFailInfo值badRequest拒绝认证请求。
2. If the conflict is between different PKIData, the outermost version of the extension would be used (allowing an RA to override the requested extension).
2. 如果冲突发生在不同的PKI数据之间，则将使用最外层版本的扩展（允许RA覆盖请求的扩展）。
6.6. Transaction Identifier Control and Sender and Recipient Nonce Controls
6.6. 事务标识符控件以及发送方和接收方临时控件
Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.
使用事务标识符标识和跟踪事务。如果使用，客户端将生成事务标识符并保留其值，直到服务器响应完整的PKI响应完成事务。服务器相应地在完整的PKI响应中包括接收到的事务标识符。
The Transaction Identifier control is identified by the OID:
事务标识符控件由OID标识：
id-cmc-transactionId ::= { id-cmc 5 }
id-cmc-transactionId ::= { id-cmc 5 }
The Transaction Identifier control has the ASN.1 definition:
事务标识符控件具有ASN.1定义：
TransactionId ::= INTEGER
TransactionId ::= INTEGER
The Transaction Identifier control identifies a given transaction. It is used by client and server to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.
事务标识符控件标识给定的事务。客户端和服务器使用它来管理操作的状态。客户端可以在请求中包括事务标识符控件。如果原始请求包含事务标识符控件，则所有后续请求和响应必须包含相同的事务标识符控件。
Replay protection is supported through the use of the Sender and Recipient Nonce controls. If nonces are used, in the first message of a transaction, a Recipient Nonce control is not transmitted; a Sender Nonce control is included by the transaction originator and retained for later reference. The recipient of a Sender Nonce control reflects this value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. Upon receipt by the transaction originator of this response, the transaction originator compares the value of Recipient Nonce control to its retained value. If the values match, the message can be accepted for further security processing. The received value for a Sender Nonce control is also retained for inclusion in the next message associated with the same transaction.
通过使用发送方和接收方的Nonce控件支持重播保护。如果使用了Nonce，则在事务的第一条消息中，不传输接收方Nonce控制；发送方临时控制由事务发起人包括，并保留以供以后参考。发送方Nonce控件的接收方将此值作为接收方Nonce控件反射回发起方，并包括其自己的发送方Nonce控件。交易发起人收到此响应后，交易发起人会将接收方临时控制权的价值与其保留价值进行比较。如果值匹配，则可以接受该消息以进行进一步的安全处理。发送方Nonce控件的接收值也将保留，以便包含在与同一事务关联的下一条消息中。
The Sender Nonce and Recipient Nonce controls are identified by the OIDs:
发送方Nonce和接收方Nonce控件由OID标识：
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
The Sender Nonce control has the ASN.1 definition:
发送方Nonce控件具有ASN.1定义：
SenderNonce ::= OCTET STRING
SenderNonce ::= OCTET STRING
The Recipient Nonce control has the ASN.1 definition:
收件人Nonce控件具有ASN.1定义：
RecipientNonce ::= OCTET STRING
RecipientNonce ::= OCTET STRING
Clients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control and include a new value as its Sender Nonce control.
客户端可以在初始PKI请求中包括发送方Nonce控件。如果消息包括发送方Nonce控件，则响应必须包括先前接收的发送方Nonce控件的传输值作为接收方Nonce控件，并包括新值作为其发送方Nonce控件。
Servers MAY require that this POP method be used only if another POP method is unavailable. Servers SHOULD reject all certification 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 the entity that generated the certification request 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 steps:
根据需要，POP for encryption only密钥不能在一次往返中完成，因为有四个不同的步骤：
1. Client tells the server about the public component of a new encryption key pair.
1. 客户端告诉服务器新加密密钥对的公共组件。
2. Server sends the client a POP challenge, encrypted with the presented public encryption key.
2. 服务器向客户端发送一个POP质询，并使用提供的公共加密密钥进行加密。
3. Client decrypts the POP challenge using the private key that corresponds to the presented public key and sends the plaintext back to the server.
3. 客户端使用与提供的公钥对应的私钥解密POP质询，并将明文发送回服务器。
4. Server validates the decrypted POP challenge and continues processing the certification request.
4. 服务器验证解密的POP质询并继续处理认证请求。
CMC defines two different controls. 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 Encrypted POP control is used to send the encrypted challenge from the server to the client as part of the PKIResponse. (Note that it is assumed that the message sent in Step 1 above is a Full PKI Request and that the response in Step 2 is a Full PKI Response including a CMCFailInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP control.)
加密的POP控件用于将加密的质询作为PKI响应的一部分从服务器发送到客户端。（注意，假设在上面步骤1中发送的消息是完整的PKI请求，并且步骤2中的响应是完整的PKI响应，包括CMCFailInfo，指定明确需要POP，并在encryptedPOP控件中提供POP质询。）
The Encrypted POP control is identified by the OID:
加密的POP控件由OID标识：
id-cmc-encryptedPOP ::= { id-cmc 9 }
id-cmc-encryptedPOP ::= { id-cmc 9 }
The Encrypted POP control has the ASN.1 definition:
加密的POP控件具有ASN.1定义：
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
}
The Decrypted POP control is identified by the OID:
解密的POP控件由OID标识：
id-cmc-decryptedPOP ::= { id-cmc 10 }
id-cmc-decryptedPOP ::= { id-cmc 10 }
The Decrypted POP control has the ASN.1 definition:
解密的POP控件具有ASN.1定义：
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 randomly generates the POP Proof Value and associates it with the request.
1. 服务器随机生成POP-Proof值并将其与请求关联。
2. The server returns the Encrypted POP control with the following fields set:
2. 服务器返回设置了以下字段的加密POP控件：
request is the original certification request (it is included here so the client need not keep a copy of the request).
请求是原始的认证请求（包含在此处，因此客户无需保留请求的副本）。
cms is an EnvelopedData, the encapsulated content type being id-data and the content being the POP Proof Value; this value needs to be long enough that one cannot reverse the value from the witness hash. If the certification request contains a
cms是封装数据，封装的内容类型为id数据，内容为防弹出值；此值需要足够长，以便无法从见证散列中反转该值。如果认证请求包含
Subject Key Identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IssuerName MUST be encoded as NULL and the SerialNumber as the bodyPartID of the certification request.
Subject Key Identifier（SKI）扩展，则收件人标识符应为SKI。如果使用issuerAndSerialNumber表单，则必须将IssuerName编码为NULL，将SerialNumber编码为认证请求的bodyPartID。
thePOPAlgID identifies the algorithm to be used in computing the return POP value.
POPALGID标识用于计算返回POP值的算法。
witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.
witnessAlgID标识用于创建字段见证的POP-Proof值的哈希算法。
witness is the hashed value of the POP Proof Value.
witness是防弹出值的散列值。
3. The client decrypts the cms field to obtain the POP Proof Value. The client computes H(POP Proof Value) 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 containing a CMC Status Info control with CMCFailInfo value of popFailed.
3. 客户端解密cms字段以获得防弹出值。客户端使用witnessAlgID计算H（POP-Proof值），并与witness的值进行比较。如果值不进行比较或解密不成功，则客户端必须中止注册过程。客户端通过发送包含CMCFailInfo值为popFailed的CMC状态信息控件的请求中止该进程。
4. The client creates the Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:
4. 客户端创建解密的POP控件作为新PKI数据的一部分。DecryptedPOP中的字段为：
bodyPartID refers to the certification request in the new PKI Request.
bodyPartID是指新PKI请求中的证书请求。
thePOPAlgID is copied from the encryptedPOP.
POPALGID是从encryptedPOP复制的。
thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.
这本书包含了财产证明。该值由POPALGID使用POP证明值和请求计算得出。
5. The server then re-computes the value of thePOP from its cached value 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 the request altogether.
5. 然后，服务器根据缓存值和请求重新计算POP的值，并与POP的值进行比较。如果值不匹配，则服务器不得颁发证书。服务器可能会重新发出一个新的质询，或者请求可能会全部失败。
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. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.
定义POPALGID和WitnessalId的算法时，必须注意确保WitnessalId的结果不是使用POPALGID简化计算的有用值。在HMAC算法中，POP证明值用作秘密值，请求用作数据。如果防弹出值大于64字节，则仅将防弹出值的前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. The following 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.)
1. 服务器生成随机种子x，在所有请求中保持不变。（x的值通常会定期更改，并在之后保留一段短时间。）
2. For certification 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 certification request structure. y should not be predictable based on knowledge of R, thus the use of a one-way function like HMAC-SHA1.
2. 对于认证请求R，服务器计算y=F（x，R）。例如，F可以是HMAC-SHA1（x，R）。对于无状态而言，最重要的是，y可以仅使用已知的状态常数x和函数F，以及来自认证请求结构的其他输入来一致地计算。基于对R的了解，y不应是可预测的，因此使用了类似HMAC-SHA1的单向函数。
In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. In this case, the RA needs a way to inform the CA that it has done the POP. The RA POP Witness control addresses this issue.
在涉及RA的认证请求场景中，CA可能允许（或要求）RA与生成认证请求的实体执行POP协议。在这种情况下，RA需要一种方法来通知CA它已经完成了POP。RA POP见证控制解决了这个问题。
The RA POP Witness control is identified by the OID:
RA POP见证控制由OID标识：
id-cmc-lraPOPWitness ::= { id-cmc 11 }
id-cmc-lraPOPWitness ::= { id-cmc 11 }
The RA POP Witness control has the ASN.1 definition:
RA POP见证控件具有ASN.1定义：
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
The fields in LraPOPWitness have the following meaning:
LRA中的字段具有以下含义：
pkiDataBodyid contains the body part identifier of the nested TaggedContentInfo containing the client's Full PKI Request. pkiDataBodyid is set to 0 if the request is in the current PKIData.
pkiDataBodyid包含嵌套标记的主体部分标识符，该标记包含客户端的完整PKI请求。如果请求位于当前PKIData中，则pkiDataBodyid设置为0。
bodyIds is a list of certification requests for which the RA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response, or other means.
BodyID是RA已执行带外身份验证的认证请求列表。认证方法可以是私钥材料的存档、质询响应或其他方式。
If a certification server does not allow an RA to do the POP verification, it returns a CMCFailInfo with the value of popFailed. The CA MUST NOT start a challenge-response to re-verify the POP itself.
如果认证服务器不允许RA执行POP验证，则它将返回一个值为popFailed的CMCFailInfo。CA不得启动质询响应来重新验证POP本身。
Everything described in this section is optional to implement.
本节中描述的所有内容都是可选的。
The Get Certificate control is used to retrieve a previously issued certificate from a certificate repository. A CA, an RA, 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 Certificate控件用于从证书存储库检索以前颁发的证书。CA、RA或独立服务可以提供此存储库。预期使用此功能的客户机是那些完全部署的目录不可行或不受欢迎的客户机。
The Get Certificate control is identified by the OID:
获取证书控件由OID标识：
id-cmc-getCert ::= { id-cmc 15 }
id-cmc-getCert ::= { id-cmc 15 }
The Get Certificate control has the ASN.1 definition:
Get Certificate控件具有ASN.1定义：
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The fields in GetCert have the following meaning:
GetCert中的字段具有以下含义：
issuerName is the name of the certificate issuer.
issuerName是证书颁发者的名称。
serialNumber identifies the certificate to be retrieved.
serialNumber标识要检索的证书。
The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
响应此请求的服务器将请求的证书放置在SignedData的证书字段中。如果Get Certificate控件是完整PKI请求中的唯一控件，则响应应该是简单的PKI响应。
Everything described in this section is optional to implement.
本节中描述的所有内容都是可选的。
The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, 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控件用于从CRL存储库中检索CRL。CA、RA或独立服务可以提供此存储库。预期使用此功能的客户机是那些完全部署的目录不可行或不受欢迎的客户机。
The Get CRL control is identified by the OID:
Get CRL控件由OID标识：
id-cmc-getCRL ::= { id-cmc 16 }
id-cmc-getCRL ::= { id-cmc 16 }
The Get CRL control has the ASN.1 definition:
Get CRL控件具有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 server responding to this request places the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response.
响应此请求的服务器将请求的CRL放置在SignedData的crls字段中。如果Get CRL控件是完整PKI请求中的唯一控件，则响应应该是简单的PKI响应。
The Revocation Request control is used to request that a certificate be revoked.
吊销请求控件用于请求吊销证书。
The Revocation Request control is identified by the OID:
撤销请求控制由OID标识：
id-cmc-revokeRequest ::= { id-cmc 17 }
id-cmc-revokeRequest ::= { id-cmc 17 }
The Revocation Request control has the ASN.1 definition:
吊销请求控件具有ASN.1定义：
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
The fields of RevokeRequest have the following meaning:
RevokeRequest字段具有以下含义：
issuerName is the issuerName of the certificate to be revoked.
issuerName是要撤销的证书的颁发者名称。
serialNumber is the serial number of the certificate to be revoked.
serialNumber是要吊销的证书的序列号。
reason is 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 is 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 is 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 is a human-readable comment.
注释是人类可读的注释。
For a revocation request to be reliable in the event of a dispute, a strong proof-of-origin is required. However, in the instance when an EE has lost use of its signature private key, it is impossible for the EE to produce a digital signature (prior to the certification of a new signature key pair). The Revoke Request control allows the EE to send the CA a shared-secret that may be used as an alternative authenticator in the instance of loss of use of the EE's signature private key. The acceptability of this practice is a matter of local security policy.
为了使撤销请求在发生争议时可靠，需要提供强有力的原产地证明。然而，在EE丢失其签名私钥的情况下，EE不可能产生数字签名（在新签名密钥对的认证之前）。撤销请求控制允许EE向CA发送共享密钥，该共享密钥可在EE的签名私钥丢失的情况下用作替代认证器。这种做法的可接受性取决于当地的安全政策。
It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.
在某些情况下，可以使用不同的证书对丢失的证书的吊销进行签名。如果名称信息匹配，客户端可以使用签名证书对加密密钥的吊销进行签名。类似地，可以为管理员或RA分配撤销第三方证书的能力。在这些情况下，服务器是否接受撤销取决于本地策略。
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared-secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self-revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests.
客户端必须提供生成数字签名撤销请求控制的功能。客户端应该能够生成包含EE共享机密的未签名撤销请求控件（未签名消息由无签名的SignedData组成）。如果客户端提供基于共享秘密的自撤销，则客户端必须能够生成包含共享秘密的撤销请求控件。服务器必须能够接受两种形式的撤销请求。
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 control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), 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 PKI Response MUST be returned for a revocation request.
必须为吊销请求返回完整的PKI响应。
The Registration Information control allows for clients to pass additional information as part of a Full PKI Request.
注册信息控件允许客户端作为完整PKI请求的一部分传递附加信息。
The Registration Information control is identified by the OID:
注册信息控件由OID标识：
id-cmc-regInfo ::= { id-cmc 18 }
id-cmc-regInfo ::= { id-cmc 18 }
The Registration Information control has the ASN.1 definition:
注册信息控件具有ASN.1定义：
RegInfo ::= OCTET STRING
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
此数据的内容基于客户端和服务器之间的双边协议。
The Response Information control allows a server to return additional information as part of a Full PKI Response.
响应信息控件允许服务器返回附加信息，作为完整PKI响应的一部分。
The Response Information control is identified by the OID:
响应信息控制由OID标识：
id-cmc-responseInfo ::= { id-cmc 19 }
id-cmc-responseInfo ::= { id-cmc 19 }
The Response Information control has the ASN.1 definition:
响应信息控件具有ASN.1定义：
ResponseInfo ::= OCTET STRING
ResponseInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.
此数据的内容基于客户端和服务器之间的双边协议。
In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request.
在某些环境中，手动干预或其他身份检查的流程要求可能会延迟证书的返回。查询挂起控件允许客户端向服务器查询挂起的证书请求的状态。服务器返回pendToken作为扩展CMC状态信息和CMC状态信息控件（在otherInfo字段中）的一部分。客户机将pendToken复制到查询挂起控件中，以向服务器标识正确的证书请求。服务器返回客户端查询挂起的证书请求状态的建议时间。
The Query Pending control is identified by the OID:
查询挂起控件由OID标识：
id-cmc-queryPending ::= { id-cmc 21 }
id-cmc-queryPending ::= { id-cmc 21 }
The Query Pending control has the ASN.1 definition:
查询挂起控件具有ASN.1定义：
QueryPending ::= OCTET STRING
QueryPending ::= OCTET STRING
If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of 'pendInfo' MUST be the same as the original pendInfo value.
如果服务器返回挂起或部分CMCStatusInfo（事务仍处于挂起状态），则可以忽略otherInfo。如果未省略otherInfo，“pendInfo”的值必须与原始pendInfo值相同。
Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.
一些CA要求客户对颁发给EE的证书是否可接受给予肯定的确认。确认证书验收控制用于此目的。如果PKI响应上的CMC状态信息为confirmRequired，则客户端必须返回完整PKI请求中包含的确认证书接受控制。
Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.
客户端在将证书用于任何目的之前，应等待服务器发出的确认已收到的PKI响应。
The Confirm Certificate Acceptance control is identified by the OID:
确认证书验收控制由OID确定：
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
The Confirm Certificate Acceptance control has the ASN.1 definition:
确认证书验收控制具有ASN.1的定义：
CMCCertId ::= IssuerAndSerialNumber
CMCCertId ::= IssuerAndSerialNumber
CMCCertId contains the issuer and serial number of the certificate being accepted.
CMCCertId包含正在接受的证书的颁发者和序列号。
Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.
服务器必须为确认证书接受控制返回完整的PKI响应。
Note that if the CA includes this control, there will be two full round-trips of messages.
请注意，如果CA包含此控件，则将有两个完整的消息往返。
1. The client sends the certification request to the CA.
1. 客户端向CA发送认证请求。
2. The CA returns a Full PKI Response with the certificate and this control.
2. CA返回带有证书和此控件的完整PKI响应。
3. The client sends a Full PKI Request to the CA with an Extended CMC Status Info control accepting and a Confirm Certificate Acceptance control or an Extended CMC Status Info control rejecting the certificate.
3. 客户端使用扩展CMC状态信息控件接受和确认证书接受控件或扩展CMC状态信息控件拒绝证书，向CA发送完整PKI请求。
4. The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.
4. CA向客户端发送完整的PKI响应，扩展CMC状态信息为success。
The Publish Trust Anchors control allows for the distribution of set trust anchors from a central authority to an EE. The same control is also used to update the set of trust anchors. Trust anchors are distributed in the form of certificates. These are expected, but not required, to be self-signed certificates. Information is extracted from these certificates to set the inputs to the certificates validation algorithm in Section 6.1.1 of [PKIXCERT].
Publish Trust Anchors控件允许将集合信任锚从中央机构分发到EE。同样的控件也用于更新信任锚点集。信任锚以证书的形式分发。这些证书应为自签名证书，但不是必需的。从这些证书中提取信息，以设置[PKIXCERT]第6.1.1节中证书验证算法的输入。
The Publish Trust Anchors control is identified by the OID:
发布信任锚控件由OID标识：
id-cmc-trustedAnchors ::= { id-cmc 26 }
id-cmc-trustedAnchors ::= { id-cmc 26 }
The Publish Trust Anchors control has the ASN.1 definition:
发布信任锚控件具有ASN.1定义：
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
The fields in PublishTrustAnchors have the following meaning:
PublishTrustAnchors中的字段具有以下含义：
seqNumber is an integer indicating the location within a sequence of updates.
seqNumber是一个整数，指示更新序列中的位置。
hashAlgorithm is the identifier and parameters for the hash algorithm that is used in computing the values of the anchorHashes field. All implementations MUST implement SHA-1 for this field.
hashAlgorithm是用于计算AnchorHash字段值的哈希算法的标识符和参数。对于该字段，所有实现都必须实现SHA-1。
anchorHashes are the hashes for the certificates that are to be treated as trust anchors by the client. The actual certificates are transported in the certificate bag of the containing SignedData structure.
AnchorHash是客户端将其视为信任锚的证书的哈希。实际证书在包含SignedData结构的证书包中传输。
While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.
虽然建议发送方在PKI响应中放置要信任的证书，但这不是必需的，因为应该可以使用正常的发现技术获取证书。
Prior to accepting the trust anchors changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to ensure that the signer is permitted to use the control, validate that the authenticated publish time in the signature is near to the current time, and validate that the sequence number is greater than the previously used one.
在接受信任锚更改之前，客户端必须至少执行以下操作：验证对当前受信任锚的PKI响应上的签名，使用策略检查以确保允许签名者使用控件，验证签名中经过身份验证的发布时间是否接近当前时间，并验证序列号是否大于先前使用的序列号。
In the event that multiple agents publish a set of trust anchors, it is up to local policy to determine how the different trust anchors should be combined. Clients SHOULD be able to handle the update of multiple trust anchors independently.
如果多个代理发布一组信任锚，则由本地策略决定如何组合不同的信任锚。客户端应该能够独立地处理多个信任锚的更新。
Note: Clients that handle this control must use extreme care in validating that the operation is permissible. Incorrect handling of this control allows for an attacker to change the set of trust anchors on the client.
注意：处理此控件的客户端必须非常小心地验证操作是否允许。对该控件的不正确处理允许攻击者更改客户端上的信任锚集。
The Authenticated Data control allows a server to provide data back to the client in an authenticated manner. This control uses the Authenticated Data structure to allow for validation of the data. This control is used where the client has a shared-secret and a secret identifier with the server, but where a trust anchor has not yet been downloaded onto the client so that a signing certificate for the server cannot be validated. The specific case that this control was created for use with is the Publish Trust Anchors control (Section 6.15), but it may be used in other cases as well.
身份验证数据控件允许服务器以身份验证的方式向客户端提供数据。此控件使用经过身份验证的数据结构来允许对数据进行验证。此控件用于客户端与服务器共享机密和机密标识符，但尚未将信任锚点下载到客户端，因此无法验证服务器的签名证书的情况。创建此控件用于发布信任锚控件的特定情况（第6.15节），但也可以用于其他情况。
The Authenticated Data control is identified by the OID:
已验证的数据控件由OID标识：
id-cmc-authData ::= { id-cmc 27 }
id-cmc-authData ::= { id-cmc 27 }
The Authenticated Data control has the ASN.1 definition:
已验证的数据控件具有ASN.1定义：
AuthPublish ::= BodyPartID
AuthPublish ::= BodyPartID
AuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData. The encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds. (One example is the Publish Trust Anchors control in Section 6.15.)
AuthPublish是一个主体部分标识符，它引用当前PKI响应或PKI数据的cmsSequence元素的成员。cmsSequence元素是AuthenticatedData。封装的内容是一个id cct PKI数据。如果身份验证成功，则需要处理controlSequence中的控件。（第6.15节中的发布信任锚控件就是一个示例。）
If the authentication operation fails, the CMCFailInfo authDataFail is returned.
如果身份验证操作失败，则返回CMCFailInfo authDataFail。
These controls allow for an RA to collect multiple requests together into a single Full PKI Request and forward it to a CA. The server would then process the requests and return the results in a Full PKI Response.
这些控件允许RA将多个请求收集到一个完整的PKI请求中，并将其转发给CA。然后，服务器将处理这些请求并在完整的PKI响应中返回结果。
The Batch Request control is identified by the OID:
批次请求控制由OID标识：
id-cmc-batchRequests ::= {id-cmc 28}
id-cmc-batchRequests ::= {id-cmc 28}
The Batch Response control is identified by the OID:
批次响应控制由OID标识：
id-cmc-batchResponses ::= {id-cmc 29}
id-cmc-batchResponses ::= {id-cmc 29}
Both the Batch Request and Batch Response controls have the ASN.1 definition:
批处理请求和批处理响应控件都具有ASN.1定义：
BodyPartList ::= SEQUENCE of BodyPartID
BodyPartList ::= SEQUENCE of BodyPartID
The data associated with these controls is a set of body part identifiers. Each request/response is placed as an individual entry in the cmcSequence of the new PKIData/PKIResponse. The body part identifiers of these entries are then placed in the body part list associated with the control.
与这些控件关联的数据是一组身体部位标识符。每个请求/响应都作为单个条目放置在新PKIData/PKIResponse的CMC序列中。然后，将这些条目的主体部件标识符放置在与控件关联的主体部件列表中。
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Requests control was processed; the responses
当服务器处理批处理请求控制时，它可能会在一个或多个PKI响应中返回响应。在除最后一个PKI响应之外的所有PKI响应上都返回一个CMCStatus值partial。如果批处理请求控件已处理，则CMCStatus将成功；回应
are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.
使用自己的CMCStatus代码创建。单个请求上的错误不会传播到顶层。
When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.
当返回CMCStatus值为partial的PKI响应时，将使用查询挂起控制（第6.13节）检索其他结果。返回的状态包括一个建议的时间，在该时间之后，客户机应请求其他结果。
The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued.
发布信息控件允许修改已发布证书的发布，包括发布和从发布中删除。此控件的常见用法是在重新设置密钥操作期间从发布中删除现有证书。应始终在颁发新证书和撤销请求后处理此控制。如果证书颁发失败，则不应处理此控件。
The Publication Information control is identified by the OID:
发布信息控件由OID标识：
id-cmc-publishCert ::= { id-cmc 30 }
id-cmc-publishCert ::= { id-cmc 30 }
The Publication Information control has the ASN.1 definition:
发布信息控件具有ASN.1定义：
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}
The fields in CMCPublicationInfo have the following meaning:
CMCPublicationInfo中的字段具有以下含义：
hashAlg is the algorithm identifier of the hash algorithm used to compute the values in certHashes.
hashAlg是用于计算证书哈希值的哈希算法的算法标识符。
certHashes are the hashes of the certificates for which publication is to change.
CertHash是要更改其发布的证书的哈希。
pubInfo is the information where and how the certificates should be published. The fields in pubInfo (taken from [CRMF]) have the following meanings:
pubInfo是应该在何处以及如何发布证书的信息。pubInfo中的字段（取自[CRMF]）具有以下含义：
action indicates the action the service should take. It has two values:
action表示服务应采取的操作。它有两个值：
dontPublish indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate him/herself). dontPublish has the added connotation of removing from publication the certificate if it is already published.
dontPublish表示PKI不应发布证书（这可能表示请求者打算自己发布证书）。dontPublish增加了从发布中删除已发布证书的含义。
pleasePublish indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the CMC Publication Info control results in the same behavior.
pleasePublish表示PKI可以使用其选择的任何方式发布证书，除非存在pubInfos。省略CMC发布信息控件会导致相同的行为。
pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the PKI SHOULD publish the certificate.
pubInfos pubInfos表示PKI应如何发布证书（例如X500、Web、IP地址）。
A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.
单个证书不应出现在多个发布信息控件中。该行为在其发生的事件中未定义。
The Control Processed control allows an RA to indicate to subsequent control processors that a specific control has already been processed. This permits an RA in the middle of a processing stream to process a control defined either in a local context or in a subsequent document.
控制已处理控制允许RA向后续控制处理器指示特定控制已处理。这允许处理流中间的RA处理在本地上下文或后续文档中定义的控制。
The Control Processed control is identified by the OID:
已处理的控制由OID标识：
id-cmc-controlProcessed ::= { id-cmc 32 }
id-cmc-controlProcessed ::= { id-cmc 32 }
The Control Processed control has the ASN.1 definition:
已处理控件具有ASN.1定义：
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
bodyList is a series of body part identifiers that form a path to each of the controls that were processed by the RA. This control is only needed for those controls that are not part of this standard and thus would cause an error condition of a server attempting to deal with a control not defined in this document. No error status is needed since an error causes the RA to return the request to the client with the error rather than passing the request on to the next server in the processing list.
bodyList是一系列身体部位标识符，构成RA处理的每个控件的路径。此控件仅适用于不属于本标准一部分的控件，因此会导致服务器尝试处理本文档中未定义的控件时出现错误情况。不需要错误状态，因为错误会导致RA将请求返回到带有错误的客户端，而不是将请求传递到处理列表中的下一个服务器。
This specification permits the use of RAs. An RA sits between the EE and the CA. From the EE's perspective, the RA appears to be the CA, and from the server, the RA appears to be a client. RAs receive the PKI Requests, perform local processing and then forward them onto CAs. Some of the types of local processing that an RA can perform include:
本规范允许使用RAs。RA位于EE和CA之间。从EE的角度看，RA似乎是CA，从服务器上看，RA似乎是客户端。RAs接收PKI请求，执行本地处理，然后将它们转发到CAs。RA可以执行的一些本地处理类型包括：
o Batching multiple PKI Requests together,
o 将多个PKI请求批处理在一起，
o Performing challenge/response POP proofs,
o 执行挑战/响应流行样稿，
o Adding private or standardized certificate extensions to all certification requests,
o 将专用或标准化证书扩展添加到所有证书请求中，
o Archiving private key material,
o 存档私钥材料，
o Routing requests to different CAs.
o 将请求路由到不同的CA。
When an RA receives a PKI Request, it has three options: it may forward the PKI Request without modification, it may add a new wrapping layer to the PKI Request, or it may remove one or more existing layers and add a new wrapping layer.
当RA收到PKI请求时，它有三个选项：它可以转发PKI请求而不进行修改，它可以向PKI请求添加新的包装层，或者它可以删除一个或多个现有层并添加新的包装层。
When an RA adds a new wrapping layer to a PKI Request, it creates a new PKIData. The new layer contains any controls required (for example, if the RA does the POP proof for an encryption key or the Add Extension control to modify a PKI Request) and the client PKI Request. The client PKI Request is placed in the cmsSequence if it is a Full PKI Request and in the reqSequence if it is a Simple PKI Request. If an RA is batching multiple client PKI Requests together,
当RA向PKI请求添加新的包装层时，它将创建新的PKI数据。新层包含所需的任何控件（例如，如果RA对加密密钥进行POP验证或添加扩展控件以修改PKI请求），以及客户端PKI请求。如果客户端PKI请求是完整PKI请求，则将其置于CMS序列中；如果客户端PKI请求是简单PKI请求，则将其置于REQ序列中。如果RA将多个客户端PKI请求批处理在一起，
then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls.
然后将每个客户端PKI请求与所有相关控件一起放入RA的PKIData对象中的适当位置。
If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request.
如果在EE和CA之间的路径中有多个RA，这将导致请求上有多个包装层。
In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF) as any alteration would invalidate the signature on the certification request and thus the POP for the private key.
在处理PKI请求时，RA不得更改任何认证请求（PKCS#10或CRMF），因为任何更改都会使认证请求上的签名无效，从而使私钥的POP无效。
An example of how this would look is illustrated by the following figure:
下图举例说明了这种情况：
SignedData (by RA) PKIData controlSequence RA added control statements reqSequence Zero or more Simple PKI Requests from clients cmsSequence Zero or more Full PKI Requests from clients SignedData (signed by client) PKIData
SignedData（按RA）PKI数据控制序列RA添加的控制语句reqSequence零或更多来自客户端的简单PKI请求CMS序列零或更多来自客户端的完整PKI请求SignedData（按客户端签名）PKI数据
Under some circumstances, an RA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
在某些情况下，需要RA来移除包装层。以下各节将介绍需要删除加密层和签名层时所需的处理。
There are two cases that require an RA to remove or change encryption in a PKI Request. In the first case, the encryption was applied for the purposes of protecting the entire PKI Request from unauthorized entities. If the CA does not have a Recipient Info entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer with or without adding a new signing layer.
有两种情况需要RA删除或更改PKI请求中的加密。在第一种情况下，应用加密是为了保护整个PKI请求不受未经授权实体的攻击。如果CA在加密层中没有收件人信息条目，RA必须删除加密层。RA可以添加新的加密层，也可以不添加新的签名层。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.
可能需要的第二个加密更改是更改签名层内部的加密。在这种情况下，RA必须删除包含加密的所有签名层。在删除每个签名层时，必须根据本地策略规则合并所有控制语句，并且所产生的合并控制必须放置在RA提供的新签名层中。如果EE提供的签名层也需要删除，RA也可以删除该层。
Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request, or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request.
只有两种情况下RA应该删除完整PKI请求上的签名层：如果需要在请求中修改加密层，或者CA不接受二次委托（即多个RA签名）。在所有其他情况下，RAs不应从PKI请求中删除签名层。
If an RA removes a signing layer from a PKI Request, 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 RA.
如果RA从PKI请求中删除签名层，则必须根据本地策略规则合并所有控制语句。生成的合并控制语句必须放置在RA提供的新签名层中。
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 controls described in Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls.
在本协议的特定实现中，可能需要阻止重播攻击的机制，具体取决于操作环境。在CA保持重要状态信息的情况下，重放攻击可以在不包含可选的nonce机制的情况下被检测。该协议的实现者需要仔细考虑环境条件，然后选择是否实现在第6.6节中描述的SENDENNORCE和RelabunNoCube控件。强烈鼓励受国家约束的PKI客户端的开发人员使用这些控件。
Extreme care needs to be taken when archiving a signing key. The holder of the archived key may have the ability to use the key to generate forged signatures. There are however reasons why a signing key should be archived. An archived CA signing key can be recovered in the event of failure to continue to produced CRLs following a disaster.
存档签名密钥时需要格外小心。存档密钥的持有者可以使用密钥生成伪造签名。但是，有一些原因说明为什么应该归档签名密钥。如果灾难发生后无法继续生成CRL，则可以恢复已存档的CA签名密钥。
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]. Methods of avoiding the small subgroup attack can be found in [SMALL-GROUP]. CMC implementations ought to be aware of this attack when doing parameter validations.
在颁发证书之前，客户端和服务器需要对加密参数进行一些检查，以确保不使用弱参数。[X942]中提供了小子组攻击的描述。可在[small-GROUP]中找到避免小子组攻击的方法。CMC实现在执行参数验证时应注意此攻击。
When using a shared-secret for authentication purposes, the shared-secret should be generated using good random number techniques [RANDOM]. User selection of the secret allows for dictionary attacks to be mounted.
当使用共享秘密进行身份验证时，应使用良好的随机数技术[random]生成共享秘密。用户选择机密允许装载字典攻击。
Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to the practice of slamming where an attacker changes the set of trusted anchors in order to weaken security.
在处理发布信任锚控件时必须格外小心。不正确的处理可能导致攻击者更改可信锚集以削弱安全性的攻击行为。
One method of controlling the use of the Publish Trust Anchors control is as follows. The client needs to associate with each trust anchor accepted by the client the source of the trust anchor. Additionally, the client should associate with each trust anchor the types of messages for which the trust anchor is valid (i.e., is the trust anchor used for validating S/MIME messages, TLS, or CMC enrollment messages?).
控制发布信任锚控件的使用的一种方法如下。客户机需要与客户机接受的每个信任锚关联信任锚的来源。此外，客户端应将信任锚有效的消息类型与每个信任锚关联（即，信任锚是否用于验证S/MIME消息、TLS或CMC注册消息？）。
When a new message is received with a Publish Trust Anchors control, the client would accept the set of new trust anchors for specific applications only if the signature validates, the signer of the message has the required policy approval for updating the trust anchors, and local policy also would allow updating the trust anchors.
当使用发布信任锚控件接收到新消息时，仅当签名验证时，客户端才会接受特定应用程序的新信任锚集，消息的签名者具有更新信任锚所需的策略批准，并且本地策略也允许更新信任锚。
The CMS AuthenticatedData structure provides message integrity, it does not provide message authentication in all cases. When using MACs in this document the following restrictions need to be observed. All messages should be for a single entity. If two entities are placed in a single message, the entities can generate new messages that have a valid MAC and might be assumed to be from the original message sender. All entities that have access to the shared-secret can generate messages that will have a successful MAC validation. This means that care must be taken to keep this value secret. Whenever possible, the SignedData structure should be used in preference to the AuthenticatedData structure.
CMS AuthenticatedData结构提供消息完整性，但并非在所有情况下都提供消息身份验证。在本文档中使用MAC时，需要遵守以下限制。所有消息都应针对单个实体。如果在一条消息中放置两个实体，则这些实体可以生成具有有效MAC的新消息，并且可以假定这些消息来自原始消息发送者。所有有权访问共享机密的实体都可以生成具有成功MAC验证的消息。这意味着必须注意对该值保密。只要可能，应优先使用SignedData结构而不是AuthenticatedData结构。
This document defines a number of control objects. These are identified by Object Identifiers (OIDs). The objects are defined from an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.
本文档定义了许多控制对象。这些由对象标识符（OID）标识。对象由IANA委托给PKIX工作组的arc定义。IANA无需对本文件或任何预期更新采取进一步行动。
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.
作者和PKIX工作组感谢刘晓义和杰夫·温斯坦参与编写本文件的原始版本。
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 (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CRMF] Schaad, J., "Internet X.509 Certification Request Message Format", RFC 4211, January 2005.
[CRMF]Schaad，J.，“互联网X.509认证请求消息格式”，RFC 4211，2005年1月。
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000.
[DH-POP]Prafullchandra，H.和J.Schaad，“Diffie-Hellman占有算法证明”，RFC 28752000年6月。
[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月。
Note that this version of PKCS #10 is used for compatibility with the use of 1988 ASN.1 syntax. An effort is currently underway in the PKIX working group to update to use 2003 ASN.1 syntax.
请注意，此版本的PKCS#10用于与1988 ASN.1语法的使用兼容。PKIX工作组目前正在努力更新以使用2003 ASN.1语法。
[PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIXCERT]Housley，R.，Ford，W.，Polk，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[CMC-TRANS]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）：传输协议”，RFC 5273，2008年6月。
[CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[CMC-COMPL]Schaad，J.和M.Myers，“CMS上的证书管理消息（CMC）：合规性要求”，RFC 5274，2008年6月。
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST SP 800-63, April 2006.
[密码]Burr，W.，Dodson，D.和W.Polk，“电子认证指南”，NIST SP 800-63，2006年4月。
[RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[SMALL-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[SMALL-GROUP]Zuccherato，R.，“避免针对S/MIME Diffie-Hellman密钥协商方法的“小子组”攻击的方法”，RFC 27852000年3月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[X942]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[RFC2797]Myers，M.，Liu，X.，Schaad，J.，和J.Weinstein，“CMS上的证书管理消息”，RFC 2797，2000年4月。
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
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
进口
-- PKIX Part 1 - Implicit From [PKIXCERT]
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(19)}
-- PKIX Part 1 - Implicit From [PKIXCERT]
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(19)}
-- PKIX Part 1 - Explicit From [PKIXCERT]
AlgorithmIdentifier, Extension, Name, CertificateSerialNumber
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
-- PKIX Part 1 - Explicit From [PKIXCERT]
AlgorithmIdentifier, Extension, Name, CertificateSerialNumber
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
-- Cryptographic Message Syntax FROM [CMS]
ContentInfo, Attribute, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- Cryptographic Message Syntax FROM [CMS]
ContentInfo, Attribute, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}
-- CRMF FROM [CRMF]
CertReqMsg, PKIPublicationInfo, CertTemplate
FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005(36)};
-- CRMF FROM [CRMF]
CertReqMsg, PKIPublicationInfo, CertTemplate
FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005(36)};
-- Global Types
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
-- Global Types
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
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 the type OCTET STRING
--以下控件的类型为八位字节字符串
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
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-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
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}
-- The following controls have the type UTF8String
--以下控件的类型为UTF8String
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
-- The following controls have the type INTEGER
--以下控件的类型为INTEGER
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
-- The following controls have the type OCTET STRING
--以下控件的类型为八位字节字符串
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
-- 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,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
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 ::= PKIResponse
ResponseBody ::= PKIResponse
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
PKIResponse ::= 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-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 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 ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
CMCStatus ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
-- Note:
-- The spelling of unsupportedExt is corrected in this version.
-- In RFC 2797, it was unsuportedExt.
-- Note:
-- The spelling of unsupportedExt is corrected in this version.
-- In RFC 2797, it was unsuportedExt.
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
-- Used for RAs to add extensions to certification requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
-- Used for RAs to add extensions to certification 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 {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
CMCCertId ::= IssuerAndSerialNumber
CMCCertId ::= IssuerAndSerialNumber
-- The following is used to request V3 extensions be added to a
-- certificate
-- The following is used to request V3 extensions be added to a
-- certificate
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 SIZE (1..MAX) OF Extension
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
-- The following exists to allow Diffie-Hellman Certification Requests
-- Messages to be well-formed
-- The following exists to allow Diffie-Hellman Certification 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
-- Unauthenticated attribute to carry removable data.
-- This could be used in an update of "CMC Extensions: Server Side
-- Key Generation and Key Escrow" (February 2005) and in other
-- documents.
-- Unauthenticated attribute to carry removable data.
-- This could be used in an update of "CMC Extensions: Server Side
-- Key Generation and Key Escrow" (February 2005) and in other
-- documents.
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
-- Replaces CMC Status Info --
--替换CMC状态信息--
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
-- Allow for distribution of trust anchors --
--允许分发信任锚--
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
AuthPublish ::= BodyPartID
AuthPublish ::= BodyPartID
-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
--
id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
--
id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
-- Inform follow on servers that one or more controls have already been
-- processed
-- Inform follow on servers that one or more controls have already been
-- processed
id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
}
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
}
-- Identity Proof control w/ algorithm agility
--具有算法敏捷性的身份证明控制
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}
IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
END
终止
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.
本节仅供参考。本节的目的是以抽象版本的形式展示在几种不同的常见情况下在客户机和服务器之间流动的消息。
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.
本节将研究在仅签名密钥发生注册时将传递的消息。如果证书设计用于签名和加密，那么唯一的区别就是证书请求中的密钥使用扩展。
Message #2 from client to server:
从客户端到服务器的消息#2：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Response from server to client:
从服务器到客户端的响应：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.
本节着眼于在数据流中间注册具有一个RA的事件中所流的消息。RA将在将认证请求传递给CA之前对其进行修改。
Message from client to RA:
从客户端到RA的消息：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Message from RA to CA:
从RA到CA的消息：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
Response from CA to RA:
CA对RA的回应：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIResponse eContent controlSequence {102, id-cmc-BatchResponse, {999, 998}}
ContentInfo.contentType=id signedData ContentInfo.content signedData.encapContentInfo eContentType=id ct PKIResponse eContent controlSequence{102，id cmc BatchResponse，{999，998}
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
Response from RA to client:
RA对客户的回复：
ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIResponse eContent controlSequence {102, id-cmc-statusInfoV2, {success, 201}} certificates Newly issued certificate Other certificates SignedData.SignerInfos Signed by CA
ContentInfo.contentType=id signedData ContentInfo.content signedData.encapContentInfo eContentType=id ct PKI响应eContent控制序列{102，id-cmc-statusInfoV2，{success，201}}证书新颁发的证书其他证书由CA签署的证书signedData.SignerInfos
This section looks at the messages that would flow in the event that an enrollment is done for an encryption only certificate using an direct POP method. For simplicity, it is assumed that the certification requester already has a signing-only certificate.
本节将介绍在使用直接POP方法注册仅加密证书时将出现的消息。为简单起见，假定证书请求者已经有一个仅签名的证书。
The fact that a second round-trip is required is implicit rather than explicit. The server determines this based on the fact that no other POP exists for the certification request.
需要第二次往返的事实是隐含的，而不是明确的。服务器根据证书请求不存在其他POP的事实来确定这一点。
Message #1 from client to server:
从客户端到服务器的消息#1：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #1 from server to client:
从服务器到客户端的响应#1：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Other certificates (optional)
SignedData.SignerInfos
Signed by CA
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Other certificates (optional)
SignedData.SignerInfos
Signed by CA
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos SignerInfo Signed by requester's signing cert
SignedData.SignerInfos SignerInfos由请求者的签名证书签名的签名信息
Response #2 from server to client:
从服务器到客户端的响应#2：
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
Appendix C. Production of Diffie-Hellman Public Key Certification Requests
附录C.Diffie-Hellman公钥认证请求的生成
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 6.7 MUST be used.
id alg NOSIGNATION的参数必须存在，并且必须编码为NULL。NoSignatureValue包含证书请求的哈希。重要的是要认识到，没有与此签名类型相关联的安全性。如果此签名类型在认证请求中，且认证机构策略要求提供私钥拥有证明，则必须使用第6.7节中定义的POP机制。
Authors' Addresses
作者地址
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Smalling Hawk咨询公司华盛顿金条675号邮政信箱98251
Phone: (425) 785-1031 EMail: jimsch@nwlink.com
电话：（425）785-1031电子邮件：jimsch@nwlink.com
Michael Myers TraceRoute Security, Inc.
迈克尔·迈尔斯追踪路线安全公司。
EMail: mmyers@fastq.com
EMail: mmyers@fastq.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.