Network Working Group J. Schaad
Request for Comments: 4211 Soaring Hawk Consulting
Obsoletes: 2511 September 2005
Category: Standards Track
Network Working Group J. Schaad
Request for Comments: 4211 Soaring Hawk Consulting
Obsoletes: 2511 September 2005
Category: Standards Track
Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
Internet X.509公钥基础设施证书请求消息格式（CRMF）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol.
本文档描述了证书请求消息格式（CRMF）语法和语义。此语法用于将证书请求传递给证书颁发机构（CA），可能是通过注册机构（RA），以便生成X.509证书。请求通常包括公钥和相关的注册信息。本文档未定义证书请求协议。
Table Of Contents
目录
1. Introduction and Terminology ....................................3
2. Overview ........................................................3
2.1. Changes since RFC 2511 .....................................4
3. CertReqMessage Syntax ...........................................4
4. Proof-of-Possession (POP) .......................................5
4.1. Signature Key POP ..........................................7
4.2. Key Encipherment Keys ......................................9
4.2.1. Private Key Info Content Type ......................11
4.2.2. Private Key Structures .............................12
4.2.3. Challenge-Response Guidelines ......................13
4.3. Key Agreement Keys ........................................14
4.4. Use of Password-Based MAC .................................14
5. CertRequest syntax .............................................16
6. Controls Syntax ................................................18
6.1. Registration Token Control ................................18
6.2. Authenticator Control .....................................19
6.3. Publication Information Control ...........................19
6.4. Archive Options Control ...................................21
6.5. OldCert ID Control ........................................23
6.6. Protocol Encryption Key Control ...........................23
7. RegInfo Controls ...............................................23
7.1. utf8Pairs .................................................23
7.2. certReq ...................................................24
8. Object Identifiers .............................................24
9. Security Considerations ........................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
11. Acknowledgements ..............................................28
Appendix A. Use of RegInfo for Name-Value Pairs ..................29
A.1. Defined Names ............................................29
A.2. IssuerName, SubjectName, and Validity Value Encoding .....29
Appendix B. ASN.1 Structures and OIDs ............................32
Appendix C. Why do Proof-of-Possession (POP) .....................38
1. Introduction and Terminology ....................................3
2. Overview ........................................................3
2.1. Changes since RFC 2511 .....................................4
3. CertReqMessage Syntax ...........................................4
4. Proof-of-Possession (POP) .......................................5
4.1. Signature Key POP ..........................................7
4.2. Key Encipherment Keys ......................................9
4.2.1. Private Key Info Content Type ......................11
4.2.2. Private Key Structures .............................12
4.2.3. Challenge-Response Guidelines ......................13
4.3. Key Agreement Keys ........................................14
4.4. Use of Password-Based MAC .................................14
5. CertRequest syntax .............................................16
6. Controls Syntax ................................................18
6.1. Registration Token Control ................................18
6.2. Authenticator Control .....................................19
6.3. Publication Information Control ...........................19
6.4. Archive Options Control ...................................21
6.5. OldCert ID Control ........................................23
6.6. Protocol Encryption Key Control ...........................23
7. RegInfo Controls ...............................................23
7.1. utf8Pairs .................................................23
7.2. certReq ...................................................24
8. Object Identifiers .............................................24
9. Security Considerations ........................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
11. Acknowledgements ..............................................28
Appendix A. Use of RegInfo for Name-Value Pairs ..................29
A.1. Defined Names ............................................29
A.2. IssuerName, SubjectName, and Validity Value Encoding .....29
Appendix B. ASN.1 Structures and OIDs ............................32
Appendix C. Why do Proof-of-Possession (POP) .....................38
This document describes the Certificate Request Message Format (CRMF). A Certificate Request Message object is used within a protocol to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information.
本文档介绍证书请求消息格式（CRMF）。证书请求消息对象在协议中用于将证书请求传送给证书颁发机构（CA），可能是通过注册机构（RA），用于X.509证书的生成。请求通常包括公钥和相关的注册信息。
The certificate request object defined in this document is not a stand-alone protocol. The information defined in this document is designed to be used by an externally defined Certificate Request Protocol (CRP). The referencing protocol is expected to define what algorithms are used, and what registration information and control structures are defined. Many of the requirements in this document refer to the referencing Certificate Request Protocol (CRP).
本文档中定义的证书请求对象不是独立协议。本文档中定义的信息旨在由外部定义的证书请求协议（CRP）使用。参考协议应定义使用的算法，以及定义的注册信息和控制结构。本文档中的许多要求涉及引用证书请求协议（CRP）。
Certificate requests may be submitted by an RA requesting a certificate on behalf of a Subject, by a CA requesting a cross-certificate from another CA, or directly by an End Entity (EE).
证书请求可以由代表主体请求证书的RA提交，也可以由从另一CA请求交叉证书的CA提交，或者直接由终端实体（EE）提交。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“必需”、“应该”、“建议”和“可能”（大写，如图所示）应按照RFC 2119[RFC2119]中的说明进行解释。
Construction of a certification request involves the following steps:
构建认证请求涉及以下步骤：
a) A CertRequest object is constructed. This object may include the public key, all or a portion of the Subject name, other requested certificate fields, and additional control information related to the registration process. Depending on the CRP, this information can be specified by the Subject and potentially modified by an RA, or specified by the RA based on knowledge of the Subject or documentation presented by the Subject.
a) 构造了CertRequest对象。该对象可以包括公钥、全部或部分主体名称、其他请求的证书字段以及与注册过程相关的附加控制信息。根据CRP，该信息可由受试者指定并可能由RA修改，或由RA根据受试者的知识或受试者提供的文件指定。
b) If required, a proof-of-possession (of the private key corresponding to the public key for which a certificate is being requested) value is calculated.
b) 如果需要，将计算占有证明（与请求证书的公钥相对应的私钥）值。
c) Additional registration information can be combined with the proof-of-possession value and the CertRequest structure to form a CertReqMessage. Additional registration information can be added by both the Subject and an RA.
c) 附加的注册信息可以与占有价值证明和CertRequest结构结合起来形成CertReqMessage。受试者和RA都可以添加其他注册信息。
d) The CertReqMessage is securely communicated to a CA. Specific means of secure transport are to be specified by each CRP that refers to this document.
d) CertReqMessage安全地传达给CA。参考本文件的每个CRP都应指定特定的安全传输方式。
1. Addition of an introduction section.
1. 增加介绍部分。
2. Addition of the concept of a CRP and language relating to CRPs.
2. 增加了CRP的概念和与CRP相关的语言。
3. In section 6.2, changed regToken to authenticator.
3. 在第6.2节中，将regToken更改为authenticator。
4. Add information describing the contents of the EncryptedValue structure.
4. 添加描述EncryptedValue结构内容的信息。
5. Changed name and contents of OID {id-regInfo 1}.
5. 已更改OID{id regInfo 1}的名称和内容。
6. Added text detailing what goes into the fields of the different structures defined in the document.
6. 添加文本，详细说明文档中定义的不同结构的字段中的内容。
7. Replaced Appendix A with a reference to [RFC2875]. The only difference is that the old text specified to use subject alt name instead of subject name if subject name was empty. This is not possible for a CA certificate issued using PKIX. It would however be useful to update RFC 2875 to have this fallback position.
7. 将附录A替换为参考[RFC2875]。唯一的区别是，旧文本指定在subject name为空时使用subject alt name而不是subject name。对于使用PKIX颁发的CA证书，这是不可能的。然而，将RFC 2875更新为该后备位置将是有用的。
7. Insert Appendix C describing why POP is necessary and what some of the different POP attacks are.
7. 插入附录C，说明为什么需要POP以及一些不同的POP攻击是什么。
8. pop field in the CertReqMsg structure has been renamed to popo to avoid confusion between POP and pop.
8. CertReqMsg结构中的pop字段已重命名为popo，以避免pop和pop之间的混淆。
9. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure.
9. EncryptedValue结构的使用已被弃用，取而代之的是EnvelopedData结构。
10. Add details on how private keys are to be structured when encrypted.
10. 添加有关加密时如何构造私钥的详细信息。
11. Allow for POP on key agreement algorithms other than DH.
11. 允许非DH的POP密钥协商算法。
A certificate request message is composed of the certificate request, an optional proof-of-possession field, and an optional registration information field.
证书请求消息由证书请求、可选的占有证明字段和可选的注册信息字段组成。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
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
}
The fields of CertReqMsg have the following meaning:
CertReqMsg的字段具有以下含义：
certReq contains the template of the certificate being requested. The template is filled in by (or on behalf of) the Subject. Not all fields within the template need to be specified. Details on this field are found in section 5.
certReq包含所请求证书的模板。模板由受试者（或其代表）填写。并非模板中的所有字段都需要指定。有关此字段的详细信息，请参见第5节。
popo contains the value used to demonstrate that the entity that will be identified as the Subject of the certificate is actually in possession of the corresponding private key. This field varies in structure and content based on the public key algorithm and the mode (encryption vs. signature) in which the algorithm is used, as specified in the KeyUsage field of the certificate to be issued. Details on this field are found in section 4.
popo包含用于证明将被标识为证书主体的实体实际拥有相应私钥的值。根据公钥算法和算法使用的模式（加密与签名），此字段的结构和内容有所不同，如要颁发的证书的KeyUsage字段中所指定。有关此字段的详细信息，请参见第4节。
regInfo field SHOULD contain only supplementary information relating to the context of the certificate request, where such information is required to fulfill the request. This information might include subscriber contact information, billing information, or other ancillary information useful to fulfillment of the request.
regInfo字段应仅包含与证书请求上下文相关的补充信息，其中此类信息是满足请求所必需的。此信息可能包括订户联系信息、帐单信息或对请求的实现有用的其他辅助信息。
Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs can invalidate the popo field (depending on the details of the POP method used). Therefore, data intended for certificate content MAY be provided in regInfo.
certReq内容中应包含与证书内容直接相关的信息。但是，RAs包含额外的certReq内容可能会使popo字段无效（取决于所用POP方法的详细信息）。因此，可以在regInfo中提供用于证书内容的数据。
It is the responsibility of a referencing CRP to define the details of what can be specified in the regInfo field. This document describes one method of encoding the information found in this field. Details on this encoding are found in Appendix A.
参考CRP负责定义可在regInfo字段中指定内容的详细信息。本文档描述了对该字段中的信息进行编码的一种方法。有关此编码的详细信息，请参见附录A。
In order to prevent certain attacks (see Appendix C) and to allow a CA/RA to properly check the validity of the binding between a subject and a key pair, the PKI management structures specified here make it possible for a subject to prove that it has possession of (i.e., is
为了防止某些攻击（见附录C）并允许CA/RA正确检查主体和密钥对之间绑定的有效性，此处指定的PKI管理结构使主体能够证明其拥有（即
able to use) the private key corresponding to the public key for which a certificate is requested. A given CRP is free to choose how to enforce POP (e.g., out-of-band procedural means versus the CRMF in-band message) in its certification exchanges. Within a given CRP, CAs and RAs are free to choose from among the POP methods provided (i.e., this is a policy issue local to an RA/CA). A CRP SHOULD define either which POP methods are required, or specify a mechanism for clients to discover the POP methods supported.
（能够使用）与请求证书的公钥相对应的私钥。给定的CRP可自由选择如何在其认证交换中实施POP（例如，带外程序手段与CRMF带内消息）。在给定的CRP中，CA和RA可以自由选择提供的POP方法（即，这是RA/CA的本地策略问题）。CRP应该定义需要哪些POP方法，或者为客户端指定一种机制来发现支持的POP方法。
Any CRP referencing this document MUST enforce POP by some means. There are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding cannot be assumed to have been verified by the CA/RA. Therefore, one cannot truly know if the binding of the public key and the identity in the certificate is actually correct.
引用本文件的任何CRP必须通过某种方式强制执行POP。目前使用的许多非PKIX操作协议（各种电子邮件协议就是一个例子）没有明确检查终端实体和私钥之间的绑定。在验证绑定（用于签名、加密和密钥协议密钥对）的操作协议存在并普遍存在之前，不能假设CA/RA已经验证了该绑定。因此，无法真正知道公钥和证书中的标识的绑定是否实际正确。
POP is accomplished in different ways depending on the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., a signing and decryption RSA key), then any of the methods MAY be used. Protocol designers need to be aware that there can be hardware limitations on what POP methods may be usable, e.g., if the private key is maintained in a hardware token.
根据请求证书的密钥类型，POP以不同的方式完成。如果密钥可用于多种目的（例如，签名和解密RSA密钥），则可以使用任何方法。协议设计者需要意识到，哪些POP方法可用可能存在硬件限制，例如，如果私钥保存在硬件令牌中。
This specification allows for cases where POP is validated by the CA, the RA, or both. Some policies require the CA to verify POP during certificate issuance, in which case the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA. (In this case, the RA could verify the POP and reject failing certificate requests rather than forwarding them to the CA.) If the CA is not required by policy to verify POP, then the RA SHOULD forward the end entity's request and proof, unaltered, to the CA as above. If this is not possible (for example because the RA verifies POP by an out-of-band method), then the RA uses the raVerified element to attest to the CA that the required proof has been validated. If the CA/RA uses an out-of-band method to verify POP (such as physical delivery of CA/RA-generated private keys), then the ProofOfPossession field is omitted.
本规范允许由CA、RA或两者验证POP的情况。某些策略要求CA在证书颁发期间验证POP，在这种情况下，RA必须将最终实体的CertRequest和ProvofPassession字段未经更改地转发给CA。（在这种情况下，RA可以验证POP并拒绝失败的证书请求，而不是转发给CA。）如果政策不要求CA验证POP，则RA应将最终实体的请求和证据（未更改）转发给CA，如上所述。如果这是不可能的（例如，因为RA通过带外方法验证POP），则RA使用raVerified元素向CA证明所需证据已验证。如果CA/RA使用带外方法来验证POP（如CA/RA生成的私钥的物理传递），则忽略“验证通过”字段。
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
The fields of ProofOfPossession have the following meaning:
证明同意的字段具有以下含义：
raVerified indicates that the RA has performed the POP required on the certificate request. This field is used by an RA when 1) the CA is not required to do its own POP verification and 2) the RA needs to change the contents of the certReq field. CRPs MUST provide a method for the RA to sign the ProofOfPossession. A requestor MUST NOT set this field and an RA/CA MUST NOT accept a ProofOfPossession where the requestor sets this field.
raVerified表示RA已执行证书请求所需的POP。当1）CA不需要自己进行POP验证，2）RA需要更改certReq字段的内容时，RA使用此字段。CRP必须提供RA签署批准证明的方法。请求者不得设置此字段，RA/CA不得接受请求者设置此字段的通过证明。
signature is used for performing POP with signature keys. The details of this field are covered in section 4.1.
签名用于使用签名密钥执行POP。该字段的详细信息见第4.1节。
keyEncipherment is used for performing POP with key encipherment encryption based keys (i.e., RSA). The details of this field are covered in section 4.2.
密钥加密用于使用基于密钥加密的密钥（即RSA）执行POP。该字段的详细信息见第4.2节。
keyAgreement is used for performing POP with key agreement type encryption keys (i.e., DH). The details of this field are covered in section 4.3.
keyAgreement用于使用密钥协议类型的加密密钥（即DH）执行POP。该字段的详细信息见第4.3节。
POP for a signature key is accomplished by performing a signature operation on a piece of data containing the identity for which the certificate is desired.
签名密钥的POP是通过对包含所需证书的标识的数据段执行签名操作来实现的。
There are three cases that need to be looked at when doing a POP for a signature key:
在对签名密钥执行POP时，需要考虑三种情况：
1. The certificate subject has not yet established an authenticated identity with a CA/RA, but has a password and identity string from the CA/RA. In this case, the POPOSigningKeyInput structure would be filled out using the publicKeyMAC choice for authInfo, and the password and identity would be used to compute the publicKeyMAC value. The public key for the certificate being requested would be placed in both the POPOSigningKeyInput and the Certificate Template structures. The signature field is computed over the DER-encoded POPOSigningKeyInput structure.
1. 证书主体尚未使用CA/RA建立经过身份验证的标识，但具有来自CA/RA的密码和标识字符串。在这种情况下，将使用authInfo的publicKeyMAC选项填写POPOSigningKeyInput结构，并使用密码和标识计算publicKeyMAC值。正在请求的证书的公钥将放置在POPOSigningKeyInput和证书模板结构中。签名字段是在DER编码的POPOSigningKeyInput结构上计算的。
2. The CA/RA has established an authenticated identity for the certificate subject, but the requestor is not placing it into the certificate request. In this case, the POPOSigningKeyInput structure would be filled out using the sender choice for authInfo. The public key for the certificate being requested would be placed in both the POPOSigningKeyInput and the Certificate Template structures. The signature field is computed over the DER-encoded POPOSigningKeyInput structure.
2. CA/RA已经为证书主体建立了经过身份验证的标识，但请求者没有将其放入证书请求中。在这种情况下，将使用authInfo的sender选项填写poposigningkeyinport结构。正在请求的证书的公钥将放置在POPOSigningKeyInput和证书模板结构中。签名字段是在DER编码的POPOSigningKeyInput结构上计算的。
3. The certificate subject places its name in the Certificate Template structure along with the public key. In this case the poposkInput field is omitted from the POPOSigningKey structure. The signature field is computed over the DER-encoded certificate template structure.
3. 证书主体将其名称与公钥一起放入证书模板结构中。在这种情况下，POPOSigningKey结构中省略了poposkInput字段。签名字段是通过DER编码的证书模板结构计算的。
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
The fields of POPOSigningKey have the following meaning:
POPOSigningKey的字段具有以下含义：
poposkInput contains the data to be signed, when present. This field MUST be present when the certificate template does not contain both the public key value and a subject name value.
poposkInput包含要签名的数据（如果存在）。当证书模板不同时包含公钥值和使用者名称值时，此字段必须存在。
algorithmIdentifier identifiers the signature algorithm and an associated parameters used to produce the POP value.
algorithmIdentifier标识符用于生成POP值的签名算法和相关参数。
signature contains the POP value produce. If poposkInput is present, the signature is computed over the DER-encoded value of poposkInput. If poposkInput is absent, the signature is computed over the DER-encoded value of certReq.
签名包含生成的POP值。如果存在poposkInput，则根据poposkInput的DER编码值计算签名。如果缺少poposkInput，则根据certReq的DER编码值计算签名。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
The fields of POPOSigningKeyInput have the following meaning:
POPOSigningKeyInput的字段具有以下含义：
sender contains an authenticated identity that has been previously established for the subject.
发件人包含以前为主题建立的经过身份验证的标识。
publicKeyMAC contains a computed value that uses a shared secret between the CA/RA and the certificate requestor.
publicKeyMAC包含一个计算值，该值使用CA/RA和证书请求者之间的共享密钥。
publicKey contains a copy of the public key from the certificate template. This MUST be exactly the same value as is contained in the certificate template.
公钥包含证书模板中公钥的副本。该值必须与证书模板中包含的值完全相同。
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
The fields of PKMACValue have the following meaning:
PKMACValue字段具有以下含义：
algId identifies the algorithm used to compute the MAC value. All implementations MUST support id-PasswordBasedMAC. The details on this algorithm are presented in section 4.4.
algId确定了用于计算MAC值的算法。所有实现都必须支持id PasswordBasedMAC。有关该算法的详细信息，请参见第4.4节。
value contains the computed MAC value. The MAC value is computed over the DER-encoded public key of the certificate subject.
值包含计算的MAC值。MAC值通过证书主体的DER编码公钥计算。
The CA/RA identifies the shared secret to be used by looking at 1) the general name field in the certificate request or 2) either the regToken (see section 6.1) or authToken (see section 6.2) controls.
CA/RA通过查看1）证书请求中的通用名称字段或2）regToken（参见第6.1节）或authToken（参见第6.2节）控件来标识要使用的共享密钥。
POP for key encipherment keys is accomplished by one of three different methods. The private key can be provided to the CA/RA, an encrypted challenge from the CA/RA can be decrypted (direct method), or the created certificate can be returned encrypted and used as the challenge response (indirect method).
密钥加密密钥的POP由三种不同的方法之一实现。私钥可以提供给CA/RA，来自CA/RA的加密质询可以解密（直接方法），或者创建的证书可以加密返回并用作质询响应（间接方法）。
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- deprecated
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING, -- deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which must include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in RFC 2875 for static DH proof-of-possession.
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- deprecated
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING, -- deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which must include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in RFC 2875 for static DH proof-of-possession.
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1) }
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1) }
The fields of POPOPrivKey have the following meaning:
POPOPrivKey字段具有以下含义：
thisMessage contains the encrypted private key for which a certificate is to be issued. The possession of the private key is proved by providing it to the CA/RA. This field was incorrectly
此消息包含要为其颁发证书的加密私钥。通过向CA/RA提供私钥来证明私钥的拥有。此字段不正确
typed when the specification was first written. The correct way to use this field is to create an EncryptedValue structure where the encrypted content is the private key, the EncryptedValue structure is then wrapped in the BIT STRING type. This field has been deprecated in favor of encryptedKey.
在第一次编写规范时键入。使用此字段的正确方法是创建一个EncryptedValue结构，其中加密内容是私钥，EncryptedValue结构随后包装为位字符串类型。此字段已被弃用，取而代之的是encryptedKey。
subsequentMessage is used to indicate that the POP will be completed by decrypting a message from the CA/RA and returning a response. The type of message to be decrypted is indicated by the value used.
subsequentMessage用于指示POP将通过解密来自CA/RA的消息并返回响应来完成。要解密的消息类型由使用的值指示。
encrCert indicates that the certificate issued is to be returned in an encrypted form. The requestor is required to decrypt the certificate and prove success to the CA/RA. The details of this are provided by the CRP.
encrCert表示将以加密形式返回颁发的证书。请求者需要解密证书并向CA/RA证明成功。详细情况由CRP提供。
challengeResponse indicates that a challenge message is to be sent from the CA/RA to the requestor. The details of the challenge message and the response are to be provided by the CRP.
challengeResponse表示将从CA/RA向请求者发送质询消息。质询信息和响应的详细信息将由CRP提供。
dhMAC is used for Diffie-Hellman key agreement keys. It contains a computed MAC that is obtained by using the requestor's private key and the CA/RA public key. The use of this field is deprecated in favor of the agreeMAC field. Details are covered in section 4.3.
dhMAC用于Diffie-Hellman密钥协议密钥。它包含通过使用请求者的私钥和CA/RA公钥获得的计算MAC。不赞成使用此字段，而赞成使用agreeMAC字段。详情见第4.3节。
agreeMAC is used for key agreement keys. It contains a computed MAC that is obtained by using the requestor's private key and a matching CA/RA public key. Details are covered in section 4.3.
agreeMAC用于密钥协议密钥。它包含通过使用请求者的私钥和匹配的CA/RA公钥获得的计算MAC。详情见第4.3节。
macAlg contains the algorithm identifying the method used to compute the MAC value.
macAlg包含识别用于计算MAC值的方法的算法。
macValue contains the computed MAC value.
macValue包含计算出的MAC值。
encryptedKey contains the encrypted private key matching the public key for which the certificate is to be issued. It also contains an identification value to indicate it was constructed by the requestor of the certificate. The enveloped content type MUST be id-ct-encKeyWithID.
encryptedKey包含与要为其颁发证书的公钥匹配的加密私钥。它还包含一个标识值，指示它是由证书的请求者构造的。封装的内容类型必须为id ct encKeyWithID。
It is expected that protocols that incorporate this specification will include the confirmation and challenge-response messages necessary for a complete protocol.
预计纳入本规范的协议将包括完整协议所需的确认和质询响应消息。
This content type is used for 1) proving possession of private keys and 2) escrow of private keys (using the archive options control in section 6.4). This structure is based on the private key info structure from [PKCS8] but has one deliberate difference. There is a potential attack on escrow agents if they decrypt the private key but don't know to whom the encrypted key is supposed to belong. An attacker could intercept the encrypted private key, build a certificate request around it and then ask for a recovery operation on the private key.
此内容类型用于1）证明拥有私钥和2）托管私钥（使用第6.4节中的存档选项控制）。此结构基于[PKCS8]中的私钥信息结构，但有一个故意的区别。如果托管代理解密私钥但不知道加密密钥应该属于谁，则可能会受到攻击。攻击者可以截获加密的私钥，围绕该私钥生成证书请求，然后请求对私钥执行恢复操作。
This content type and its structure are:
此内容类型及其结构为：
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
Attributes ::= SET OF Attribute
Attributes ::= SET OF Attribute
The fields of EncKeyWithID are defined as:
EncKeyWithID的字段定义为：
privateKey contains the encoded private key. Definitions for three private key formats are included in this document. Specifications for asymmetric algorithms need to include both the public and private key definitions for consistency.
privateKey包含编码的私钥。本文档包含三种私钥格式的定义。非对称算法的规范需要包括公钥和私钥定义，以确保一致性。
identifier contains a name that the CA/RA can associate with the requestor. This will generally be either the DN of a certificate or a text token passed and known to both the requestor and the CA/RA. This field MUST be present if the purpose is to prove possession of the private key. The field SHOULD be present if archiving a key and the archive agent is expected to decrypt the key.
标识符包含CA/RA可以与请求者关联的名称。这通常是证书的DN或请求者和CA/RA都知道并传递的文本令牌。如果目的是证明拥有私钥，则必须显示此字段。如果存档密钥并且存档代理需要解密密钥，则应显示该字段。
The fields of PrivatekeyInfo are define as:
PrivatekeyInfo的字段定义如下：
version MUST be the value 0
版本必须为值0
privateKeyAlgorithm contains the identifier for the private key object
privateKeyAlgorithm包含私钥对象的标识符
privateKey is an octet string whose contents is the private key and whose format is defined by the value of privateKeyAlgorithm.
privateKey是一个八位字符串，其内容是私钥，其格式由privateKeyAlgorithm的值定义。
attributes is a set of attributes. They are extended information that is part of the private key information.
属性是一组属性。它们是作为私钥信息一部分的扩展信息。
We are defining the structures here to be used for three algorithms.
我们在这里定义用于三种算法的结构。
When creating a PrivateKeyInfo for a D-H key, the following rules apply:
为D-H密钥创建PrivateKeyInfo时，以下规则适用：
1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The parameter for id-dh-private-number is DomainParameters (imported from [PKIXALG]).
1. privateKeyAlgorithm必须设置为id dh private number。id dh private number的参数是DomainParameters（从[PKIXALG]导入）。
2. The ASN structure for privateKey MUST be
2. privateKey的ASN结构必须是
DH-PrivateKey ::= INTEGER
DH-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
3. 属性字段必须省略。
When creating a PrivateKeyInfo for a DSA key, the following rules apply:
为DSA密钥创建PrivateKeyInfo时，以下规则适用：
1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters for id-dsa is Dss-Parms (imported from [PKIXALG]).
1. privateKeyAlgorithm必须设置为id dsa。id dsa的参数是Dss Parms（从[PKIXALG]导入）。
2. The ASN structure for privateKey MUST be
2. privateKey的ASN结构必须是
DSA-PrivateKey ::= INTEGER
DSA-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
3. 属性字段必须省略。
When creating a PrivateKeyInfo for an RSA key, the following rules apply:
为RSA密钥创建PrivateKeyInfo时，以下规则适用：
1. The privateKeyAlgorithm MUST be set to rsaEncryption.
1. privateKeyAlgorithm必须设置为RSA加密。
2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in [PKCS1])
2. privateKey的ASN结构必须是RSAPrivateKey（在[PKCS1]中定义）
3. The attributes field MUST be omitted.
3. 属性字段必须省略。
The following provides guidelines to enrollment protocol authors about how an indirect proof-of-possession is expected to work and about some of the areas where one needs to be careful in crafting the messages to implement this POP method.
以下内容为注册协议作者提供了指南，说明了间接占有证明的工作原理，以及在编写消息以实现此POP方法时需要注意的一些方面。
1. The original enrollment request includes a proof of identity of some type and the public portion of the encryption key. Note that the proof of identity needs to cover the public portion of the encryption key to prevent substitution attacks (where the attacker changes your public key for his public key).
1. 原始注册请求包括某种类型的身份证明和加密密钥的公共部分。请注意，身份证明需要覆盖加密密钥的公共部分，以防止替换攻击（攻击者将您的公钥更改为其公钥）。
2. The response message from the server includes an encrypted data value of some type. That value needs to be authenticated in some fashion as having come from the server. The specification needs to include the specifics of how this value is returned for the different key types. For RSA keys, the value can be specified as being directly encrypted by the RSA public key; this will not work for a D-H key where you need to specify an indirect mechanism to encrypt the value.
2. 来自服务器的响应消息包含某种类型的加密数据值。需要以某种方式验证该值是否来自服务器。规范需要包括如何为不同的键类型返回此值的详细信息。对于RSA密钥，可以指定该值由RSA公钥直接加密；这不适用于需要指定间接机制来加密值的D-H密钥。
3. The second request message includes a hash of the decrypted value. This message MUST NOT be just the hash of the encrypted value, as one should never "sign" a completely random value. It is desirable to include information such as the identity string in the hashing process so that this can be made explicitly. This returned value MUST be included in a second proof of identity.
3. 第二个请求消息包括解密值的散列。此消息不能只是加密值的散列，因为不应该对完全随机的值进行“签名”。希望在散列过程中包括诸如标识字符串之类的信息，以便可以显式地进行此操作。此返回值必须包含在第二个身份证明中。
It is strongly suggested that transaction identifiers and nonce values be required when performing indirect POP, as this allows for 1) tying the different messages in the process together and 2) letting each entity inject some amount of random data into the process of doing identity proofs.
强烈建议在执行间接POP时需要事务标识符和nonce值，因为这允许1）将流程中的不同消息绑定在一起，2）允许每个实体在进行身份验证的过程中注入一些随机数据。
POP for key agreement keys is accomplished by one of four different methods. The first three are identical to those presented above for key encryption keys. The fourth method takes advantage of the fact that a shared secret is produced and that the value can be used to MAC information.
密钥协商密钥的POP由四种不同方法之一实现。前三种方法与上面介绍的密钥加密密钥相同。第四种方法利用了一个事实，即产生了一个共享秘密，并且该值可以用于MAC信息。
When the direct or indirect encryption methods presented above are used, the CA/RA will need to create an ephemeral key for those cases where the encryption algorithm parameters do not match between the CA/RA and the requestor.
当使用上述直接或间接加密方法时，CA/RA将需要为CA/RA和请求者之间加密算法参数不匹配的情况创建临时密钥。
The end entity may also MAC the certificate request (using a shared secret key derived from computation) as a fourth alternative for demonstrating POP. This option may be used only if the CA/RA already has a certificate that is known to the end entity and if the Subject is able to use the CA/RA's parameters.
终端实体还可以MAC证书请求（使用从计算中导出的共享密钥），作为演示POP的第四备选方案。仅当CA/RA已经拥有终端实体已知的证书，并且主体能够使用CA/RA的参数时，才可以使用此选项。
For the DH key agreement algorithm, all implementations MUST support the static DH Proof-of-Possession. Details on this algorithm can be found in section 3 of [RFC2875]. NOTE: If either the subject or issuer name in the CA certificate is empty, then the alternative name should be used in its place.
对于DH密钥协商算法，所有实现都必须支持静态DH占有证明。有关此算法的详细信息，请参见[RFC2875]第3节。注意：如果CA证书中的使用者或颁发者名称为空，则应使用替代名称代替。
This MAC algorithm was designed to take a shared secret (a password) and use it to compute a check value over a piece of information. The assumption is that, without the password, the correct check value cannot be computed. The algorithm computes the one-way function multiple times in order to slow down any dictionary attacks against the password value.
这种MAC算法的设计目的是获取一个共享秘密（密码），并使用它计算一条信息的校验值。假设没有密码，就无法计算正确的检查值。该算法多次计算单向函数，以减缓针对密码值的任何字典攻击。
The algorithm identifier and parameter structure used for Password-Based MAC is:
用于基于密码的MAC的算法标识符和参数结构为：
id-PasswordBasedMAC OBJECT IDENTIFIER ::=
{ 1 2 840 113533 7 66 13}
id-PasswordBasedMAC OBJECT IDENTIFIER ::=
{ 1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
The fields of PEMParameter have the following meaning:
PEMParameter的字段具有以下含义：
salt contains a randomly generated value used in computing the key of the MAC process. The salt SHOULD be at least 8 octets (64 bits) long.
salt包含一个随机生成的值，用于计算MAC进程的密钥。salt的长度应至少为8个八位字节（64位）。
owf identifies the algorithm and associated parameters used to compute the key used in the MAC process. All implementations MUST support SHA-1.
owf识别用于计算MAC过程中使用的密钥的算法和相关参数。所有实现都必须支持SHA-1。
iterationCount identifies the number of times the hash is applied during the key computation process. The iterationCount MUST be a minimum of 100. Many people suggest using values as high as 1000 iterations as the minimum value. The trade off here is between protection of the password from attacks and the time spent by the server processing all of the different iterations in deriving passwords. Hashing is generally considered a cheap operation but this may not be true with all hash functions in the future.
iterationCount标识在密钥计算过程中应用哈希的次数。迭代计数必须至少为100。许多人建议使用高达1000次迭代的值作为最小值。这里的折衷是保护密码不受攻击，以及服务器在处理所有不同的密码生成迭代过程中所花费的时间。散列通常被认为是一种廉价的操作，但这可能不是所有的散列函数在将来都是如此。
mac identifies the algorithm and associated parameters of the MAC function to be used. All implementations MUST support HMAC-SHA1 [HMAC]. All implementations SHOULD support DES-MAC and Triple-DES-MAC [PKCS11].
mac标识要使用的mac函数的算法和相关参数。所有实现都必须支持HMAC-SHA1[HMAC]。所有实现都应支持DES-MAC和三重DES-MAC[PKCS11]。
The following is pseudo-code for the algorithm:
以下是算法的伪代码：
Inputs: pw - an octet string containing the user's password data - an octet string containing the value to be MAC-ed Iter - iteration count
输入：pw-一个包含用户密码数据的八位字符串-一个包含待MAC ed Iter值的八位字符串-迭代计数
Output: MAC - an octet string containing the resultant MAC value
输出：MAC-包含结果MAC值的八位字节字符串
1. Generate a random salt value S
1. 生成一个随机的salt值S
2. Append the salt to the pw. K = pw || salt.
2. 将盐添加到pw中。K=pw | |盐。
3. Hash the value of K. K = HASH(K)
3. 散列K的值。K=散列（K）
4. If Iter is greater than zero. Iter = Iter - 1. Goto step 3.
4. 如果Iter大于零。国际热核实验堆=国际热核实验堆-1。转到步骤3。
5. Compute an HMAC as documented in [HMAC].
5. 按照[HMAC]中的说明计算HMAC。
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
Where opad and ipad are defined in [HMAC].
其中[HMAC]中定义了opad和ipad。
The CertRequest syntax consists of a request identifier, a template of certificate content, and an optional sequence of control information.
CertRequest语法由请求标识符、证书内容模板和可选的控制信息序列组成。
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 }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
The fields of CertRequest have the following meaning:
CertRequest字段具有以下含义：
certReqId contains an integer value that is used by the certificate requestor to associate a specific certificate request with a certificate response.
certReqId包含一个整数值，证书请求者使用该整数值将特定证书请求与证书响应关联起来。
certTemplate contains a template of an X.509 certificate. The requestor fills in those fields for which specific values are desired. Details on the fields are given below.
certTemplate包含X.509证书的模板。请求者填写需要特定值的字段。有关字段的详细信息如下所示。
controls contains attributes that are not part of the certificate, but control the context in which the certificate is to be issued. Details on the controls defined in this document can be found in section 6. Other documents may define other controls. CRPs are responsible for specifying which controls are required.
控件包含的属性不是证书的一部分，但控制要在其中颁发证书的上下文。有关本文件中定义的控制措施的详细信息，请参见第6节。其他文件可能会定义其他控制。CRP负责指定所需的控制措施。
The fields of CertTemplate have the following meaning:
CertTemplate的字段具有以下含义：
version MUST be 2 if supplied. It SHOULD be omitted.
如果提供，则版本必须为2。应该省略它。
serialNumber MUST be omitted. This field is assigned by the CA during certificate creation.
序列号必须省略。此字段由CA在证书创建期间分配。
signingAlg MUST be omitted. This field is assigned by the CA during certificate creation.
必须省略签名。此字段由CA在证书创建期间分配。
issuer is normally omitted. It would be filled in with the CA that the requestor desires to issue the certificate in situations where an RA is servicing more than one CA.
发行人通常被省略。在RA为多个CA提供服务的情况下，将填写请求者希望颁发证书的CA。
validity is normally omitted. It can be used to request that certificates either start at some point in the future or expire at some specific time. A case where this field would commonly be used is when a cross certificate is issued for a CA. In this case the validity of an existing certificate would be placed in this field so that the new certificate would have the same validity period as the existing certificate. If validity is not omitted, then at least one of the sub-fields MUST be specified. The sub-fields are as follows:
有效性通常被忽略。它可用于请求证书在将来某个时间开始或在某个特定时间过期。通常使用此字段的情况是为CA颁发交叉证书。在这种情况下，现有证书的有效性将放在该字段中，以便新证书与现有证书具有相同的有效期。如果未忽略有效性，则必须至少指定一个子字段。子字段如下所示：
notBefore contains the requested start time of the certificate. The time follows the same rules as the notBefore time in [PROFILE].
notBefore包含请求的证书开始时间。时间遵循与[PROFILE]中notBefore时间相同的规则。
notAfter contains the requested expiration time of the certificate. The time follows the same rules as the notAfter time in [PROFILE].
notAfter包含请求的证书过期时间。该时间遵循与[PROFILE]中notAfter时间相同的规则。
subject is filled in with the suggested name for the requestor. This would normally be filled in by a name that has been previously issued to the requestor by the CA.
subject用请求者的建议名称填写。这通常由CA先前发给请求者的名称填写。
publicKey contains the public key for which the certificate is being created. This field MUST be filled in if the requestor generates its own key. The field is omitted if the key is generated by the RA/CA.
publicKey包含为其创建证书的公钥。如果请求者生成自己的密钥，则必须填写此字段。如果密钥由RA/CA生成，则省略该字段。
issuerUID MUST be omitted. This field has been deprecated in [PROFILE].
issuerUID必须省略。此字段在[PROFILE]中已被弃用。
subjectUID MUST be omitted. This field has been deprecated in [PROFILE].
必须省略subjectUID。此字段在[PROFILE]中已被弃用。
extensions contains extensions that the requestor wants to have placed in the certificate. These extensions would generally deal with things such as setting the key usage to keyEncipherment.
扩展包含请求者希望在证书中放置的扩展。这些扩展通常会处理诸如将密钥使用设置为密钥加密之类的事情。
With the exception of the publicKey field, the CA/RA is permitted to alter any requested field. The returned certificate needs to be checked by the requestor to see if the fields have been set in an acceptable manner. CA/RA SHOULD use the template fields if possible.
除公钥字段外，CA/RA允许更改任何请求的字段。请求者需要检查返回的证书，以查看字段是否以可接受的方式设置。CA/RA应尽可能使用模板字段。
There are cases where all fields of the template can be omitted. If the key generation is being done at the CA/RA and the identity proof is placed in a different location (such as the id-regCtrl-regToken below), then there are no fields that need to be specified by the certificate requestor.
在某些情况下，模板的所有字段都可以省略。如果密钥生成是在CA/RA上完成的，并且身份证明被放置在不同的位置（例如下面的id regCtrl regToken），那么证书请求者不需要指定任何字段。
The generator of a CertRequest may include one or more control values pertaining to the processing of the request.
CertRequest的生成器可以包括与请求处理相关的一个或多个控制值。
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
The following controls are defined by this document: regToken (section 6.1); authenticator (section 6.2); pkiPublicationInfo (section 6.3); pkiArchiveOptions (section 6.4); oldCertID (section 6.5); protocolEncrKey (section 6.6). Each CRP MUST define the set of controls supported by that protocol. Additional controls may be defined by additional RFCs or by the CRP protocol itself.
本文件定义了以下控制：regToken（第6.1节）；认证人（第6.2节）；PKI发布信息（第6.3节）；PKI架构选项（第6.4节）；oldCertID（第6.5节）；协议密钥（第6.6节）。每个CRP必须定义该协议支持的控制集。附加控制可由附加RFC或CRP协议本身定义。
A regToken control contains one-time information (either based on a secret value or other shared information) intended to be used by the CA to verify the identity of the subject prior to issuing a certificate. Upon receipt of a certification request containing a value for regToken, the receiving CA verifies the information in order to confirm the identity claimed in the certification request.
regToken控件包含一次信息（基于秘密值或其他共享信息），CA打算在颁发证书之前使用该信息来验证主体的身份。接收到包含regToken值的认证请求后，接收CA验证信息，以确认认证请求中声明的身份。
The value for regToken may be generated by the CA and provided out of band to the subscriber, or may otherwise be available to both the CA and the subscriber. The security of any out-of-band exchange should be commensurate with the risk that the CA will tolerate with regard to accepting an intercepted value from someone other than the intended subscriber. The regToken value is not encrypted on return, if the data is considered to be sensitive, it needs to be shrouded by the requestor.
regToken的值可以由CA生成并在带外提供给订阅者，或者可以对CA和订阅者都可用。任何带外交换的安全性应与CA在接受来自预期订户以外的其他人的截获价值时所承受的风险相称。regToken值在返回时未加密，如果数据被视为敏感数据，则需要请求者对其进行屏蔽。
The regToken control is used only for initialization of an end entity into the PKI, whereas the authenticator control (see section 7.2) can be used for the initial as well as subsequent certification requests.
regToken控件仅用于将最终实体初始化到PKI中，而authenticator控件（参见第7.2节）可用于初始和后续认证请求。
In some instances of use the value for regToken could be a text string or a numeric quantity such as a random number. In the latter case, the value is encoded as a text string representation of the binary quantity. The encoding of regToken SHALL be UTF8String.
在某些情况下，regToken的值可以是文本字符串或数字量，如随机数。在后一种情况下，该值被编码为二进制量的文本字符串表示形式。regToken的编码应为UTF8String。
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
Without prior agreement between the subscriber and CA agents, this value would be a textual shared secret of some type. If a computed value based on that shared secret is to be used instead, it is suggested that the CRP define a new registration control for that specific computation.
如果订阅者和CA代理之间没有事先约定，此值将是某种类型的文本共享秘密。如果要使用基于该共享机密的计算值，则建议CRP为该特定计算定义新的注册控制。
An authenticator control contains information used on an ongoing basis to establish a non-cryptographic check of identity in communication with the CA. Examples include: mother's maiden name, last four digits of social security number, or other knowledge-based information shared with the subscriber's CA; a hash of such information; or other information produced for this purpose. The value for an authenticator control may be generated by the subscriber or by the CA.
验证器控件包含持续使用的信息，用于在与CA的通信中建立身份的非加密检查。示例包括：母亲的婚前姓名、社会保险号码的最后四位数字或与订阅者的CA共享的其他基于知识的信息；此类信息的散列；或为此目的提供的其他信息。验证器控件的值可由订阅者或CA生成。
In some instances of use, the value for authenticator could be a text string or a numeric quantity such as a random number. The value in the latter case is encoded as a text string representation of the binary quantity. The encoding of authenticator SHALL be UTF8String.
在某些使用实例中，authenticator的值可以是文本字符串或数字量，如随机数。后一种情况下的值编码为二进制量的文本字符串表示形式。验证器的编码应为UTF8String。
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
When deciding whether to use an authenticator or a regToken, use the following guidelines. If the value is a one-time usage value, then regToken would be used. If the value has a long-term usage, then the authenticator control would be used.
在决定是使用验证器还是使用regToken时，请使用以下准则。如果该值是一次性使用值，则将使用regToken。如果该值具有长期用途，则将使用authenticator控件。
The pkiPublicationInfo control enables subscribers to influence the CA/RA's publication of the certificate. This control is considered advisory and can be ignored by CAs/RAs. It is defined by the following OID and syntax:
pkiPublicationInfo控件使订阅者能够影响CA/RA的证书发布。这种控制被认为是建议性的，可以被CAs/RAs忽略。它由以下OID和语法定义：
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
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 }
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 of PKIPublicationInfo have the following meaning:
PKIPublicationInfo的字段具有以下含义：
action indicates whether or not the requestor wishes the CA/RA to publish the certificate. The values and their means are:
操作指示请求者是否希望CA/RA发布证书。这些数值及其平均值为：
dontPublish indicates that the requester wishes the CA/RA not to publish the certificate (this may indicate that the requester intends to publish the certificate him/herself). If dontPublish is used, the pubInfos field MUST be omitted.
dontPublish表示请求者希望CA/RA不发布证书（这可能表示请求者打算自己发布证书）。如果使用dontPublish，则必须省略pubInfos字段。
pleasePublish indicates that the requestor wishes the CA/RA to publish the certificate.
pleasePublish表示请求者希望CA/RA发布证书。
pubInfos holds the locations where the requestor desires the CA/RA to publish the certificate. This field is omitted if the dontPublish choice is selected. If the requestor wants to specify some locations for the certificate to be published, and to allow the CA/RA to publish in other locations, it would specify multiple values of the SinglePubInfo structure, one of which would be dontCare.
pubInfos保存请求者希望CA/RA发布证书的位置。如果选择了dontPublish选项，则忽略此字段。如果请求者希望为要发布的证书指定一些位置，并允许CA/RA在其他位置发布，它将指定SinglePubInfo结构的多个值，其中一个值将是dontCare。
The fields of SinglePubInfo have the following meaning:
SinglePubInfo的字段具有以下含义：
pubMethod indicates the address type for the location at which the requestor desires the certificate to be placed by the CA/RA.
pubMethod表示请求者希望CA/RA放置证书的位置的地址类型。
dontCare indicates that the CA/RA can publish the certificate in whatever locations it chooses. If dontCare is used, the pubInfos field MUST be omitted.
dontCare表示CA/RA可以在其选择的任何位置发布证书。如果使用dontCare，则必须省略pubInfos字段。
x500 indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the x500 field of pubLocation.
x500表示请求者希望CA/RA在特定位置发布证书。位置显示在pubLocation的x500字段中。
ldap indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the ldap field of pubLocation.
ldap表示请求者希望CA/RA在特定位置发布证书。位置在pubLocation的ldap字段中指示。
web indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the http field of pubLocation.
web表示请求者希望CA/RA在特定位置发布证书。位置在pubLocation的http字段中指示。
pubLocation contains the address at which the certificate is to be placed. The choice in the general name field is dictated by the pubMethod selection in this structure.
pubLocation包含要放置证书的地址。“常规名称”字段中的选择由此结构中的pubMethod选择决定。
Publication locations can be supplied in any order. All locations are to be processed by the CA for purposes of publication.
出版物位置可以按任何顺序提供。CA将处理所有位置，以便发布。
The pkiArchiveOptions control enables subscribers to supply information needed to establish an archive of the private key corresponding to the public key of the certification request. It is defined by the following OID and syntax:
pkiArchiveOptions控件使订阅者能够提供建立与认证请求的公钥对应的私钥存档所需的信息。它由以下OID和语法定义：
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- The use of the EncryptedValue field has been deprecated in favor
-- of the EnvelopedData structure.
--
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- The use of the EncryptedValue field has been deprecated in favor
-- of the EnvelopedData structure.
--
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
KeyGenParameters ::= OCTET STRING
The fields of PKIArchiveOptions have the following meaning:
PKIArchiveOptions字段具有以下含义：
encryptedPrivKey contains an encrypted version of the private key.
encryptedPrivKey包含私钥的加密版本。
keyGenParameters contains the information needed by the requestor to regenerate the private key. As an example, for many RSA implementations one could send the first random number(s) tested for primality. The structure to go here is not defined by this document. CRPs that define content for this structure MUST define not only the content that is to go here, but also how that data is shrouded from unauthorized access.
keyGenParameters包含请求者重新生成私钥所需的信息。例如，对于许多RSA实现，可以发送第一个经过素性测试的随机数。本文档未定义此处的结构。为该结构定义内容的CRP不仅必须定义要放在此处的内容，还必须定义如何保护数据不被未经授权的访问。
archiveRemGenPrivKey indicates that the requestor desires that the key generated by the CA/RA on the requestor's behalf be archived.
archiveRemGenPrivKey表示请求者希望CA/RA代表请求者生成的密钥被存档。
The fields of EncryptedKey have the following meaning:
EncryptedKey字段具有以下含义：
encryptedValue is longer used. This field has been deprecated along with the EncryptedValue structure.
encryptedValue已不再使用。此字段与EncryptedValue结构一起被弃用。
envelopedData contains the encrypted value of the private key. CPRs that use this structure MUST define the entity or entities for whom the data is to be encrypted (the EE, escrow agents, CAs) and how that key or set of keys is to be determined. Details on constructing an EnvelopedData structure are found in [CMS]. The encrypted content MUST be an id-ct-encKeyWithID. The identifier can be omitted unless this structure is also being used to do proof-of-possession.
envelopedData包含私钥的加密值。使用此结构的CPR必须定义要为其加密数据的一个或多个实体（EE、托管代理、CA）以及如何确定该密钥或密钥集。有关构造EnvelopedData结构的详细信息，请参见[CMS]。加密的内容必须是id ct encKeyWithID。标识符可以省略，除非此结构也用于证明占有。
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The OID and syntax is:
如果存在，OldCertID控件指定要由当前证书请求更新的证书。OID和语法为：
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
If present, the protocolEncrKey control specifies a key that the CA is to use in encrypting a response to CertReqMessages. The OID for this control is id-regCtrl-protocolEncrKey. The parameter structure for this field is SubjectPublicKeyInfo. (This structure is defined in [PROFILE].)
如果存在，ProtocolEncKey控件指定CA用于加密对CertReqMessages的响应的密钥。此控件的OID是id REGCRL protocolEncrKey。此字段的参数结构为SubjectPublicKeyInfo。（此结构在[PROFILE]中定义。）
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
This control is used when a CA has information to send to the subscriber that needs to be encrypted. Such information includes a private key generated by the CA for use by the subscriber.
当CA有需要加密的信息发送给订阅服务器时，使用此控件。此类信息包括由CA生成供订户使用的私钥。
This section documents the controls that are to be placed in the regInfo field of the CertReqMsg structure.
本节记录了要放置在CertReqMsg结构的regInfo字段中的控件。
This control is used to convey text-based information from the Subject to an RA to a CA issuing a certificate. The OID for this structure is id-regInfo-utf8Paris and has a type of UTF8String.
此控件用于将基于文本的信息从主体传送到RA，再传送到颁发证书的CA。此结构的OID为id-regInfo-utf8Paris，其类型为UTF8String。
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
The name is terminated by the question mark character ('?'). The value is terminated by the percent character '%'. Name value pairs can be repeated. Thus the syntax is:
名称以问号字符（“？”）结尾。该值以百分比字符“%”结尾。名称-值对可以重复。因此，语法是：
Name?Value%[Name?Value%]*
名称？值%[名称？值%]*
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character.
[RFC1738]的%xx机制用于对“？”（%3f）和“%”（%25）进行编码（如果它们不是用于保留目的）。名称不能以数字字符开头。
This control can appear multiple times in the regInfo structure. Resolution of conflicts of information is a matter of local policy on the RA/CA.
此控件可以在regInfo结构中出现多次。解决信息冲突是当地RA/CA政策的一个问题。
Appendix A contains a set of common names and data formats corresponding to fields that commonly appear in certificates and directories.
附录A包含一组常见名称和数据格式，对应于证书和目录中常见的字段。
This control is designed to deal with the problem where an RA needs to modify the certificate template proposed by a Subject, but the Subject used the certificate template as part of its POP calculation. In this case, the RA can place a new certificate template in the regInfo sequence.
此控件旨在处理RA需要修改受试者建议的证书模板，但受试者将证书模板用作其POP计算的一部分的问题。在这种情况下，RA可以在regInfo序列中放置新的证书模板。
This control has the OID id-regInfo-certReq and the structure CertRequest. There can only be one instance of this attribute in the regInfo sequence. If this control exists in the regInfo structure, then the certificate template in the request is ignored. The RA MUST copy all data from the core template to this attribute.
此控件具有OID id regInfo certReq和结构CertRequest。在regInfo序列中，此属性只能有一个实例。如果此控件存在于regInfo结构中，则忽略请求中的证书模板。RA必须将核心模板中的所有数据复制到此属性。
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
The OID id-pkix has the value
OID id pkix具有以下值：
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) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
-- arc for Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
-- arc for Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
-- arc for Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
Enrollment protocols, by their very nature, involve large amounts of private information. This can include private keys, identity numbers, credit card numbers, and the like. The security of any CRP is based on the security mechanisms of the protocol and/or process used to communicate between CAs, RAs and EEs. All protocols must provide for masking, either via encryption or off-line processing, of all subscriber-sensitive information.
注册协议本质上涉及大量的私有信息。这可以包括私钥、身份证号码、信用卡号码等。任何CRP的安全性都基于用于CAs、RAs和EEs之间通信的协议和/或流程的安全机制。所有协议必须通过加密或离线处理对所有订户敏感信息进行屏蔽。
Many enrollment protocols provide for the initial establishment of identity between the CA/RA and the EE by the use of a token. Generally this token is delivered using an out-of-band delivery method (such as the governmental mail system). The security of any out-of-band exchange needs to be commensurate with the risk that the CA/RA will tolerate with regard to interception of the token by a third party.
许多注册协议通过使用令牌在CA/RA和EE之间提供初始身份建立。通常，使用带外交付方法（如政府邮件系统）交付此令牌。任何带外交换的安全性需要与CA/RA在第三方拦截代币方面所承受的风险相称。
Implementation must implement Proof-of-Possession (POP) values during certificate enrollment processes. A good POP algorithm needs to provide proof of two things: 1) that the key is tied to a specific user and 2) that the user has use of the key in question. Failure to implement POP allows people to create certificates where the public key and the name values do not correctly bind. This allows for impersonation on signature keys and interception of encrypted messages.
实现必须在证书注册过程中实现占有证明（POP）值。一个好的POP算法需要证明两件事：1）密钥与特定用户绑定，2）用户使用了有问题的密钥。未能实现POP允许用户创建公钥和名称值未正确绑定的证书。这允许模拟签名密钥和拦截加密消息。
Implementations must use high entropy random number generators in producing private keys. Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), salt, and padding. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
实现必须使用高熵随机数生成器来生成私钥。实现必须随机生成内容加密密钥、消息身份验证密钥、初始化向量（IVs）、salt和填充。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境、搜索生成的一小部分可能性比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 4086[RANDOM]在这方面提供了重要的指导，FIPS Pub 186[DSS]的附录3提供了一种高质量的PRNG技术。
Implementations must protect private keys. The compromise of a signer's private key permits third parties to masquerade as the signer. The compromise of a decryption private key allows for interception of messages by a third party.
实现必须保护私钥。签名者私钥的泄露允许第三方伪装成签名者。解密私钥的泄露允许第三方截取消息。
One feature of the certificate message request syntax is for the key generation to be performed remotely from the creation of the certificate request. This feature should never be used for generation of signing keys. If signing keys are generated for the user, then an element of repudiation comes into play. The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator the to EE. Care must be taken to protect encryption keys by the remote key generator to protect against interception of the keys by a third party. This means that the encryption algorithms used need to be secure, and a content encryption key or a key encryption key must be used to mask the private key during transport back to the user. CRP protocols must never assume that a signature key generated by the user can be used to decrypt the package in which an encryption private key is transported.
证书消息请求语法的一个特性是，密钥生成可以在创建证书请求时远程执行。此功能不应用于生成签名密钥。如果为用户生成了签名密钥，那么一个拒绝元素就起作用了。用户可以声明某个项是由生成密钥的实体以及在从生成器传输到EE期间可能看到密钥值的任何实体签名的。远程密钥生成器必须小心保护加密密钥，以防止第三方截获密钥。这意味着所使用的加密算法需要是安全的，并且在传输回用户期间必须使用内容加密密钥或密钥加密密钥来屏蔽私钥。CRP协议决不能假定用户生成的签名密钥可用于解密传输加密私钥的包。
This document describes a method by which key escrow may be done. There are several issues that need to be taken into account when doing key escrow. First, the client must be able to correctly identify the entity to which a key is to be escrowed or the CRP must provide a method by which the client can discover this information. A CRP cannot assume that the key escrow agent and the CA are the same entity and thus have the same names. Second, the algorithms used to mask the private key or other key generation information during transport to the escrow agent need to be commensurate with the value of the data being protected by the key. Third, the escrow agent needs to provide sufficient safeguards that an escrowed key is returned only to entities that should be able to obtain the private key. Generally, this should be restricted to the entity that escrowed the data. Fourth, the escrow data base needs to be stored in a secure manner. One common method for doing this is to re-encrypt the data to keys that only the escrow agent has access to. In this case, one may need to escrow the escrow agent key as well. Access to either the escrow agent or the archived key would amount to access to all private keys that have been escrowed with that agent.
本文档描述了密钥托管的一种方法。在进行密钥托管时，需要考虑几个问题。首先，客户机必须能够正确识别要托管密钥的实体，或者CRP必须提供客户机可以发现此信息的方法。CRP不能假设密钥托管代理和CA是同一实体，因此具有相同的名称。其次，用于在传输到托管代理期间屏蔽私钥或其他密钥生成信息的算法需要与密钥保护的数据的价值相称。第三，托管代理需要提供足够的保障措施，确保托管密钥仅返回给应该能够获得私钥的实体。一般来说，这应限于托管数据的实体。第四，托管数据库需要以安全的方式存储。执行此操作的一种常见方法是将数据重新加密为只有托管代理才能访问的密钥。在这种情况下，可能还需要托管托管代理密钥。对托管代理或存档密钥的访问将相当于对该代理托管的所有私钥的访问。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA Security Inc., June 2001.
[PKCS11]RSA实验室，公钥加密标准-“PKCS#11 v2.11：加密令牌接口标准”，RSA Security Inc.，2001年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[简介]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 32802002年4月。
[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[PKIXALG]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, July 2000.
[RFC2875]Prafullchandra，H.和J.Schaad，“Diffie-Hellman占有算法证明”，RFC 28752000年7月。
[DSS] National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard, May 1994.
[DSS]国家标准与技术研究所，FIPS Pub 186：数字签名标准，1994年5月。
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS #8 v1.2, November 1993.
[PKCS8]RSA实验室，“PKCS#8：私钥信息语法标准”，PKCS#8 v1.2，1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202]Cheng，P.和R.Glenn，“HMAC-MD5和HMAC-SHA-1的测试案例”，RFC 2202，1997年9月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
The working group would like to thank Michael Myers, Carlisle Adams, Dave Solo, and David Kemp, who authored the original version of this document.
工作组要感谢迈克尔·迈尔斯、卡莱尔·亚当斯、戴夫·索洛和大卫·肯普，他们编写了本文件的原始版本。
The working group also gratefully acknowledges the contributions of Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose review and comments significantly clarified and improved the utility of this specification. The members of the ca-talk mailing list also provided significant input with respect to interoperability testing.
工作组还感谢Barbara Fox、Warwick Ford、Russ Housley和John Pawling的贡献，他们的审查和评论极大地澄清和改进了本规范的实用性。ca talk邮件列表的成员还提供了有关互操作性测试的重要信息。
The text of Appendix C (Why do POP) was taken from an e-mail message by Al Arsenault and was originally part of the PKIX Roadmap document.
附录C（为什么要POP）的文本取自Al Arsenault的一封电子邮件，最初是PKIX路线图文件的一部分。
The "value" field of the id-regInfo-utf8Pairs string (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF-8 name/value pairs.
id-regInfo-utf8Pairs字符串的“值”字段（标记字段等于12，适当的“长度”字段）将包含一系列UTF-8名称/值对。
This Appendix lists some common examples of such pairs for the purpose of promoting interoperability among independent implementations of this specification. It is recognized that this list is not exhaustive and will grow with time and implementation experience.
本附录列出了此类配对的一些常见示例，以促进本规范独立实现之间的互操作性。人们认识到，该列表并非详尽无遗，并将随着时间和实施经验的增长而增长。
The following table defines a recommended set of named elements. The value in the column "Name Value" is the exact text string that will appear in the regInfo.
下表定义了一组推荐的命名元素。“名称值”列中的值是将显示在regInfo中的精确文本字符串。
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber's email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber's email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
For example:
例如：
version?1%corp_company?Example, Inc.%org_unit?Engineering% mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% mail_email?john@example.com%
版本？1%corp\u company？例如，Inc.%org\u unit？工程%mail\u firstName？约翰%mail\u lastName？史密斯%jobTitle？团队负责人%mail\u email？john@example.com%
When they appear in id-regInfo-utf8Pairs syntax as named elements,
the encoding of values for issuerName, subjectName, and validity
SHALL use the following syntax. The characters [] indicate an
optional field, ::= and | have their usual BNF meanings, and all
other symbols (except spaces, which are insignificant) outside non-
terminal names are terminals. Alphabetics are case-sensitive.
When they appear in id-regInfo-utf8Pairs syntax as named elements,
the encoding of values for issuerName, subjectName, and validity
SHALL use the following syntax. The characters [] indicate an
optional field, ::= and | have their usual BNF meanings, and all
other symbols (except spaces, which are insignificant) outside non-
terminal names are terminals. Alphabetics are case-sensitive.
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>
<notbefore> ::= <time>
<notafter> ::= <time>
Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM, and SS default to 00 and are omitted if at the and of value 00.
其中<time>是UTC时间，格式为YYYYMMDD[HH[MM[SS]]。HH、MM和SS默认为00，如果和的值为00，则省略。
Example validity encoding:
有效性编码示例：
validity?-19991231%
有效期？-19991231%
is a validity interval with no value for notBefore, and a value of December 31, 1999 for notAfter.
是有效期间隔，notBefore没有值，notAfter的值为1999年12月31日。
Each name comprises a single character name form identifier, followed by a name value of one or more UTF-8 characters. Within a name value, when it is necessary to disambiguate a character that has formatting significance at an outer level, the escape sequence %xx SHALL be used, where xx represents the hex value for the encoding concerned. The percent symbol is represented by %%.
每个名称包含一个单字符名称表单标识符，后跟一个或多个UTF-8字符的名称值。在名称值中，当需要消除在外部级别具有格式重要性的字符的歧义时，应使用转义序列%xx，其中xx表示相关编码的十六进制值。百分比符号用%%表示。
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
Name forms and value formats are as follows:
名称格式和值格式如下所示：
X.500 directory name form (identifier "X"):
X.500目录名称表（标识符“X”）：
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>
Standard attribute type <stdat> is an alphabetic attribute type identifier from the following set:
标准属性类型<stdat>是以下集合中的字母属性类型标识符：
C (country) L (locality) ST (state or province) O (organization) OU (organizational unit) CN (common name) STREET (street address) E (E-mail address).
C（国家）L（地区）ST（州或省）O（组织）OU（组织单位）CN（通用名称）街道（街道地址）E（电子邮件地址）。
<avalue> is a name component in the form of a UTF-8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF-8 only the characters of ASN.1 PrintableString may be used.
<avalue>是一个名称组件，其形式为1到64个字符的UTF-8字符串，限制是在UTF-8的IA5子集中只能使用ASN.1可打印字符串的字符。
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
IP address (identifier "I"):
<iname> ::= <oid>
IP address (identifier "I"):
<iname> ::= <oid>
For example:
例如：
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
O=Example, C=US, E=john@example.com%
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
O=Example, C=US, E=john@example.com%
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} -- found in [PROFILE]
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} -- found in [PROFILE]
-- Certificate Extensions (X.509)
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} -- found in [PROFILE]
-- Certificate Extensions (X.509)
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} -- found in [PROFILE]
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24) }; -- found in [CMS]
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24) }; -- found in [CMS]
-- The following definition may be uncommented for use with
-- ASN.1 compilers that do not understand UTF8String.
-- The following definition may be uncommented for use with
-- ASN.1 compilers that do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
-- arc for Internet X.509 PKI protocols and their components
--Internet X.509 PKI协议及其组件的arc
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
-- Core definitions for this module
--本模块的核心定义
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
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 }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } -- at least one MUST be present
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } -- at least one MUST be present
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed over the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain both the
-- public key and subject values (i.e., if it contains only one
-- of these, or neither), then poposkInput MUST be present and
-- MUST be signed.
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed over the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain both the
-- public key and subject values (i.e., if it contains only one
-- of these, or neither), then poposkInput MUST be present and
-- MUST be signed.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [HMAC, RFC2202])
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [HMAC, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- Deprecated
-- possession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING, -- Deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- Deprecated
-- possession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING, -- Deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which MUST include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which MUST include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
-- Object identifier assignments --
--对象标识符分配--
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
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)
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)
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 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters that allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters that allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- Deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- Deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
KeyGenParameters ::= OCTET STRING
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
-- id-ct-encKeyWithID is a new content type used for CMS objects.
-- it contains both a private key and an identifier for key escrow
-- agents to check against recovery requestors.
-- id-ct-encKeyWithID is a new content type used for CMS objects.
-- it contains both a private key and an identifier for key escrow
-- agents to check against recovery requestors.
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
Attributes ::= SET OF Attribute
Attributes ::= SET OF Attribute
END
终止
Appendix C. Why do Proof-of-Possession (POP)
附录C.为什么要使用占有证明（POP）
Proof-of-Possession, or POP, means that the CA is adequately convinced that the entity requesting a certificate for the public key Y, has access to the corresponding private key X.
占有证明，即POP，意味着CA充分确信请求公钥Y证书的实体可以访问相应的私钥X。
POP is important because it provides an appropriate level of assurance of the correct operation of the PKI as a whole. At its lowest level, POP counters the "self-inflicted denial of service"; that is, an entity voluntarily gets a certificate that cannot be used to sign or encrypt/decrypt information. However, as the following two examples demonstrate, POP also counters less direct, but more severe, threats:
POP很重要，因为它为整个PKI的正确运行提供了适当的保证。在最低级别，POP反击“自我造成的拒绝服务”；也就是说，一个实体自愿获得一个不能用于签名或加密/解密信息的证书。但是，正如以下两个示例所示，POP还应对不太直接但更严重的威胁：
POP for signing keys: it is important to provide POP for keys used to sign material, in order to provide non-repudiation of transactions. For example, suppose Alice legitimately has private key X and its corresponding public key Y. Alice has a certificate from Charlie, a CA, containing Y. Alice uses X to sign a transaction T. Without POP, Mal could also get a certificate from Charlie containing the same public key, Y. Now, there are two possible threats: Mal could claim to have been the real signer of T; or Alice can falsely deny signing T, claiming that it was instead Mal. Since no one can reliably prove that Mal did or did not ever possess X, neither of these claims can be refuted, and thus the service provided by and the confidence in the PKI has been defeated. (Of course, if Mal really did possess X, Alice's private key, then no POP mechanism in the world will help, but that is a different problem.)
用于签名密钥的POP：为用于签名材料的密钥提供POP非常重要，以便提供交易的不可否认性。例如，假设Alice合法地拥有私钥X及其相应的公钥Y。Alice拥有来自CA Charlie的证书，其中包含Y。Alice使用X签署事务T。如果没有POP，Mal也可以从Charlie处获得包含相同公钥Y的证书。现在，有两种可能的威胁：马尔可能声称自己是T的真正签署者；或者Alice可以错误地否认签名T，声称它是Mal。由于没有人能够可靠地证明Mal曾经拥有或从未拥有X，这些说法都无法反驳，因此PKI提供的服务和对PKI的信任都被击败。（当然，如果Mal真的拥有Alice的私钥X，那么世界上没有任何POP机制会有帮助，但这是另一个问题。）
Note that one level of protection can be gained by having Alice (as the true signer of the transaction) include in the signed information, her certificate or an identifier of her certificate (e.g., a hash of her certificate). This might make it more difficult for Mal to claim authorship; he would have to assert that he incorrectly included Alice's certificate, rather than his own. However, it would not stop Alice from falsely repudiating her actions. Since the certificate itself is a public item, Mal indeed could have inserted Alice's certificate or identifier into the signed transaction, and thus its presence does not indicate that Alice was the one who participated in the now-repudiated transaction. The only reliable way to stop this attack is to require that Mal prove he possesses X before his certificate is issued.
请注意，通过让Alice（作为交易的真正签名者）在签名信息中包含她的证书或证书的标识符（例如，她的证书的散列），可以获得一个级别的保护。这可能使Mal更难声称其作者身份；他将不得不断言，他错误地包括了爱丽丝的证书，而不是他自己的证书。然而，这并不能阻止爱丽丝错误地否定她的行为。由于证书本身是一个公共项目，Mal确实可以将Alice的证书或标识符插入已签署的交易，因此其存在并不表明Alice是参与现已被拒绝的交易的人。阻止此攻击的唯一可靠方法是要求Mal在颁发证书之前证明他拥有X。
For signing keys used only for authentication, and not for non-repudiation, the threat is lower because users may not care about Alice's after-the-fact repudiation, and thus POP becomes less important. However, POP SHOULD still be done wherever feasible in this environment, by either off-line or on-line means.
对于仅用于身份验证而不用于不可抵赖性的签名密钥，威胁更低，因为用户可能不关心Alice的事后抵赖，因此POP变得不那么重要。然而，在这种环境下，只要可行，POP仍应通过离线或在线方式进行。
POP for key management keys: Similarly, POP for key management keys (that is, keys used for either key agreement or key exchange) can help to prevent undermining confidence in the PKI. Suppose that Al is a new instructor in the Computer Science Department of a local university. Al has created a draft final exam for the Introduction to Networking course he is teaching. He wants to send a copy of the draft final to Dorothy, the Department Head, for her review prior to giving the exam. This exam will of course be encrypted, as several students have access to the computer system. However, a quick search of the certificate repository (e.g., search the repository for all records with subjectPublicKey=Dorothy's-value) turns up the fact that several students have certificates containing the same public key management key as Dorothy. At this point, if no POP has been done by the CA, Al has no way of knowing whether all of the students have simply created these certificates without knowing the corresponding private key (and thus it is safe to send the encrypted exam to Dorothy), or whether the students have somehow acquired Dorothy's private key (and thus it is certainly not safe to send the exam). Thus, the service to be provided by the PKI allowing users to communicate with one another, with confidence in who they are communicating with, has been totally defeated. If the CA is providing POP, then either no students will have such certificates, or Al can know with certainty that the students do indeed know Dorothy's private key, and act accordingly.
POP用于密钥管理密钥：同样，POP用于密钥管理密钥（即用于密钥协议或密钥交换的密钥）有助于防止破坏PKI的信心。假设艾尔是当地一所大学计算机科学系的新教员。艾尔已经为他所教授的网络入门课程起草了期末考试初稿。他想在考试前把期末考试草稿的副本寄给系主任多萝西，让她审阅。这个考试当然会加密，因为有几个学生可以访问计算机系统。但是，快速搜索证书存储库（例如，在存储库中搜索subjectPublicKey=Dorothy's-value的所有记录）会发现一个事实，即几个学生的证书包含与Dorothy相同的公钥管理密钥。在这一点上，如果CA没有进行POP，Al无法知道是否所有学生只是在不知道相应私钥的情况下创建了这些证书（因此将加密的考试发送给Dorothy是安全的），或者学生是否以某种方式获得了Dorothy的私钥（因此发送考试肯定不安全）。因此，PKI将提供的允许用户相互通信的服务完全失败了。如果CA提供POP，那么要么没有学生拥有此类证书，要么Al可以肯定地知道学生确实知道Dorothy的私钥，并采取行动相应地。
Author's Address
作者地址
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Smalling Hawk咨询公司华盛顿金条675号邮政信箱98251
EMail: jimsch@exmsft.com
EMail: jimsch@exmsft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。