Network Working Group J. Schaad
Request for Comments: 5274 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Network Working Group J. Schaad
Request for Comments: 5274 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Certificate Management Messages over CMS (CMC): Compliance Requirements
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 provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC.
本文档提供了一组关于CMC（CMS证书管理）注册协议的合规性声明。其他文档介绍了CMC注册协议的ASN.1结构和传输机制。本文档提供了制作CMC兼容版本所需的信息。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
4. Requirements for All Entities . . . . . . . . . . . . . . . . 3
4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 4
4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 8
4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 8
5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 8
6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
4. Requirements for All Entities . . . . . . . . . . . . . . . . 3
4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 4
4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 8
4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 8
5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 8
6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
The CMC (Certificate Management over CMS) protocol is designed in terms of a client/server relationship. In the simplest case, the client is the requestor of the certificate (i.e., the End Entity (EE)) and the server is the issuer of the certificate (i.e., the Certification Authority (CA)). The introduction of a Registration Authority (RA) into the set of agents complicates the picture only slightly. The RA becomes the server with respect to the certificate requestor, and it becomes the client with respect to the certificate issuer. Any number of RAs can be inserted into the picture in this manner.
CMC（CMS证书管理）协议是根据客户机/服务器关系设计的。在最简单的情况下，客户端是证书的请求者（即，终端实体（EE）），服务器是证书的颁发者（即，证书颁发机构（CA））。在代理集合中引入注册机构（RA）只会使情况稍微复杂化。RA成为证书请求者的服务器，成为证书颁发者的客户端。可以以这种方式将任意数量的RAs插入图片中。
The RAs may serve specialized purposes that are not currently covered by this document. One such purpose would be a Key Escrow agent. As such, all certificate requests for encryption keys would be directed through this RA and it would take appropriate action to do the key archival. Key recovery requests could be defined in the CMC methodology allowing for the Key Escrow agent to perform that operation acting as the final server in the chain of agents.
RAs可用于本文件目前未涵盖的特殊用途。其中一个目的是成为关键的托管代理。因此，加密密钥的所有证书请求都将通过此RA进行定向，并且它将采取适当的操作来进行密钥存档。密钥恢复请求可以在CMC方法中定义，允许密钥托管代理作为代理链中的最终服务器执行该操作。
If there are multiple RAs in the system, it is considered normal that not all RAs will see all certificate requests. The routing between the RAs may be dependent on the content of the certificate requests involved.
如果系统中有多个RAs，则认为并非所有RAs都能看到所有证书请求是正常的。RAs之间的路由可能取决于所涉及的证书请求的内容。
This document is divided into six sections, each section specifying the requirements that are specific to a class of agents in the CMC model. These are 1) All agents, 2) all servers, 3) all clients, 4) all End-Entities, 5) all Registration Entities, 6) all Certificate Authorities.
本文档分为六个部分，每个部分指定CMC模型中某类代理的特定要求。这些是1）所有代理、2）所有服务器、3）所有客户端、4）所有终端实体、5）所有注册实体、6）所有证书颁发机构。
There are several different terms, abbreviations, and acronyms used in this document that we define here for convenience and consistency of usage:
本文件中使用了几个不同的术语、缩写和首字母缩略词，我们在此处对其进行了定义，以便于使用和保持一致性：
End-Entity (EE) refers to the entity that owns a key pair and for whom a certificate is issued.
终端实体（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.
身份证明是指客户端向服务器证明他们是他们所说的那个人。
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.
占有证明（POP）是指可用于证明与公钥对应的私钥处于占有状态并可由最终实体使用的值。
Transport wrapper refers to the outermost CMS wrapping layer.
传输包装是指最外层的CMS包装层。
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 [MUST].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[必须]中所述进行解释。
All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered to unless specifically stated otherwise in this document.
除非本文件另有明确规定，否则必须遵守所有[CMC-STRUCT]和[CMC-TRANS]合规声明。
All entities MUST support Full PKI Requests, Simple PKI Responses, and Full PKI Responses. Servers SHOULD support Simple PKI Requests.
所有实体都必须支持完整的PKI请求、简单的PKI响应和完整的PKI响应。服务器应支持简单的PKI请求。
All entities MUST support the use of the CRMF syntax for certification requests. Support for the PKCS #10 syntax for certification requests SHOULD be implemented by servers.
所有实体必须支持对认证请求使用CRMF语法。服务器应实现对认证请求的PKCS#10语法的支持。
The extendedFailInfo field SHOULD NOT be populated in the CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay this information. If the extendedFailInfo field is used, it is suggested that an additional CMCStatusInfoV2 item exist for the same body part with a failInfo field.
不应在CMCStatusInfoV2对象中填充extendedFailInfo字段；failInfo字段应用于中继此信息。如果使用extendedFailInfo字段，建议为具有failInfo字段的同一车身零件存在额外的CMCStatusInfoV2项。
All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
所有实体必须实现[CMC-TRANS]中定义的HTTP传输机制。可以实施其他传输机制。
All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in SignedData (see [CMS-ALG]). Entities MAY verify other signature algorithms. It is strongly suggested that RSA-PSS with SHA-1 be verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256 using RSA and RSA-PSS be verified (see [RSA-256]).
所有实体必须验证SignedData中的DSA-SHA1和RSA-SHA1签名（参见[CMS-ALG]）。实体可以验证其他签名算法。强烈建议验证带有SHA-1的RSA-PSS（见[CMS-RSA-PSS]）。强烈建议验证使用RSA和RSA-PSS的SHA-256（见[RSA-256]）。
All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used for generation.
所有实体必须为SignedData生成DSA-SHA1或RSA-SHA1签名（参见[CMS-ALG]）。其他签名算法可用于生成。
All entities MUST support Advanced Encryption Standard (AES) as the content encryption algorithm for EnvelopedData (see [CMS-AES]). Other content encryption algorithms MAY be implemented.
所有实体都必须支持高级加密标准（AES）作为信封数据的内容加密算法（见[CMS-AES]）。可以实现其他内容加密算法。
All entities MUST support RSA as a key transport algorithm for EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP (see [CMS-RSA-OAEP]) as a key transport algorithm. Other key transport algorithms MAY be implemented.
所有实体都必须支持RSA作为EnvelopedData的密钥传输算法（请参见[CMS-ALG]）。所有实体都应支持RSA-OAEP（参见[CMS-RSA-OAEP]）作为密钥传输算法。可以实现其他密钥传输算法。
If an entity supports key agreement for EnvelopedData, it MUST support Diffie-Hellman (see [CMS-DH]).
如果实体支持EnvelopedData的密钥协议，则它必须支持Diffie Hellman（参见[CMS-DH]）。
If an entity supports PasswordRecipientInfo for EnvelopedData or AuthenticatedData, it MUST support PBKDF2 [PBKDF2] for key derivation algorithms. It MUST support AES key wrap (see [AES-WRAP] as the key encryption algorithm.
如果实体对EnvelopedData或AuthenticatedData支持PasswordRecipientInfo，则必须对密钥派生算法支持PBKDF2[PBKDF2]。它必须支持AES密钥包裹（参见[AES-wrap]作为密钥加密算法）。
If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported.
如果支持AuthenticatedData，则必须支持PasswordRecipientInfo。
Algorithm requirements for the Identity Proof Version 2 control (Section 6.2.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1 MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented for macAlgId.
身份验证版本2控件（CMC-STRUCT第6.2.1节）的算法要求为：必须为hashAlgId实现SHA-1。hashAlgId应该实现SHA-256。必须为macAlgId实现HMAC-SHA1。应为macAlgId实现HMAC-SHA256。
Algorithm requirements for the Pop Link Witness Version 2 control (Section 6.3.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for keyGenAlgorithm. SHA-256 SHOULD be implemented for keyGenAlgorithm. PBKDF2 [PBKDF2] MAY be implemented for keyGenAlgorithm. HMAC-SHA1 MUST be implemented for macAlgorithm. HMAC-SHA256 SHOULD be implemented for macAlgorithm.
Pop-Link见证版本2控件（CMC-STRUCT第6.3.1节）的算法要求为：必须为keyGenAlgorithm实现SHA-1。密钥生成算法应实现SHA-256。PBKDF2[PBKDF2]可用于keyGenAlgorithm。必须为macAlgorithm实现HMAC-SHA1。macAlgorithm应实现HMAC-SHA256。
Algorithm requirements for the Encrypted POP and Decrypted POP controls (Section 6.7 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for witnessAlgID. SHA-256 SHOULD be implemented for witnessAlgID. HMAC-SHA1 MUST be implemented for thePOPAlgID. HMAC-SHA256 SHOULD be implemented for thePOPAlgID.
加密POP和解密POP控件（CMC-STRUCT第6.7节）的算法要求为：必须为witnessAlgID执行SHA-1。SHA-256应用于见证阿尔及德。必须为POPALGID实现HMAC-SHA1。应为POPALGID实现HMAC-SHA256。
Algorithm requirements for Publish Trust Anchors control (Section 6.15 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for hashAlgorithm. SHA-256 SHOULD be implemented for hashAlgorithm.
发布信任锚控制（CMC-STRUCT第6.15节）的算法要求为：hashAlgorithm必须实现SHA-1。哈希算法应实现SHA-256。
If an EE generates DH keys for certification, it MUST support section 4 of [DH-POP]. EEs MAY support Section 3 of [DH-POP]. CAs and RAs that do POP verification MUST support Section 4 of [DH-POP] and SHOULD support Section 3 of [DH-POP].
如果EE生成用于认证的DH密钥，则必须支持[DH-POP]的第4节。EEs可支持[DH-POP]第3节。进行POP验证的CA和RA必须支持[DH-POP]第4节，并应支持[DH-POP]第3节。
EEs that need to use a signature algorithm for keys that cannot produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST support the Encrypted/Decrypted POP controls. CAs and RAs that do POP verification MUST support this signature algorithm and MUST support the Encrypted/Decrypted POP controls.
对于无法生成签名的密钥，需要使用签名算法的EE必须支持[CMC-STRUCT]的附录C，并且必须支持加密/解密的POP控件。进行POP验证的CA和RAs必须支持此签名算法，并且必须支持加密/解密的POP控件。
The following table lists the name and level of support required for each control.
下表列出了每个控件所需的名称和支持级别。
+----------------------------+----------+----------+----------+
| Control | EE | RA | CA |
+----------------------------+----------+----------+----------+
| Extended CMC Status Info | MUST | MUST | MUST |
| | | | |
| CMC Status Info | SHOULD | SHOULD | SHOULD |
| | | | |
| Identity Proof Version 2 | MUST | MUST | MUST |
| | | | |
| Identity Proof | SHOULD | SHOULD | SHOULD |
| | | | |
| Identification | MUST | MUST | MUST |
| | | | |
| POP Link Random | MUST | MUST | MUST |
| | | | |
| POP Link Witness Version 2 | MUST | MUST | MUST |
| | | | |
| POP Link Witness | SHOULD | MUST | MUST |
| | | | |
| Data Return | MUST | MUST | MUST |
| | | | |
| Modify Cert Request | N/A | MUST | (2) |
| | | | |
| Add Extensions | N/A | MAY | (1) |
| | | | |
| Transaction ID | MUST | MUST | MUST |
| | | | |
| Sender Nonce | MUST | MUST | MUST |
| | | | |
| Recipient Nonce | MUST | MUST | MUST |
| | | | |
| Encrypted POP | (4) | (5) | SHOULD |
| | | | |
| Decrypted POP | (4) | (5) | SHOULD |
| | | | |
| RA POP Witness | N/A | SHOULD | (1) |
| | | | |
| Get Certificate | optional | optional | optional |
| | | | |
| Get CRL | optional | optional | optional |
| | | | |
| Revocation Request | SHOULD | SHOULD | MUST |
| | | | |
+----------------------------+----------+----------+----------+
| Control | EE | RA | CA |
+----------------------------+----------+----------+----------+
| Extended CMC Status Info | MUST | MUST | MUST |
| | | | |
| CMC Status Info | SHOULD | SHOULD | SHOULD |
| | | | |
| Identity Proof Version 2 | MUST | MUST | MUST |
| | | | |
| Identity Proof | SHOULD | SHOULD | SHOULD |
| | | | |
| Identification | MUST | MUST | MUST |
| | | | |
| POP Link Random | MUST | MUST | MUST |
| | | | |
| POP Link Witness Version 2 | MUST | MUST | MUST |
| | | | |
| POP Link Witness | SHOULD | MUST | MUST |
| | | | |
| Data Return | MUST | MUST | MUST |
| | | | |
| Modify Cert Request | N/A | MUST | (2) |
| | | | |
| Add Extensions | N/A | MAY | (1) |
| | | | |
| Transaction ID | MUST | MUST | MUST |
| | | | |
| Sender Nonce | MUST | MUST | MUST |
| | | | |
| Recipient Nonce | MUST | MUST | MUST |
| | | | |
| Encrypted POP | (4) | (5) | SHOULD |
| | | | |
| Decrypted POP | (4) | (5) | SHOULD |
| | | | |
| RA POP Witness | N/A | SHOULD | (1) |
| | | | |
| Get Certificate | optional | optional | optional |
| | | | |
| Get CRL | optional | optional | optional |
| | | | |
| Revocation Request | SHOULD | SHOULD | MUST |
| | | | |
| Registration Info | SHOULD | SHOULD | SHOULD |
| | | | |
| Response Information | SHOULD | SHOULD | SHOULD |
| | | | |
| Query Pending | MUST | MUST | MUST |
| | | | |
| Confirm Cert. Acceptance | MUST | MUST | MUST |
| | | | |
| Publish Trust Anchors | (3) | (3) | (3) |
| | | | |
| Authenticate Data | (3) | (3) | (3) |
| | | | |
| Batch Request | N/A | MUST | (2) |
| | | | |
| Batch Responses | N/A | MUST | (2) |
| | | | |
| Publication Information | optional | optional | optional |
| | | | |
| Control Processed | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
| Registration Info | SHOULD | SHOULD | SHOULD |
| | | | |
| Response Information | SHOULD | SHOULD | SHOULD |
| | | | |
| Query Pending | MUST | MUST | MUST |
| | | | |
| Confirm Cert. Acceptance | MUST | MUST | MUST |
| | | | |
| Publish Trust Anchors | (3) | (3) | (3) |
| | | | |
| Authenticate Data | (3) | (3) | (3) |
| | | | |
| Batch Request | N/A | MUST | (2) |
| | | | |
| Batch Responses | N/A | MUST | (2) |
| | | | |
| Publication Information | optional | optional | optional |
| | | | |
| Control Processed | N/A | MUST | (2) |
+----------------------------+----------+----------+----------+
Table 1: CMC Control Attributes
表1:CMC控件属性
Notes:
笔记：
1. CAs SHOULD implement this control if designed to work with RAs.
1. 如果CAs设计用于RAs，则应实施此控制。
2. CAs MUST implement this control if designed to work with RAs.
2. 如果CAs设计用于RAs，则必须实施此控制。
3. Implementation is optional for these controls. We strongly suggest that they be implemented in order to populate client trust anchors.
3. 这些控件的实现是可选的。我们强烈建议实现它们以填充客户信任锚。
4. EEs only need to implement this if (a) they support key agreement algorithms or (b) they need to operate in environments where the hardware keys cannot provide POP.
4. 仅当（a）EEs支持密钥协商算法或（b）EEs需要在硬件密钥无法提供POP的环境中运行时，EEs才需要实现这一点。
5. RAs SHOULD implement this if they implement RA POP Witness.
5. 如果RAs实现RA POP见证，则应实现此功能。
Strong consideration should be given to implementing the Authenticate Data and Publish Trust Anchors controls as this gives a simple method for distributing trust anchors into clients without user intervention.
应充分考虑实施“验证数据”和“发布信任锚”控件，因为这提供了一种无需用户干预即可将信任锚分发到客户端的简单方法。
The following additional restrictions are placed on CRMF features:
CRMF功能有以下附加限制：
The registration control tokens id-regCtrl-regToken and id-regCtrl-authToken MUST NOT be used. No specific CMC feature is used to replace these items, but generally the CMC controls identification and identityProof will perform the same service and are more specifically defined.
不得使用注册控制令牌id REGCRL REGTONKEN和id REGCRL authToken。没有使用特定的CMC功能来替换这些项目，但通常CMC控制标识和标识屋顶将执行相同的服务，并且定义得更为具体。
The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. An alternative method is under development to provide this functionality.
不应支持控制令牌id REGCRL pkiArchiveOptions。正在开发一种替代方法来提供此功能。
The behavior of id-regCtrl-oldCertID is not presently used. It is replaced by issuing the new certificate and using the id-cmc-publishCert to remove the old certificate from publication. This operation would not normally be accompanied by an immediate revocation of the old certificate; however, that can be accomplished by the id-cmc-revokeRequest control.
id regCtrl oldCertID的行为目前未使用。它由颁发新证书和使用id cmc publishCert从发布中删除旧证书来替换。此操作通常不会立即撤销旧证书；但是，这可以通过id cmc revokeRequest控件实现。
The id-regCtrl-protocolEncrKey is not used.
未使用id REGCRL protocolEncrKey。
There are no additional requirements.
没有其他要求。
There are no additional requirements.
没有其他要求。
If an entity implements Diffie-Hellman, it MUST implement either the DH-POP Proof-of-Possession as defined in [DH-POP], Section 4, or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
如果实体实现Diffie Hellman，则必须实现[DH-POP]第4节中定义的DH-POP占有证明，或质询响应POP控制id cmc encryptedPOP和id cmc decryptedPOP。
RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.
RAs应该能够完成授权POP。实现此功能的RAs必须实现id cmc LRP见证控件。
All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in Section 3.2.3 of [CMC-STRUCT].
所有RAs必须按照[cmc-STRUCT]第3.2.3节的规定推广id aa cmc unsignedData。
Providing for CAs to work in an environment with RAs is strongly suggested. Implementation of such support is strongly suggested as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA.
强烈建议让CAs在具有RAs的环境中工作。强烈建议实施此类支持，因为这允许将实质性的行政互动委托给RA而不是CA。
CAs MUST perform at least minimal checks on all public keys before issuing a certificate. At a minimum, a check for syntax would occur with the POP operation. Additionally, CAs SHOULD perform simple checks for known bad keys such as small subgroups for DSA-SHA1 and DH keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys.
CA在颁发证书之前，必须至少对所有公钥执行最低限度的检查。至少，POP操作会检查语法。此外，CA应该对已知的坏密钥执行简单检查，例如DSA-SHA1和DH密钥的小子组[small-SUB-GROUP]或RSA密钥的已知坏指数。
CAs MUST enforce POP checking before issuing any certificate. CAs MAY delegate the POP operation to an RA for those cases where 1) a challenge/response message pair must be used, 2) an RA performs escrow of a key and checks for POP in that manner, or 3) an unusual algorithm is used and that validation is done at the RA.
CA必须在颁发任何证书之前执行POP检查。CAs可将POP操作委托给RA，用于以下情况：1）必须使用质询/响应消息对，2）RA执行密钥托管并以这种方式检查POP，或3）使用异常算法并在RA处进行验证。
CAs SHOULD implement both the DH-POP Proof-of-Possession as defined in [DH-POP], Section 4, and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
CAs应实施[DH-POP]第4节中定义的DH-POP占有证明，以及质询响应POP控制id cmc encryptedPOP和id cmc decryptedPOP。
This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to this document. The security sections of those two documents are included by reference.
本文档使用[CMC-STRUCT]和[CMC-TRANS]作为本文档的构建块。这两份文件的安全部分以参考方式包括在内。
Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable to that entity. Care needs to be taken in determining which sections apply and fully implementing the necessary code.
了解一个实体的预期运营方式对于确定需求的哪些部分适用于该实体至关重要。在确定哪些章节适用和全面实施必要的规范时需要谨慎。
Cryptographic algorithms have and will be broken or weakened. Implementers and users need to check that the cryptographic algorithms listed in this document make sense from a security level. The IETF from time to time may issue documents dealing with the current state of the art. Two examples of such documents are [SMALL-SUB-GROUP] and [HASH-ATTACKS].
密码算法已经并将被破坏或削弱。实现者和用户需要检查本文档中列出的加密算法在安全级别上是否有意义。IETF可不时发布涉及当前技术状态的文件。此类文档的两个示例是[SMALL-SUB-GROUP]和[HASH-ATTACKS]。
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的贡献。
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[CMC-STRUCT]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[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月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMS-AES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMS-ALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMS-DH]Rescorla，E.“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[CRMF]Schaad，J.，“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 4211，2005年9月。
[CMS-RSA-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[CMS-RSA-OAEP]Housley，R.，“在加密消息语法（CMS）中使用RSAES-OAEP密钥传输算法”，RFC3560，2003年7月。
[CMS-RSA-PSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[CMS-RSA-PSS]Schaad，J.，“在加密消息语法（CMS）中使用RSASSA-PSS签名算法”，RFC 4056，2005年6月。
[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月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[必须]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[RSA-256] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RSA-256]Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[PBKDF2]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification v1.7", RFC 2986, November 2000.
[PKCS10]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范v1.7”，RFC 2986，2000年11月。
[SMALL-SUB-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-SUB-GROUP]Zuccherato，R.，“避免针对S/MIME的Diffie-Hellman密钥协商方法的“小子组”攻击的方法”，RFC 27852000年3月。
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[散列攻击]Hoffman，P.和B.Schneier，“对互联网协议中加密散列的攻击”，RFC 42702005年11月。
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.