Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
obsoletes
- rfc-2511 — Internet X.509 Certificate Request Message Format
updated by
- rfc-9045 — Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
Extracted elements (31)
EncKeyWithID adds an identifier field to the PKCS#8 PrivateKeyInfo structure to thwart an escrow-agent attack: without it, an attacker could intercept an encrypted private key, wrap it in a new certificate request, and then claim a recovery on the key as if they were the owner.
The regInfo field is intentionally separate from certReq so that supplementary registration data (billing, contact info) can be added by an RA without invalidating the subject's POP signature over the certificate template.
The thisMessage and dhMAC fields in POPOPrivKey are deprecated; thisMessage is superseded by encryptedKey (EnvelopedData), and dhMAC is superseded by agreeMAC. The EncryptedValue structure is also deprecated in favor of EnvelopedData throughout.
A requestor MUST NOT set the raVerified field in ProofOfPossession, and an RA/CA MUST NOT accept a ProofOfPossession where the requestor sets this field. CRPs MUST provide a method for the RA to sign the ProofOfPossession when using raVerified.
All implementations MUST support HMAC-SHA1 for the PBM mac algorithm; all implementations SHOULD support DES-MAC and Triple-DES-MAC.
All implementations MUST support id-PasswordBasedMAC in PKMACValue algId. The MAC value is computed over the DER-encoded public key of the certificate subject.
Any CRP referencing this document MUST enforce Proof-of-Possession by some means. The binding between the public key and the identity in the certificate cannot be assumed verified unless POP is performed.
For DH key agreement POP, all implementations MUST support the static DH Proof-of-Possession algorithm as specified in RFC 2875 section 3.
If a CA is required by policy to verify POP, the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA. If the CA is not required to verify POP, the RA SHOULD forward them unaltered.
In CertTemplate, version MUST be 2 if supplied and SHOULD be omitted; serialNumber MUST be omitted (assigned by CA); signingAlg MUST be omitted (assigned by CA); issuerUID and subjectUID MUST be omitted (deprecated in the PKIX profile).
In POPOSigningKeyInput, the publicKey field MUST be exactly the same value as is contained in the certificate template. This ties the POP signature to the specific key being certified.
The PBM iterationCount MUST be a minimum of 100; many implementations use 1000 or more as a practical minimum to slow dictionary attacks against the password.
The publicKey field in CertTemplate MUST be filled in if the requestor generates its own key; the field is omitted if the key is generated by the RA/CA. If validity is not omitted, at least one of notBefore/notAfter MUST be specified.
CertReqMsg is the top-level certificate request message structure, composed of a CertRequest, an optional ProofOfPossession (popo), and an optional regInfo sequence of AttributeTypeAndValue. The popo field varies in structure based on the key type and usage mode.
ProofOfPossession is a CHOICE of raVerified (NULL), signature (POPOSigningKey), keyEncipherment (POPOPrivKey), or keyAgreement (POPOPrivKey). The choice is determined by the key type and the mode in which the algorithm is used.
The authenticator control (id-regCtrl-authenticator) carries long-term non-cryptographic identity information (e.g., mother's maiden name, knowledge-based answers) encoded as UTF8String. Unlike regToken, it may be used for both initial and subsequent certification requests.
The certReq regInfo control (id-regInfo-certReq) allows an RA to supply a replacement CertRequest when the RA must modify the certificate template but cannot alter the original without invalidating POP. If present, the original certTemplate in the request MUST be ignored.
The oldCertID control (id-regCtrl-oldCertID) identifies the certificate being updated by encoding a CertId SEQUENCE of issuer (GeneralName) and serialNumber (INTEGER).
The pkiArchiveOptions control (id-regCtrl-pkiArchiveOptions) enables key escrow by conveying the private key (encryptedPrivKey via EnvelopedData), key generation parameters (keyGenParameters), or a flag requesting CA-generated key archival (archiveRemGenPrivKey). The EncryptedValue choice is deprecated; envelopedData MUST be used.
The pkiPublicationInfo control (id-regCtrl-pkiPublicationInfo) lets subscribers request that the CA publish or not publish their certificate, and optionally specify publication locations (x500, web, ldap) via SinglePubInfo structures. This control is advisory and CAs/RAs may ignore it.
The protocolEncrKey control (id-regCtrl-protocolEncrKey) specifies a SubjectPublicKeyInfo key the CA MUST use to encrypt its response, enabling secure return of CA-generated private keys or other sensitive information.
The regToken control (id-regCtrl-regToken) carries a one-time shared secret (encoded as UTF8String) used by the CA to verify the subject's identity prior to initial certificate issuance. It is intended only for PKI initialization, not for subsequent requests.
Implementations MUST enforce POP during enrollment. Failure to do so allows an attacker to obtain a certificate for a key they do not possess, enabling impersonation on signature keys and interception of messages encrypted to key-management keys.
Implementations MUST use high-entropy random number generators for private keys, content-encryption keys, MACs, IVs, salt, and padding. Weak PRNGs reduce effective key space and allow key reproduction attacks.
Key escrow implementations must ensure: the client correctly identifies the escrow entity; transport algorithms match the sensitivity of the escrowed data; only authorized entities can retrieve escrowed keys; and the escrow database is stored securely (e.g., re-encrypted under keys known only to the escrow agent).
Remote key generation SHOULD NOT be used for signing keys; a remotely generated signing key creates repudiation risk because the generating entity (and anyone in the transfer path) could also have possessed the key. Encryption keys transported remotely MUST be protected with strong encryption algorithms and a content- or key-encryption key.
CertRequest encodes a certReqId INTEGER (for matching request/reply), a CertTemplate (selected X.509 certificate fields), and an optional Controls sequence. CertTemplate is a fully optional SEQUENCE with up to 10 tagged fields (version through extensions).
EncKeyWithID encodes a PrivateKeyInfo plus an optional identifier (UTF8String or GeneralName). The identifier MUST be present when the purpose is to prove possession of the private key, and SHOULD be present when archiving a key for an escrow agent that will decrypt it.
PBMParameter encodes salt (OCTET STRING, SHOULD be at least 8 octets), owf (AlgorithmIdentifier for the one-way function, SHA-1 required), iterationCount (INTEGER, minimum 100), and mac (AlgorithmIdentifier, HMAC-SHA1 required).
POPOPrivKey is a CHOICE supporting: thisMessage [0] BIT STRING (deprecated), subsequentMessage [1] SubsequentMessage (encrCert or challengeResp), dhMAC [2] BIT STRING (deprecated), agreeMAC [3] PKMACValue, and encryptedKey [4] EnvelopedData. The encryptedKey MUST contain id-ct-encKeyWithID as its content type.
POPOSigningKey contains an optional poposkInput (POPOSigningKeyInput), an AlgorithmIdentifier, and a BIT STRING signature. poposkInput MUST be present when the certificate template does not contain both the public key value and a subject name value.