Network Working Group M. Myers
Request for Comments: 2511 VeriSign
Category: Standards Track C. Adams
Entrust Technologies
D. Solo
Citicorp
D. Kemp
DoD
March 1999
Network Working Group M. Myers
Request for Comments: 2511 VeriSign
Category: Standards Track C. Adams
Entrust Technologies
D. Solo
Citicorp
D. Kemp
DoD
March 1999
Internet X.509 Certificate Request Message Format
Internet X.509证书请求消息格式
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document describes the Certificate Request Message Format (CRMF). 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 associated registration information.
本文档介绍证书请求消息格式（CRMF）。此语法用于将证书请求传递给证书颁发机构（CA）（可能通过注册机构（RA））以生成X.509证书。请求通常包括公钥和相关的注册信息。
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.
本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”（大写，如图所示）应按照RFC 2119中的说明进行解释。
Construction of a certification request involves the following steps:
构建认证请求涉及以下步骤：
a) A CertRequest value is constructed. This value may include the public key, all or a portion of the end-entity's (EE's) name, other requested certificate fields, and additional control information related to the registration process.
a) 构造一个CertRequest值。该值可能包括公钥、终端实体（EE）的全部或部分名称、其他请求的证书字段以及与注册过程相关的附加控制信息。
b) A proof of possession (of the private key corresponding to the public key for which a certificate is being requested) value may be calculated across the CertRequest value.
b) 可以跨CertRequest值计算占有证明（与请求证书的公钥相对应的私钥）值。
c) Additional registration information may be combined with the proof of possession value and the CertRequest structure to form a CertReqMessage.
c) 附加的注册信息可以与占有价值证明和CertRequest结构相结合，形成CertReqMessage。
d) The CertReqMessage is securely communicated to a CA. Specific means of secure transport are beyond the scope of this specification.
d) CertReqMessage被安全地传送到CA。特定的安全传输方式超出了本规范的范围。
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,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
The proof of possession field is used to demonstrate that the entity to be associated with the certificate is actually in possession of the corresponding private key. This field may be calculated across the contents of the certReq field and varies in structure and content by public key algorithm type and operational mode.
“拥有证明”字段用于证明与证书关联的实体实际拥有相应的私钥。该字段可以跨certReq字段的内容进行计算，其结构和内容因公钥算法类型和操作模式而异。
The regInfo field SHOULD only contain supplementary information related to the context of the certification request when such information is required to fulfill a certification request. This information MAY include subscriber contact information, billing information or other ancillary information useful to fulfillment of the certification request.
当满足认证请求需要与认证请求上下文相关的补充信息时，regInfo字段应仅包含这些信息。该信息可包括订户联系信息、计费信息或对实现认证请求有用的其他辅助信息。
Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs may invalidate the pop field. Data therefore intended for certificate content MAY be provided in regInfo.
certReq内容中应包含与证书内容直接相关的信息。但是，RAs包含额外的certReq内容可能会使pop字段无效。因此，可在regInfo中提供用于证书内容的数据。
See Section 8 and Appendix B for example regInfo contents.
regInfo内容示例见第8节和附录B。
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA 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 (i.e., this may be a policy issue). However, it is MANDATED that CAs/RAs MUST enforce POP by some means because 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 can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful.
为了防止某些攻击并允许CA/RA正确检查终端实体和密钥对之间绑定的有效性，此处指定的PKI管理操作使终端实体能够证明其拥有（即能够使用）与请求证书的公钥相对应的私钥。给定CA/RA可自由选择如何在其认证交换中强制执行POP（例如，带外程序手段与CRMF带内消息）（即，这可能是一个政策问题）。然而，CAs/RAs必须通过某种方式强制执行POP，因为目前使用的许多非PKIX操作协议（各种电子邮件协议就是一个例子）没有明确检查终端实体和私钥之间的绑定。在验证绑定（用于签名、加密和密钥协议密钥对）的操作协议存在并普遍存在之前，只能假设该绑定已由CA/RA验证。因此，如果绑定未经CA/RA验证，则Internet公钥基础设施中的证书的意义将有所降低。
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., an RSA key) then any of the methods MAY be used.
根据请求证书的密钥类型，POP以不同的方式完成。如果一个密钥可用于多种目的（例如RSA密钥），则可以使用任何方法。
This specification allows for cases where POP is validated by the CA, the RA, or both. Some policies may require the CA to verify POP during certification, in which case the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA, and as an option MAY also verify POP. 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 MAY attest to the CA that the required proof has been validated. If the CA uses an out-of-band method to verify POP (such as physical delivery of CA-generated private keys), then the ProofOfPossession field is not used.
本规范允许由CA、RA或两者验证POP的情况。某些策略可能要求CA在认证期间验证POP，在这种情况下，RA必须将终端实体的CertRequest和ProvofPassession字段未经更改转发给CA，并且作为一种选项，还可以验证POP。如果政策不要求CA验证POP，则RA应如上所述将最终实体的请求和证明转发给CA。如果这是不可能的（例如，因为RA通过带外方法验证POP），则RA可以向CA证明所需证明已经验证。如果CA使用带外方法验证POP（如物理传递CA生成的私钥），则不使用ProofPassession字段。
For signature keys, the end entity can sign a value to prove possession of the private key.
对于签名密钥，终端实体可以签署一个值来证明拥有私钥。
For key encipherment keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly or indirectly.
对于密钥加密密钥，终端实体可以向CA/RA提供私钥，或者可以被要求解密值以证明私钥的拥有。解密值可以直接或间接实现。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the end entity is required.
直接方法是RA/CA发出随机质询，要求终端实体立即响应。
The indirect method is to issue a certificate which is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in a confirmation message). This allows a CA to issue a certificate in a form which can only be used by the intended end entity.
间接方法是颁发为最终实体加密的证书（并让最终实体在确认消息中演示其解密该证书的能力）。这允许CA以只能由预期的最终实体使用的形式颁发证书。
For key agreement keys, the end entity can use any of the three methods given in Section 5.2 for encryption keys. For the direct and indirect methods, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key (i.e., in order to decrypt the encrypted certificate or to construct the response to the issued challenge). Note that this need not impose any restrictions on the keys that can be certified by a given CA -- in particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters -- provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
对于密钥协议密钥，终端实体可以使用第5.2节中给出的加密密钥的三种方法中的任何一种。对于直接和间接方法，终端实体和PKI管理实体（即CA或RA）必须建立共享密钥，以证明终端实体拥有私钥（即，以解密加密证书或构造对发出的质询的响应）。注意，这不需要对可由给定CA认证的密钥施加任何限制——特别是对于Diffie-Hellman密钥，终端实体可以自由选择其算法参数——前提是CA可以在必要时生成具有适当参数的短期（或一次性）密钥对。
The end entity may also MAC the certificate request (using a shared secret key derived from a Diffie-Hellman computation) as a fourth alternative for demonstrating POP. This option may be used only if the CA already has a DH certificate that is known to the end entity and if the EE is willing to use the CA's DH parameters.
终端实体还可以MAC证书请求（使用从Diffie-Hellman计算派生的共享密钥）作为演示POP的第四备选方案。仅当CA已经拥有终端实体已知的DH证书并且EE愿意使用CA的DH参数时，才可以使用此选项。
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,
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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
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,
-- the algorithm value shall be PasswordBasedMac
-- {1 2 840 113533 7 66 13}
-- the parameter value is PBMParameter
value BIT STRING }
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- the algorithm value shall be PasswordBasedMac
-- {1 2 840 113533 7 66 13}
-- the parameter value is PBMParameter
value BIT STRING }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
SubsequentMessage ::= INTEGER {
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/RA engage in challenge-response exchange with
-- end entity in order to prove private key possession
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/RA engage in challenge-response exchange with
-- end entity in order to prove private key possession
It is expected that protocols which incorporate this specification will include the confirmation and challenge-response messages necessary to a complete protocol.
预计包含本规范的协议将包括完整协议所需的确认和质询响应消息。
The following algorithm SHALL be used when publicKeyMAC is used in POPOSigningKeyInput to prove the authenticity of a request.
当publicKeyMAC用于POPOSigningKeyInput以证明请求的真实性时，应使用以下算法。
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 [RFC2104, 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 [RFC2104, RFC2202])
The process of using PBMParameter to compute publicKeyMAC and so authenticate the origin of a public key certification request consists of two stages. The first stage uses shared secret information to produce a MAC key. The second stage MACs the public key in question using this MAC key to produce an authenticated value.
使用PBMParameter计算publicKeyMAC并验证公钥认证请求的来源的过程包括两个阶段。第一阶段使用共享的秘密信息生成MAC密钥。第二阶段MAC使用该MAC密钥来生成经过身份验证的值，从而对所讨论的公钥进行MAC。
Initialization of the first stage of algorithm assumes the existence of a shared secret distributed in a trusted fashion between CA/RA and end-entity. The salt value is appended to the shared secret and the one way function (owf) is applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration, yielding a key K.
算法第一阶段的初始化假设CA/RA和终端实体之间存在以可信方式分发的共享秘密。salt值被附加到共享密钥，单向函数（owf）被应用迭代计数次，其中salt密钥是第一次迭代的输入，对于每个后续迭代，输入被设置为前一次迭代的输出，产生密钥K。
In the second stage, K and the public key are inputs to HMAC as documented in [HMAC] to produce a value for publicKeyMAC as follows:
在第二阶段中，K和公钥是HMAC的输入，如[HMAC]中所述，以产生publicKeyMAC的值，如下所示：
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
where ipad and opad are defined in [RFC2104].
其中[RFC2104]中定义了ipad和opad。
The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
owf的算法标识符应为SHA-1{1 3 14 3 2 26}，mac的算法标识符应为HMAC-SHA1{1 3 6 1 5 8 1 2}。
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 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 (it is recognized that this list may expand over time): regToken; authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; protocolEncrKey.
定义了以下控件（认识到此列表可能会随时间扩展）：regToken；验证者；PKI发布信息；公共钥匙基础设施选择；旧证书；原密码匙。
A regToken control contains one-time information (either based on a secret value or on knowledge) 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 of the CA accepting an intercepted value from someone other than the intended subscriber.
regToken的值可以由CA生成并在带外提供给订阅者，或者可以对CA和订阅者都可用。任何带外交换的安全性都应与CA接受预期订户以外的其他人截获的价值的风险相称。
The regToken control would typically be used only for initialization of an end entity into the PKI, whereas the authenticator control (see Section 7.2) would typically be used for 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. The value in the latter case could be encoded either as a binary quantity or as a text string representation of the binary quantity. To ensure a uniform encoding of values regardless of the nature of the quantity, the encoding of regToken SHALL be UTF8.
在某些情况下，regToken的值可以是文本字符串或数字量，如随机数。后一种情况下的值可以编码为二进制量或二进制量的文本字符串表示形式。为确保数值的统一编码，无论数量的性质如何，regToken的编码应为UTF8。
6.2 Authenticator Control.
6.2 验证器控件。
An authenticator control contains information used in 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 regToken could be a text string or a numeric quantity such as a random number. The value in the latter case could be encoded either as a binary quantity or as a text string representation of the binary quantity. To ensure a uniform encoding of values regardless of the nature of the quantity, the encoding of authenticator SHALL be UTF8.
在某些情况下，regToken的值可以是文本字符串或数字量，如随机数。后一种情况下的值可以编码为二进制量或二进制量的文本字符串表示形式。为了确保数值的统一编码，无论数量的性质如何，验证器的编码应为UTF8。
The pkiPublicationInfo control enables subscribers to control the CA's publication of the certificate. It is defined by the following syntax:
pkiPublicationInfo控件使订阅者能够控制CA的证书发布。它由以下语法定义：
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
If the dontPublish option is chosen, the requester indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate him/herself).
如果选择了dontPublish选项，则请求者表示PKI不应发布证书（这可能表示请求者打算自己发布证书）。
If the dontCare method is chosen, or if the PKIPublicationInfo control is omitted from the request, the requester indicates that the PKI MAY publish the certificate using whatever means it chooses.
如果选择了dontCare方法，或者如果请求中省略了PKIPublicationInfo控件，则请求者表示PKI可以使用其选择的任何方式发布证书。
If the requester wishes the certificate to appear in at least some locations but wishes to enable the CA to make the certificate available in other repositories, set two values of SinglePubInfo for pubInfos: one with x500, web or ldap value and one with dontCare.
如果请求者希望证书至少出现在某些位置，但希望使CA能够使证书在其他存储库中可用，请为pubInfos设置两个SinglePubInfo值：一个为x500、web或ldap值，另一个为dontCare。
The pubLocation field, if supplied, indicates where the requester would like the certificate to be found (note that the CHOICE within GeneralName includes a URL and an IP address, for example).
pubLocation字段（如果提供）指示请求者希望在何处找到证书（请注意，GeneralName中的选项包括URL和IP地址，例如）。
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 syntax:
pkiArchiveOptions控件使订阅者能够提供建立与认证请求的公钥对应的私钥存档所需的信息。它由以下语法定义：
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 which 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 which the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
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 }
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 }
KeyGenParameters ::= OCTET STRING
KeyGenParameters ::= OCTET STRING
An alternative to sending the key is to send the information about how to re-generate the key using the KeyGenParameters choice (e.g., for many RSA implementations one could send the first random numbers tested for primality). The actual syntax for this parameter may be defined in a subsequent version of this document or in another standard.
发送密钥的另一种方法是发送有关如何使用KeyGenParameters选项重新生成密钥的信息（例如，对于许多RSA实现，可以发送第一个经过素性测试的随机数）。此参数的实际语法可在本文档的后续版本或其他标准中定义。
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The syntax of its value is:
如果存在，OldCertID控件指定要由当前证书请求更新的证书。其值的语法为：
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
If present, the protocolEncrKey control specifies a key the CA is to use in encrypting a response to CertReqMessages.
如果存在，ProtocolEncKey控件指定CA用于加密对CertReqMessages的响应的密钥。
This control can be 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生成供订户使用的私钥。
The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.
ProtocolEncKey的编码应以PublicKeyInfo为准。
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) }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax OCTET STRING
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax CertRequest
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax OCTET STRING
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax CertRequest
The security of CRMF delivery is reliant upon the security mechanisms of the protocol or process used to communicate with CAs. Such protocol or process needs to ensure the integrity, data origin authenticity, and privacy of the message. Encryption of a CRMF is strongly recommended if it contains subscriber-sensitive information and if the CA has an encryption certificate that is known to the end entity.
CRMF传递的安全性取决于用于与CAs通信的协议或进程的安全机制。此类协议或流程需要确保消息的完整性、数据来源真实性和隐私。如果CRMF包含订户敏感信息，并且CA具有终端实体已知的加密证书，则强烈建议对其进行加密。
[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月。
The authors gratefully acknowledge 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.
作者衷心感谢Barbara Fox、Warwick Ford、Russ Housley和John Pawling的贡献，他们的审查和评论极大地澄清和改进了本规范的实用性。
Michael Myers VeriSign, Inc. 1390 Shorebird Way Mountain View, CA 94019
Michael Myers VeriSign，Inc.加利福尼亚州滨鸟路山景1390号，邮编94019
EMail: mmyers@verisign.com
EMail: mmyers@verisign.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Canada, K1V 1A7
卡莱尔·亚当斯加拿大渥太华Heron路750号E08室K1V 1A7
EMail: cadams@entrust.com
EMail: cadams@entrust.com
Dave Solo Citicorp 666 Fifth Ave, 3rd Floor New York, Ny 10103
纽约州纽约市第五大道666号三楼戴夫·索洛花旗集团10103
EMail: david.solo@citicorp.com
EMail: david.solo@citicorp.com
David Kemp National Security Agency Suite 6734 9800 Savage Road Fort Meade, MD 20755
马里兰州米德堡萨维奇路6734 9800号大卫肯普国家安全局套房20755
EMail: dpkemp@missi.ncsc.mil
EMail: dpkemp@missi.ncsc.mil
Appendix A. Constructing "dhMAC"
附录A.构建“dhMAC”
This Appendix describes the method for computing the bit string "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie-Hellman certificate requests.
本附录描述了在Diffie-Hellman证书请求的占有证明POPOPrivKey结构中计算位字符串“dhMAC”的方法。
1. The entity generates a DH public/private key-pair.
1. 实体生成DH公钥/私钥对。
The DH parameters used to calculate the public SHOULD be those specified in the CA's DH certificate.
用于计算公共数据的DH参数应为CA DH证书中指定的参数。
From CA's DH certificate: CApub = g^x mod p (where g and p are the established DH parameters and x is the CA's private DH component) For entity E: DH private value = y Epub = DH public value = g^y mod p
来自CA的DH证书：CApub=g^x mod p（其中g和p是已建立的DH参数，x是CA的私有DH组件）对于实体E:DH private value=y Epub=DH public value=g^y mod p
2. The MACing process will then consist of the following steps.
2. 然后，MACing过程将包括以下步骤。
a) The value of the certReq field is DER encoded, yielding a binary string. This will be the 'text' referred to in [HMAC], the data to which HMAC-SHA1 is applied.
a) certReq字段的值经过DER编码，产生一个二进制字符串。这将是[HMAC]中提到的“文本”，HMAC-SHA1适用的数据。
b) A shared DH secret is computed, as follows, shared secret = Kec = g^xy mod p
b) 共享DH机密的计算如下：共享机密=Kec=g^xy mod p
[This is done by the entity E as CApub^y and by the CA as Epub^x, where CApub is retrieved from the CA's DH certificate and Epub is retrieved from the actual certification request.]
[这由实体E作为CApub^y和CA作为Epub^x完成，其中CApub从CA的DH证书中检索，Epub从实际的认证请求中检索。]
c) A key K is derived from the shared secret Kec and the subject and issuer names in the CA's certificate as follows:
c) 密钥K来自共享密钥Kec以及CA证书中的主体和颁发者名称，如下所示：
K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)
K=SHA1（DER编码的主题名| Kec | DER编码的发布名）
where "|" means concatenation. If subjectName in the CA certificate is an empty SEQUENCE then DER-encoded-subjectAltName should be used instead; similarly, if issuerName is an empty SEQUENCE then DER-encoded-issuerAltName should be used instead.
其中“|”表示串联。如果CA证书中的subjectName为空序列，则应改用DER编码的subjectName；类似地，如果issuerName是空序列，则应改用DER编码的ISSUERATNAME。
d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as: SHA1(K XOR opad, SHA1(K XOR ipad, text))
d) 根据[RFC2104]as:SHA1（K XOR opad，SHA1（K XOR ipad，text））在数据“文本”上计算HMAC-SHA1
where, opad (outer pad) = the byte 0x36 repeated 64 times and ipad (inner pad) = the byte 0x5C repeated 64 times.
其中，opad（外焊盘）=字节0x36重复64次，ipad（内焊盘）=字节0x5C重复64次。
Namely,
即
(1) Append zeros to the end of K to create a 64 byte string (e.g., if K is of length 16 bytes it will be appended with 48 zero bytes 0x00). (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad. (3) Append the data stream 'text' to the 64 byte string resulting from step (2). (4) Apply SHA1 to the stream generated in step (3). (5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad. (6) Append the SHA1 result from step (4) to the 64 byte string resulting from step (5). (7) Apply SHA1 to the stream generated in step (6) and output the result.
(1) 在K的末尾追加零以创建64字节的字符串（例如，如果K的长度为16字节，则将追加48个零字节0x00）。（2） XOR（按位异或）使用ipad在步骤（1）中计算的64字节字符串。（3） 将数据流“text”附加到步骤（2）产生的64字节字符串中。（4） 将SHA1应用于步骤（3）中生成的流。（5） XOR（按位异或）在步骤（1）中使用opad计算的64字节字符串。（6） 将步骤（4）中的SHA1结果附加到步骤（5）中的64字节字符串。（7） 将SHA1应用于步骤（6）中生成的流并输出结果。
Sample code is also provided in [RFC2104, RFC2202].
[RFC2104，RFC2202]中还提供了示例代码。
e) The output of (d) is encoded as a BIT STRING (the value "dhMAC").
e) （d）的输出被编码为位字符串（值“dhMAC”）。
3. The proof-of-possession process requires the CA to carry out steps (a) through (d) and then simply compare the result of step (d) with what it received as the "dhMAC" value. If they match then the following can be concluded.
3. 占有证明过程要求CA执行步骤（a）至（d），然后简单地将步骤（d）的结果与其收到的“dhMAC”值进行比较。如果它们匹配，则可以得出以下结论。
1) The Entity possesses the private key corresponding to the public key in the certification request (because it needed the private key to calculate the shared secret).
1) 实体拥有与证书请求中的公钥对应的私钥（因为它需要私钥来计算共享密钥）。
2) Only the intended CA can actually verify the request (because the CA requires its own private key to compute the same shared secret). This helps to protect from rogue CAs.
2) 只有预期的CA才能实际验证请求（因为CA需要自己的私钥来计算相同的共享密钥）。这有助于防止流氓CA。
References
工具书类
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
Acknowledgements
致谢
The details of this Appendix were provided by Hemma Prafullchandra.
本附录的细节由Hemma Prafullchandra提供。
Appendix B. Use of RegInfo for Name-Value Pairs
附录B.名称-值对的RegInfo使用
The "value" field of the id-regInfo-utf8Pairs OCTET STRING (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF8 name/value pairs.
id-regInfo-utf8Pairs八位字节字符串的“值”字段（带有等于12的“标记”字段和适当的“长度”字段）将包含一系列UTF8名称/值对。
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.
本附录列出了此类配对的一些常见示例，以促进本规范独立实现之间的互操作性。人们认识到，该列表并非详尽无遗，并将随着时间和实施经验的增长而增长。
When regInfo is used to convey one or more name-value pairs (via id-regInfo-utf8Pairs), the first and subsequent pairs SHALL be structured as follows:
当使用regInfo传递一个或多个名称-值对（通过id-regInfo-utf8Pairs）时，第一对和后续对的结构应如下所示：
[name?value][%name?value]*%
[名称？值][%name？值]*%
This string is then encoded into an OCTET STRING and placed into the regInfo SEQUENCE.
然后将该字符串编码为八位字节字符串并放入regInfo序列。
Reserved characters are encoded using the %xx mechanism of [RFC1738], unless they are used for their reserved purposes.
保留字符使用[RFC1738]的%xx机制进行编码，除非它们用于保留目的。
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
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
mailStop--邮件停止发行人名称--CA的名称
subjectName -- name of Subject validity -- validity interval
subjectName--受试者名称有效期--有效期间隔
For example:
例如：
version?1%corp_company?Acme, Inc.%org_unit?Engineering% mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% mail_email?john@acme.com%
版本？1%公司？Acme，Inc.%组织单位？工程%mail\u名字？约翰%mail\u姓氏？史密斯%jobTitle？团队负责人%mail\u电子邮件？john@acme.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>]
<notbefore> ::= <time>
<notafter> ::= <time>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<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 UTF8 characters. Within a name value, when it is necessary to disambiguate a character which 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 %%.
每个名称都包含一个单字符名称表单标识符，后跟一个或UTF8字符的名称值。在名称值中，当需要消除在外部级别具有格式重要性的字符的歧义时，应使用转义序列%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 UTF8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF8 only the characters of ASN.1 PrintableString may be used.
<avalue>是一个名称组件，其形式为1到64个字符的UTF8字符串，限制为在UTF8的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=Acme,C=US%
subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%
issuerName?XOU=Our CA,O=Acme,C=US%
subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%
References
工具书类
[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月。
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}
CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- 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-88(2)}
-- 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-88(2)}
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) };
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) };
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop 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,
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 }
publicKey[6]SubjectPublicKeyInfo可选，issuerUID[7]UniqueIdentifier可选，subjectUID[8]UniqueIdentifier可选，扩展[9]扩展可选}
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
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
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 }
-- 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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
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
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
publicKey SubjectPublicKeyInfo}——来自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 [RFC2104, 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 [RFC2104, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
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 --
--对象标识符分配--
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 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- The following definition may be uncommented for use with
-- ASN.1 compilers which do not understand UTF8String.
-- The following definition may be uncommented for use with
-- ASN.1 compilers which do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
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 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 which the receiver generates in response to
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 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 which the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
--这一要求；如果不需要存档，则设置为FALSE。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
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
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
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 }
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
--with syntax
CertReq ::= CertRequest
END
终止
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。