Lightweight Certificate Management Protocol (CMP) Profile
Extracted elements (26)
All certificate management operations follow the pull model (initiated by the EE), and announcement messages (which require a push model and a CMP server on the EE) are excluded in favor of a lightweight EE implementation.
When design flexibility existed, complexity was placed in PKI management entities rather than EEs, because management entities typically have more computational resources. This minimizes resource requirements for memory-constrained IoT devices while keeping the mandatory-to-implement feature set for EEs small.
For SZTP/NETCONF environments using ietf-ztp-csr, the ir/cr/kur/p10cr message MUST be formatted as described in Section 4.1 and MAY be forwarded per Section 5.2. For BRSKI-AE environments, CMP use requires adherence to this profile.
This profile is compatible with RFC 4210 Appendices D and E with exceptions: signature-based protection is the default (not MAC), dual-key certification in one operation is unsupported, confirmation may be omitted with implicitConfirm, and announcement messages are excluded.
An EE MUST include the implicitConfirm generalInfo field in ir/cr/kur/p10cr unless it requires explicit confirmation. If the PKI management entity needs explicit confirmation, it MUST NOT include implicitConfirm in the response; otherwise it MUST include it.
An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in the upstream direction. On other downstream error conditions the PKI management entity MUST report them as an error message downstream.
For central key pair generation, the PKI management entity acting as KGA MUST use a certificate containing the extended key usage id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority.
For key update (kur), protection MUST be performed using the certificate to be updated, the subject field/subjectAltName MUST contain the EE subject name of the existing certificate without modification, and the caPubs field in the kup response MUST be absent.
For MAC-based enrollment, all messages MUST use MAC-based protection, and the PKI management entity checking MAC-based protection MUST replace this protection (re-protect with its own credentials) before forwarding upstream, since the next hop may not know the shared secret.
If certificate confirmation is required, the EE MUST send a certConf message on successful receipt of the certificate. On receiving a valid certConf, the PKI management entity MUST respond with pkiConf. If certConf is not received in time, the entity MUST treat it as rejection.
Messages without protection MUST be rejected except for error messages. Messages with invalid protection MUST be rejected. If signature-based protection is used, the CMP protection certificate MUST be successfully validated via path validation using a trust anchor.
The extraCerts field MUST be present for signature-based protection and contain the CMP protection certificate plus its chain in the first request and response of an operation. The first certificate MUST be the CMP protection certificate. Self-signed certificates MUST NOT be trusted based on inclusion in extraCerts.
The formal ASN.1 syntax of the whole CMP message MUST be compliant with RFC 4210, RFC 9480, RFC 4211, RFC 5652, and RFC 8933. The pvno MUST be cmp2000(2) or cmp2021(3). The transactionID MUST be present.
The ir MUST contain a sequence of exactly one CertReqMsg. The certReqId MUST be 0. The certTemplate MUST contain the subject field and/or subjectAltName, and MUST include the publicKey when local key generation is used.
The proof-of-possession MUST be provided by signing the certReq containing the certTemplate. When using POPOSigningKey, the poposkInput field MUST NOT be used. The signature algorithm MUST be consistent with the publicKey algorithm field of the certTemplate.
The pvno field MUST be 3 (CMP v3) in all cases where EnvelopedData is supported or expected to be used, and in certConf messages using the hashAlg field; MUST be 2 (CMP v2) in all other cases.
The same kind of protection (signature-based or MAC-based) MUST be used for all messages of a single PKI management operation. Protection MUST be present except for error messages where protection is not technically feasible.
The senderNonce MUST be cryptographically secure fresh 128 random bits. The recipNonce MUST be absent in the first message and MUST equal the senderNonce of the previous message in all other messages.
The transactionID MUST be 128 bits of random data in the first message of a PKI management operation to minimize collision probability; all subsequent messages in the same operation MUST reuse that value.
When an EE receives a CA certificate in caPubs for installation as a new trust anchor, it MUST properly authenticate the message and authorize the sender. A certificate received in caPubs MUST NOT be accepted as a trust anchor if it is the root CA certificate of the certificate used to protect the message.
Every CMP message consists of four fields: header (REQUIRED), body (REQUIRED), protection (OPTIONAL), and extraCerts (OPTIONAL), as defined in RFC 4210 Section 5.1.
The certConf message MUST contain a sequence of one CertStatus with certHash (computed using the hash algorithm of the certificate signature or as indicated by hashAlg), certReqId (MUST be 0), and optional statusInfo. The hashAlg field requires pvno cmp2021(3) and its use is NOT RECOMMENDED if the algorithm can be identified by other means.
The PKIStatusInfo structure carries status ('rejection', 'accepted', 'grantedWithMods', 'waiting'), an optional human-readable statusString, and an optional failInfo bitfield using PKIFailureInfo values such as badCertId, badPOP, certRevoked, badCertTemplate, transactionIdInUse, notAuthorized, systemUnavail, and systemFailure.
Certificate status checking SHOULD be performed on CMP protection certificates. If the response contains the caPubs field to transfer new trust anchor information, certificate status checking is REQUIRED. Path validation per RFC 5280 MUST be followed for signature-based CMP message protection.
The entropy of shared secret information is crucial for the level of protection when using MAC-based protection. The shared secret MUST be established out of band (e.g., by a service technician during initial local configuration). Further guidance is in CMP Updates (RFC 9480).
The EE state machine begins with sending ir/cr/kur/p10cr/rr/genm, then enters 'waiting for response'. On receiving ip/cp/kup with status 'accepted'/'grantedWithMods', it either uses implicitConfirm or sends certConf and awaits pkiConf. Status 'waiting' triggers a polling sub-loop using pollReq/pollRep. The operation ends on receiving pkiConf, rp/genp, or any rejection.