Internet X.509 Certificate Request Message Format
obsoleted by
- rfc-4211 — Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
Extracted elements (33)
For key agreement (DH) keys, a fourth POP option (dhMAC) is provided: the entity MACs the certReq using a key derived from a DH computation with the CA's public key. This proves possession without revealing the private key, and ensures only the intended CA can verify the request.
POP is mandated because many non-PKIX operational protocols (e.g., various email protocols) do not explicitly verify the binding between an end entity and a private key. Until such protocols become ubiquitous, certificates cannot be assumed meaningful unless the CA/RA has verified possession.
The indirect POP method for key encipherment issues the resulting certificate encrypted for the end entity, so that only the intended recipient can use it. This allows a CA to issue a certificate that can only be used by the entity that actually possesses the private key.
The POPOSigningKey structure ensures the public key does not appear redundantly in both poposkInput and CertTemplate by requiring poposkInput to be omitted when CertTemplate already carries subject and publicKey, and requiring it to be present and signed otherwise.
The regInfo name/value pair format uses %xx percent-encoding (borrowed from RFC 1738 URL syntax) with '?' as name/value delimiter and '%' as pair terminator, enabling disambiguation of reserved characters within UTF8 values.
CRMF is designed to be transported within other PKI management protocols (e.g., CMP). The specification explicitly leaves secure transport mechanisms out of scope, requiring the enclosing protocol to ensure integrity, data origin authenticity, and privacy.
For Diffie-Hellman key agreement POP, the DH parameters used to calculate the entity's public key SHOULD be those specified in the CA's DH certificate. The CA must be able to generate a short-term or one-time key pair with appropriate parameters if needed.
The EncryptedKey type supports both the legacy EncryptedValue encoding and the CMS EnvelopedData format [0], providing interoperability with CMS-based systems while maintaining backward compatibility with earlier formats.
CAs and RAs MUST enforce proof of possession by some means, because many non-PKIX operational protocols in use do not explicitly check the binding between an end entity and its private key.
If the CertReqMsg CertTemplate contains both subject and publicKey values, then poposkInput MUST be omitted and the POPOSigningKey signature MUST be computed on the DER-encoded value of CertReqMsg certReq. Conversely, if the CertTemplate does not contain publicKey and subject, then poposkInput MUST be present and MUST be signed.
In OptionalValidity, at least one of notBefore and notAfter MUST be present. Both fields are individually OPTIONAL but the SEQUENCE requires at least one.
In PKIPublicationInfo, pubInfos MUST NOT be present if the action is 'dontPublish'. If action is 'pleasePublish' and pubInfos is omitted, 'dontCare' is assumed.
The AlgorithmIdentifier for the one-way function (owf) in PBMParameter SHALL be SHA-1 {1 3 14 3 2 26} and the MAC algorithm SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
The dhMAC value in POPOPrivKey MUST be calculated as specified in Appendix A: HMAC-SHA1 over the DER-encoded certReq using a key K derived from SHA1(DER-subjectName | DH-shared-secret | DER-issuerName).
The regInfo SEQUENCE SHOULD only contain supplementary information related to the context of the certification request. Information directly related to certificate content SHOULD be included in certReq content instead.
The regToken control encoding SHALL be UTF8 to ensure uniform encoding regardless of the nature of the value (text string, numeric, binary, etc.). The same requirement applies to the authenticator control.
When CA policy requires POP verification by the CA, the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA. If the RA performs out-of-band POP verification instead, it MAY attest to the CA that the required proof has been validated.
When EncryptedKey uses the envelopedData form, the encrypted private key MUST be placed in the envelopedData encryptedContentInfo encryptedContent OCTET STRING.
CertId is a SEQUENCE of issuer (GeneralName) and serialNumber (INTEGER), used by the OldCertID control to identify the certificate being updated in a re-certification request.
CertReqMsg is a SEQUENCE containing a mandatory CertRequest, an optional ProofOfPossession field, and an optional regInfo SEQUENCE of AttributeTypeAndValue entries. CertReqMessages is a SEQUENCE SIZE(1..MAX) of CertReqMsg, allowing batched requests.
CertRequest is a SEQUENCE of certReqId (INTEGER for matching request/reply), certTemplate (CertTemplate), and optional Controls. CertTemplate carries up to ten optional fields: version, serialNumber, signingAlg, issuer, validity, subject, publicKey, issuerUID, subjectUID, and extensions.
PKIArchiveOptions is a CHOICE for private key archival: [0] EncryptedKey (either EncryptedValue or CMS EnvelopedData), [1] KeyGenParameters OCTET STRING (re-generation parameters), or [2] archiveRemGenPrivKey BOOLEAN (archive CA-generated key).
PKIPublicationInfo carries an action INTEGER (dontPublish=0 or pleasePublish=1) and an optional SEQUENCE of SinglePubInfo entries. Each SinglePubInfo specifies a publication method (dontCare=0, x500=1, web=2, ldap=3) and an optional pubLocation GeneralName.
POPOPrivKey is a CHOICE used for key encipherment and key agreement POP: [0] thisMessage BIT STRING (encrypted private key), [1] subsequentMessage (encrCert=0 or challengeResp=1), or [2] dhMAC BIT STRING (HMAC over DER-encoded certReq using shared DH secret).
ProofOfPossession is a CHOICE with four alternatives: [0] raVerified (NULL), [1] signature (POPOSigningKey), [2] keyEncipherment (POPOPrivKey), and [3] keyAgreement (POPOPrivKey). The appropriate alternative depends on the key type being certified.
Six registration controls are defined under id-regCtrl: regToken [1], authenticator [2], pkiPublicationInfo [3], pkiArchiveOptions [4], oldCertID [5], and protocolEncrKey [6]. Two regInfo types are defined: id-regInfo-utf8Pairs [1] and id-regInfo-certReq [2].
CRMF defines six registration control OIDs under id-regCtrl (id-pkix.5.1): regToken [1], authenticator [2], pkiPublicationInfo [3], pkiArchiveOptions [4], oldCertID [5], protocolEncrKey [6]. Two regInfo OIDs are defined under id-regInfo (id-pkix.5.2): utf8Pairs [1] and certReq [2].
The dhMAC proof of possession provides a dual guarantee: the entity possesses the private key corresponding to the requested public key (needed to compute the shared secret), and only the intended CA can verify the request (because the CA requires its own private key to compute the same shared secret), protecting against rogue CAs.
The regToken value should be distributed out-of-band with security commensurate with the risk of the CA accepting an intercepted value. If an attacker can intercept and replay the regToken, they can impersonate the legitimate subscriber during PKI initialization.
The security of CRMF delivery is entirely reliant on the security mechanisms of the enclosing protocol or process. That protocol must ensure integrity, data origin authenticity, and privacy. Encryption of a CRMF is strongly recommended when it contains subscriber-sensitive information and when the CA has an accessible encryption certificate.
CertTemplate is an ASN.1 SEQUENCE with ten context-tagged OPTIONAL fields: [0] Version, [1] INTEGER serialNumber, [2] AlgorithmIdentifier signingAlg, [3] Name issuer, [4] OptionalValidity, [5] Name subject, [6] SubjectPublicKeyInfo publicKey, [7] UniqueIdentifier issuerUID, [8] UniqueIdentifier subjectUID, [9] Extensions.
PBMParameter is a SEQUENCE of salt (OCTET STRING), owf AlgorithmIdentifier (one-way function applied iterationCount times), iterationCount INTEGER, and mac AlgorithmIdentifier. It parameterizes the password-based MAC used in PKMACValue.
POPOSigningKey is a SEQUENCE of an optional [0] POPOSigningKeyInput, an AlgorithmIdentifier, and a BIT STRING signature. POPOSigningKeyInput in turn carries an authInfo CHOICE (GeneralName sender or PKMACValue publicKeyMAC) and a SubjectPublicKeyInfo publicKey.