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)
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.
Copyright Notice
Copyright (C) The Internet Society (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.
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
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.
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).
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).
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].
2. Overview
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.
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.
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.
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.
2.1. Changes since RFC 2511
1. Addition of an introduction section.
2. Addition of the concept of a CRP and language relating to CRPs.
3. In section 6.2, changed regToken to authenticator.
4. Add information describing the contents of the EncryptedValue
structure.
5. Changed name and contents of OID {id-regInfo 1}.
6. Added text detailing what goes into the fields of the different
structures defined in the document.
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. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
8. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
9. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
10. Add details on how private keys are to be structured when
encrypted.
11. Allow for POP on key agreement algorithms other than DH.
3. CertReqMessage Syntax
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
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:
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.
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.
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.
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.
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.
4. Proof-of-Possession (POP)
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
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.
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.
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.
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.
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.
signature is used for performing POP with signature keys. The
details of this field are covered in section 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.
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.
4.1. Signature Key POP
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.
There are three cases that need to be looked at when doing a POP for
a signature key:
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.
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.
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.
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
The fields of POPOSigningKey have the following meaning:
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.
algorithmIdentifier identifiers the signature algorithm and an
associated parameters used to produce the POP value.
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.
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:
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.
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 }
The fields of PKMACValue have the following meaning:
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.
value contains the computed MAC value. The MAC value is computed
over the DER-encoded public key of the certificate subject.
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.
4.2. Key Encipherment Keys
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).
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) }
The fields of POPOPrivKey have the following meaning:
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
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.
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.
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.
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.
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.
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.
macAlg contains the algorithm identifying the method used to
compute the MAC value.
macValue contains the computed MAC value.
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.
It is expected that protocols that incorporate this specification
will include the confirmation and challenge-response messages
necessary for a complete protocol.
4.2.1. Private Key Info Content Type
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.
This content type and its structure are:
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
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
}
Attributes ::= SET OF Attribute
The fields of EncKeyWithID are defined as:
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.
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