Internet X.509 Public Key Infrastructure Certificate Management Protocols
obsoleted by
- rfc-4210 — Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
Extracted elements (28)
The CA returning an EncryptedCert (certificate encrypted so only the intended recipient can decrypt it) allows a CA to issue a certificate before POP is complete; if POP subsequently fails, the CA need not revoke the certificate because the certificate is unusable without proof of the private key.
The indirect POP method for encryption keys — returning the certificate encrypted under a randomly generated symmetric key, which is itself encrypted under the requested public key, with confirmation via MAC over a key derived from that symmetric key — is encouraged because it requires no extra round trips beyond the standard {request, response, confirmation} triple.
The RA is defined as an OPTIONAL component; when absent, the CA assumes all RA functions so that the PKI management protocol is identical from the end entity's perspective regardless of whether it communicates with an RA or directly with the CA.
When a RA forwards an end entity's protected PKI message to a CA, the RA MAY nest the entire end-entity PKIMessage inside a new PKIMessage (NestedMessageContent ::= PKIMessage) and apply its own protection. This preserves the original message integrity while adding the RA's authentication layer.
PKCS#10 CertificationRequest (p10cr) MAY be used as an alternative PKIBody for certification of signing key pairs to interoperate with legacy systems, but its use is strongly discouraged whenever not absolutely necessary.
CAs and RAs MUST enforce Proof of Possession (POP) by some means, because many non-PKIX operational protocols do not explicitly check the binding between an end entity and its private key; without CA/RA enforcement, certificates in the Internet PKI become less meaningful.
Conforming CA equipment, RA equipment, and EE equipment MUST support the basic authenticated scheme: end-entity-initiated, with message authentication via an out-of-band Initial Authentication Key, key generation at the EE, and a mandatory PKIConfirm confirmation message.
For cross-certification requests, the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA.
If PKIProtection bits are supplied then the protectionAlg field MUST be supplied; if no protection bits are present (PKIProtection is OPTIONAL), then protectionAlg MUST be omitted.
If the sender is unknown (e.g., in an initialization request where the end entity does not yet know its DN), the sender field MUST contain a NULL value (zero-length SEQUENCE OF RDNs), and the senderKID field MUST hold an identifier pointing to the shared secret to be used for verification.
When verification of a PKIConfirm message fails after certificate issuance, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.
CA key update requires four certificate attribute values in the X.500 directory: OldWithOld (self-signed with old key), OldWithNew (old public key signed with new private key), NewWithOld (new public key signed with old private key), and NewWithNew (self-signed with new key). Validity periods of the transitional certificates must be carefully set to cover the transition window.
InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } is used in GenMsgContent and GenRepContent for extensible general-purpose PKI information exchange. Defined id-it OIDs include CAProtEncCert, SignKeyPairTypes, EncKeyPairTypes, PreferredSymmAlg, CAKeyUpdateInfo, and CurrentCRL.
PKIBody is a CHOICE of 24 message types covering the full certificate lifecycle: initialization request/response (ir/ip), certification request/response (cr/cp), PKCS#10 request (p10cr), POP challenge/response (popdecc/popdecr), key update (kur/kup), key recovery (krr/krp), revocation (rr/rp), cross-certification (ccr/ccp), CA key update announcement (ckuann), certificate/revocation/CRL announcements (cann/rann/crlann), confirmation (conf), nested message, general message/response (genm/genp), and error.
PKIStatus INTEGER encodes seven states: granted (0), grantedWithMods (1), rejection (2), waiting (3), revocationWarning (4), revocationNotification (5), and keyUpdateWarning (6). PKIFailureInfo BIT STRING provides ten failure reason bits (badAlg through badPOP).
PKI management protocols must support proof of possession of private keys to prevent attacks where an end entity obtains a certificate for a key it does not control. This is critical because many operational protocols rely solely on the CA/RA having verified this binding.
The use of confidentiality in PKI management protocols is deliberately minimized to ease regulatory problems; however, when encrypted values are transported (e.g., private keys or encrypted certificates), the EncryptedValue structure from CRMF is used and requires the sender and recipient to share or derive a symmetric key.
CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew Certificate, newWithOld Certificate, newWithNew Certificate } carries the three transitional certificates needed when a CA updates its key pair: old public key signed with new private key, new public key signed with old private key, and new public key signed with new private key.
CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE OF Certificate OPTIONAL, response SEQUENCE OF CertResponse }. CertResponse contains certReqId, PKIStatusInfo, optional CertifiedKeyPair, and optional rspInfo. CertOrEncCert is a CHOICE between a plaintext Certificate and an EncryptedValue.
KeyRecRepContent ::= SEQUENCE { status PKIStatusInfo, newSigCert [0] Certificate OPTIONAL, caCerts [1] SEQUENCE OF Certificate OPTIONAL, keyPairHist [2] SEQUENCE OF CertifiedKeyPair OPTIONAL } is the response structure for key recovery operations.
OOBCert is a self-signed Certificate whose subject and issuer MUST be identical; if the subject is NULL, both subjectAltNames and issuerAltNames MUST be present and equal. OOBCertHash ::= SEQUENCE { hashAlg [0] AlgorithmIdentifier OPTIONAL, certId [1] CertId OPTIONAL, hashVal BIT STRING } conveys a hash of the self-signed certificate for out-of-band root CA key distribution.
PKIHeader contains pvno (fixed at 1), sender and recipient GeneralNames, optional messageTime, protectionAlg, senderKID, recipKID, transactionID, senderNonce, recipNonce, freeText, and generalInfo fields. The transactionID correlates request/response/confirmation triples; senderNonce and recipNonce provide replay protection.
PKIProtection is a BIT STRING computed over the DER encoding of ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody }. Three protection modes are defined: shared-secret MAC (PasswordBasedMac), DH-derived MAC (DHBasedMac), and digital signature.
POPODecKeyChallContent is a SEQUENCE OF Challenge where each Challenge contains an owf AlgorithmIdentifier, a witness OCTET STRING (OWF applied to random integer A), and a challenge OCTET STRING (public-key encryption of Rand ::= SEQUENCE { int INTEGER, sender GeneralName }). POPODecKeyRespContent is a SEQUENCE OF INTEGER returning the decrypted A values.
RevDetails ::= SEQUENCE { certDetails CertTemplate, revocationReason ReasonFlags OPTIONAL, badSinceDate GeneralizedTime OPTIONAL, crlEntryDetails Extensions OPTIONAL }. RevRepContent carries a parallel SEQUENCE OF PKIStatusInfo, optional CertIds, and optional resulting CRLs.
The DHBasedMac protection algorithm (OID 1 2 840 113533 7 66 30) uses DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier, mac AlgorithmIdentifier }. The OWF is applied to the DH shared secret to derive BASEKEY, which keys the MAC.
The PasswordBasedMac protection algorithm (OID 1 2 840 113533 7 66 13) uses PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, iterationCount INTEGER, mac AlgorithmIdentifier }. The OWF (SHA-1 recommended) is applied iterationCount times to the salted shared secret to derive BASEKEY, which is then used as the MAC key.
The top-level PKIMessage structure is a SEQUENCE containing a PKIHeader, a PKIBody, an optional PKIProtection BIT STRING, and an optional extraCerts field carrying certificates that may assist the recipient in path validation.