1.1. How to Read This Document

This document has become longer than the authors would have liked it to be. Yet apart from studying Section 3, which contains general requirements, the reader does not have to work through the whole document. The guidance in Sections 1.9 and 7 should be used to figure out which parts of Sections 4 to 6 are relevant for the target certificate management solution, depending on the PKI management operations, their variants, and types of message transfer needed.¶

Since conformity to this document can be achieved by implementing only the functionality declared mandatory in Section 7, the profile can still be called lightweight because, in particular for end entities, the mandatory-to-implement set of features is rather limited.¶

1.2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The term "PROHIBITED" is to be interpreted to mean that the respective ASN.1 field SHALL NOT be present or used.¶

Technical terminology is used in conformance with [RFC4210], [RFC4211], [RFC5280], and IEEE 802.1AR [IEEE.802.1AR_2018]. The following terminology is used:¶

CA:

Certification authority, which issues certificates.¶

RA:

Registration authority, an optional PKI component to which a CA delegates certificate management functions, such as end entity authentication and authorization checks for incoming requests. An RA can also provide conversion between various certificate management protocols and other protocols providing some operations related to certificate management.¶

LRA:

Local registration authority, a specific form of RA with proximity to the end entities.¶

Note: For ease of reading, this document also uses the term "RA" for LRAs in all cases where the difference is not relevant.¶

KGA:

Key generation authority, an optional system component, typically colocated with an RA or CA, that offers key generation services to end entities.¶

EE:

End entity, typically a device or service that holds a public-private key pair for which it manages a public key certificate. An identifier for the EE is given as the subject of its certificate.¶

The following terminology is reused from [RFC4210] as follows:¶

PKI management operation:

All CMP messages belonging to a single transaction. The transaction is identified by the transactionID field of the message headers.¶

PKI management entity:

A non-EE PKI entity, i.e., an RA or a CA.¶

PKI entity:

An EE or PKI management entity.¶

CMP messages are referred to by the names of PKIBody choices defined in Section 5.1.2 of [RFC4210] and are further described in Section 4 of this document.¶

The following terms are introduced in this document:¶

CMP protection key:

The private key used to sign a CMP message.¶

CMP protection certificate:

The certificate related to the CMP protection key. If the keyUsage extension is present, it MUST include digitalSignature.¶

1.3. Motivation for a Lightweight Profile of CMP

CMP was standardized in 1999 and is implemented in several PKI products. In 2005, a completely reworked and enhanced version 2 of CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a document specifying a transfer mechanism for CMP messages using HTTP [RFC6712] in 2012.¶

CMP is a capable protocol and could be used more widely. CMP [RFC4210] and CMP Updates [RFC9480] offer a very large set of features and options. On one hand, this makes CMP applicable to a very wide range of scenarios; on the other hand, a full implementation supporting all options is not realistic because this would take undue effort.¶

In order to reduce complexity, the set of mandatory PKI management operations and variants required by this specification has been kept lean. This limits development efforts and minimizes resource needs, which is particularly important for memory-constrained devices. To this end, when there was design flexibility to either have necessary complexity on the EE or in the PKI management entity, this profile chose to include it in the PKI management entities where typically more computational resources are available. Additional recommended PKI management operations and variants support some more complex scenarios that are considered beneficial for environments with more specific demands or boundary conditions. The optional PKI management operations support less common scenarios and requirements.¶

Moreover, many details of the Certificate Management Protocol have been left open or have not been specified in full preciseness. The profiles specified in Appendices D and E of [RFC4210] define some more detailed PKI management operations. Yet the specific needs of highly automated scenarios for machine-to-machine communication are not covered sufficiently.¶

Profiling is a way to reduce feature richness and complexity of standards to what is needed for specific use cases. 3GPP and UNISIG already use profiling of CMP as a way to cope with these challenges. To profile means to take advantage of the strengths of the given protocol while explicitly narrowing down the options it provides to those needed for the purpose(s) at hand and eliminating all identified ambiguities. In this way, the general aspects of the protocol are utilized and only the special requirements of the target scenarios need to be dealt with using distinct features the protocol offers.¶

Defining a profile for a new target environment takes high effort because the range of available options needs to be well understood and the selected options need to be consistent with each other and suitably cover the intended application scenario. Since most industrial PKI management use cases typically have much in common, it is worth sharing this effort, which is the aim of this document. Other standardization bodies can reference this document and further tailor the PKI management operations to their needs to avoid coming up with individual profiles from scratch.¶

1.4. Special Requirements of Industrial and IoT Scenarios

The profiles specified in Appendices D and E of [RFC4210] have been developed particularly for managing certificates of human end entities. With the evolution of distributed systems and client-server architectures, certificates for machines and applications on them have become widely used. This trend has strengthened even more in emerging industrial and IoT scenarios. CMP is sufficiently flexible to support them well.¶

Today's IT security architectures for industrial solutions typically use certificates for endpoint authentication within protocols like IPsec, TLS, or Secure Shell (SSH). Therefore, the security of these architectures highly relies upon the security and availability of the implemented certificate management operations.¶

Due to increasing security and availability needs in operational technology, especially when used for critical infrastructures and systems with a high number of certificates, a state-of-the-art certificate management system must be constantly available and cost-efficient, which calls for high automation and reliability. Consequently, "Framework for Improving Critical Infrastructure Cybersecurity" [NIST.CSWP.04162018] refers to proper processes for issuance, management, verification, revocation, and audit of authorized devices, users, and processes involving identity and credential management. According to commonly accepted best practices, such PKI management operations are also required in [IEC.62443-3-3] for security level 2 and higher.¶

Further challenges in many industrial systems are network segmentation and asynchronous communication. Also, PKI management entities like certification authorities (CAs) are not typically deployed on-site but in a highly protected data center environment, e.g., operated according to ETSI Policy and security requirements for Trust Service Providers issuing certificates [ETSI-EN.319411-1]. Certificate management must be able to cope with such network architectures. CMP offers the required flexibility and functionality, namely authenticated self-contained messages, efficient polling, and support for asynchronous message transfer while retaining end-to-end authentication.¶

1.5. Existing CMP Profiles

As already stated, [RFC4210] contains profiles with mandatory and optional PKI management operations in Appendices D and E of [RFC4210]. Those profiles focus on management of human user certificates and only partly address the specific needs of certificate management automation for unattended devices or machine-to-machine application scenarios.¶

Both Appendices D and E of [RFC4210] focus on PKI management operations between an EE and an RA or CA. They do not address further profiling of RA-to-CA communication, which is typically needed for full backend automation. All requirements regarding algorithm support for Appendices D and E of [RFC4210] have been updated by Section 7.1 of CMP Algorithms [RFC9481].¶

3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 [ETSI-3GPP.33.310] for automatic management of IPsec certificates in 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP profile for initial certificate enrollment and certificate update operations between EEs and RAs/CAs is specified in that document.¶

In 2015, UNISIG included a CMP profile for enrollment of TLS certificates in the Subset-137 specifying the ETRAM/ETCS online key management for train control systems [UNISIG.Subset-137].¶

Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI management operations for unattended devices and services.¶

1.6. Compatibility with Existing CMP Profiles

The profile specified in this document is compatible with Appendices D and E of [RFC4210], with the following exceptions:¶

• signature-based protection is the default protection; an initial PKI management operation may also use protection based on the message authentication code (MAC),¶
• certification of a second key pair within the same PKI management operation is not supported,¶
• proof-of-possession (POP) with the self-signature of the certReq containing the certTemplate (according to [RFC4211], Section 4.1, clause 3) is the recommended default POP method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technically not capable to generate digital signatures),¶
• confirmation of newly enrolled certificates may be omitted, and¶
• all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model, a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.¶

The profile specified in this document is compatible with the CMP profile for 3G, LTE, and 5G network domain security and authentication framework [ETSI-3GPP.33.310], except that:¶

• protection of initial PKI management operations may be MAC-based,¶
• the subject field is mandatory in certificate templates, and¶
• confirmation of newly enrolled certificates may be omitted.¶

The profile specified in this document is compatible with the CMP profile for online key management in rail networks as specified in [UNISIG.Subset-137], except that:¶

• A certificate enrollment request message consists of only one certificate request (CertReqMsg).¶

• [RFC4210] requires that the messageTime is Greenwich Mean Time coded as generalizedTime.¶

  Note: As Table 5 of [UNISIG.Subset-137] explicitly states that the messageTime is required to be "UTC time", it is not clear if this means a coding as UTCTime or generalizedTime and if time zones other than Greenwich Mean Time shall be allowed. Both time formats are described in Section 4.1.2.5 of [RFC5280].¶

• The same type of protection is required to be used for all messages of one PKI management operation. This means, in case the request message protection is MAC-based, the response, certConf, and pkiConf messages must also have MAC-based protection.¶

• Use of caPubs is not required but is typically allowed in combination with MAC-based protected PKI management operations. On the other hand, Table 12 of [UNISIG.Subset-137] requires using caPubs.¶

  Note: It remains unclear from UNISIG Subset-137 which certificate(s) for the caPubs field should be used. For security reasons, it cannot be used for delivering the root CA certificate needed to validate the signature-based protection of the given response message (as stated indirectly also in Section 6.3.1.5.2 b of [UNISIG.Subset-137]).¶

• This profile requires that the certConf message have one CertStatus element where the statusInfo field is recommended.¶

  Note: In contrast, Table 18 of [UNISIG.Subset-137] requires that the certConf message has one CertStatus element where the statusInfo field must be absent. This precludes sending a negative certConf message in case the EE rejects the newly enrolled certificate. This results in violating the general rule that a certificate request transaction must include a certConf message (moreover, since using implicitConfirm is not allowed there either).¶

1.7. Use of CMP in SZTP and BRSKI Environments

In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other environments using Network Configuration Protocol (NETCONF) / YANG modules, [SZTP-CSR] offers a YANG module that includes several types of certificate requests to obtain a public key certificate for a locally generated key pair. Such messages are of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer both proof-of-possession and proof-of-identity. To allow PKI management entities that use the module ietf-ztp-csr and also wish to comply with this profile, the ir, cr, kur, or p10cr message MUST be formatted by the EE as described in Section 4.1, and it MAY be forwarded, as specified in Section 5.2.¶

In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI" [BRSKI-AE] describes a generalization regarding the employed enrollment protocols to allow alternatives to Enrollment over Secure Transport (EST) [RFC7030]. For the use of CMP, it requires adherence to this profile.¶

1.8. Scope of This Document

On one hand, this profile intends to reduce the flexibility of CMP to the generic needs of automated certificate management of machine end entities. On the other hand, it offers a variety of PKI management operations and options relevant for industrial use cases. Therefore, it is still a framework that supports further profiling by those addressing a specific use case or scenario, e.g., 3GPP/ETSI or UNISIG. There is room to further tailor this profile. This enables stricter profiling to meet the concrete needs in application areas.¶

To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements for generating PKI management messages on the sender side. However, it gives only minimal requirements on checks by the receiving side and how to handle error cases.¶

Especially on the EE side, this profile aims at a lightweight implementation. This means that the number of PKI management operation implementations are reduced to a reasonable minimum to support typical certificate management use cases in industrial machine-to-machine environments. On the EE side, only limited resources are expected, while on the side of the PKI management entities, the profile accepts higher requirements.¶

For the sake of interoperability and robustness, implementations should, so long as security is not affected, adhere to Postel's law: "Be conservative in what you do, be liberal in what you accept from others" (often reworded as: "Be conservative in what you send, be liberal in what you receive").¶

Fields used in ASN.1 syntax in Sections 3, 4, or 5 are specified in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. When these sections do not explicitly discuss a field, then the field SHOULD NOT be used by the sending entity. The receiving entity MUST NOT require the absence of such a field and, if the field is present, MUST handle it gracefully.¶

1.9. Structure of This Document

Section 2 introduces the general PKI architecture and approach to certificate management that is assumed in this document.¶

Section 3 profiles the generic aspects of the PKI management operations specified in detail in Sections 4 and 5 to minimize redundancy in the description and to ease implementation. This covers the general structure and protection of messages, as well as generic prerequisites, validation, and error handling.¶

Section 4 profiles the exchange of CMP messages between an EE and the PKI management entity. There are various flavors of certificate enrollment requests, optionally with polling, central key generation, revocation, and general support PKI management operations.¶

Section 5 profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which involves polling for responses, and nesting of messages.¶

Section 6 outlines several mechanisms for CMP message transfer, including HTTP-based transfer [RFC6712] optionally using TLS, CoAP-based transfer [RFC9482] optionally using DTLS, and offline file-based transport.¶

Section 7 defines which parts of the profile are mandatory, recommended, optional, or not relevant to implement for which type of entity.¶

3.1. General Description of the CMP Message Header

This section describes the generic header fields of all CMP messages.¶

Any fields or variations specific to PKI management operation are described in Sections 4 and 5.¶

header
  pvno                        REQUIRED
    -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
    --   is supported and expected to be used in the current
    --   PKI management operation
    -- MUST be 3 to indicate CMP v3 in certConf messages when using
    --   the hashAlg field
    -- MUST be 2 to indicate CMP v2 in all other cases
    -- For details on version negotiation, see [RFC9480]
  sender                      REQUIRED
    -- Contains a name representing the originator, which also
    --   protects the message
    -- For signature-based protection, MUST be the subject field of
    --   the CMP protection certificate
    -- For MAC-based protection, MUST contain a name the PKI
    --   management entity can use to identify the shared secret
    --   information. This name MUST be placed in the commonName
    --   field of the directoryName choice.
    -- In a multihop scenario, the receiving entity cannot rely
    --   on the correctness of the sender field.
  recipient                   REQUIRED
    -- SHOULD be the name of the intended recipient; otherwise, the
    --   NULL-DN MUST be used
    -- In the first message of a PKI management operation, SHOULD be
    --   the subject DN of the CA the PKI management operation is
    --   requested from
    -- In all other messages, SHOULD contain the value of the sender
    --   field of the previous message in the same PKI management
    --   operation
    -- The recipient field shall be handled gracefully by the
    --   receiving entity, because in a multihop scenario, its
    --   correctness cannot be guaranteed.
  messageTime                 OPTIONAL
    -- MUST be present if the confirmWaitTime field is present
    -- MUST be the time at which the message was produced, if present
    -- MAY be set by a PKI management entity to provide the current
    --   time
    -- MAY be used by the end entity for time synchronization if the
    --   response was received within a short time frame
  protectionAlg               REQUIRED
    -- MUST be an algorithm identifier indicating the algorithm
    --   used for calculating the protection bits
    -- If it is a signature algorithm, its type MUST be
    --   MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
    --   MUST be consistent with the subjectPublicKeyInfo field of
    --   the CMP protection certificate
    -- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
    --   specified in [RFC9481], Section 6.1
  senderKID                   RECOMMENDED
    -- For signature-based protection, MUST be used and contain the
    --   value of the SubjectKeyIdentifier if present in the CMP
    --   protection certificate
    -- For MAC-based protection, MUST be used and contain the same
    --   name as in the commonName field of the sender field
  transactionID               REQUIRED
    -- In the first message of a PKI management operation, MUST be
    --   128 bits of random data to minimize the probability of
    --   having the transactionID already in use at the server
    -- In all other messages, MUST be the value from the previous
    --   message in the same PKI management operation
  senderNonce                 REQUIRED
    -- MUST be cryptographically secure and fresh 128 random bits
  recipNonce                  RECOMMENDED
    -- If this is the first message of a transaction, MUST be absent
    -- If this is a delayed response message, MUST be present and
    --   contain the value of the senderNonce of the respective
    --   request message in the same transaction
    -- In all other messages, MUST be present and contain the value
    --   of the senderNonce of the previous message in the same
    --   transaction
  generalInfo                 OPTIONAL
    implicitConfirm           OPTIONAL
    -- RECOMMENDED in ir/cr/kur/p10cr messages,
    -- OPTIONAL in ip/cp/kup response messages, and
    -- PROHIBITED in other types of messages
    -- Added to request messages to request omission of the certConf
    --   message
    -- Added to response messages to grant omission of the certConf
    --   message
    -- See [RFC4210], Section 5.1.1.1.
      ImplicitConfirmValue   REQUIRED
    -- ImplicitConfirmValue MUST be NULL
    confirmWaitTime           OPTIONAL
    -- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
    --   not included
    -- PROHIBITED if implicitConfirm is included
    -- See [RFC4210], Section 5.1.1.2.
      ConfirmWaitTimeValue    REQUIRED
    -- ConfirmWaitTimeValue MUST be a GeneralizedTime value
    --   specifying the point in time up to which the PKI management
    --   entity will wait for the certConf message.  The accepted
    --   length of the waiting period will vary by use case.
    certProfile               OPTIONAL
    -- MAY be present in ir/cr/kur/p10cr and in genm messages of type
    --   id-it-certReqTemplate
    -- MUST be omitted in all other messages
    -- See [RFC9480].
      CertProfileValue        REQUIRED
    -- MUST contain a sequence of one UTF8String element
    -- MUST contain the name of a certificate profile

3.2. General Description of the CMP Message Protection

This section describes the generic protection field contents of all CMP messages. For signature-based protection, which is the default protection mechanism for all CMP messages described in this profile, the CMP protection key and CMP protection certificate are used. For MAC-based protection, shared secret information is used as described in Section 4.1.5.¶

protection
    -- If present, the same kind of protection MUST be used for all
    --   messages of that PKI management operation.
    -- MUST be present, except if protection is not possible for
    --   error messages as described in Section 3.6.4
    -- For signature-based protection, MUST contain the signature
    --   calculated using the CMP protection key of the entity
    --   protecting the message
    -- For MAC-based protection, MUST contain a MAC calculated using
    --   the shared secret information
    -- The protection algorithm used MUST be given in the
    --   protectionAlg field.

The CMP message protection provides, if available, message origin authentication and integrity protection for the header and body. The CMP message extraCerts field is not covered by this protection.¶

Note: The extended key usages described in Section 2.2 of CMP Updates [RFC9480] can be used for authorization of a sending PKI management entity.¶

3.3. General Description of CMP Message ExtraCerts

This section describes the generic extraCerts field of all CMP messages. Any specific requirements on the extraCerts are specified in the respective PKI management operation.¶

extraCerts
    -- MUST be present for signature-based protection and contain the
    --   CMP protection certificate together with its chain for the
    --   first request and response message of a PKI management
    --   operation.  MAY be omitted in certConf, PKIConf, pollReq,
    --   and pollRep messages.  The first certificate in this field
    --   MUST be the CMP protection certificate followed by its
    --   chain, where each element should directly certify the one
    --   immediately preceding it.
    -- MUST be present in ip, cp, and kup messages and contain the
    --   chain of a newly issued certificate.
    -- Self-signed certificates should be omitted from extraCerts and
    --   MUST NOT be trusted based on their inclusion in any case

Note: One reason for adding a self-signed certificate to extraCerts is if it is the CMP protection certificate or a successor root CA self-signed certificate as indicated in the HashOfRootKey extension of the current root CA certificate; see [RFC8649]. Another reason for including self-signed certificates in the extraCerts is, for instance, due to storage limitations. A receiving PKI entity may not have the complete trust anchor information available but just a unique identification of it and thus needs the full trust anchor information carried in a self-signed certificate for further processing (see Section 9).¶

For maximum interoperability, all implementations SHOULD be prepared to handle potentially additional certificates and arbitrary orderings of the certificates.¶

3.4. Generic PKI Management Operation Prerequisites

This subsection describes what is generally needed by the PKI entities to be able to perform PKI management operations.¶

Identification of PKI entities:¶

• For signature-based protection, each EE knows its own identity from the CMP protection certificate; for MAC-based protection, it MAY know its identity to fill the sender field.¶

• Each EE MAY know the intended recipient of its requests to fill the recipient field, e.g., the name of the addressed CA.¶

  Note: This name may be established using an enrollment voucher (as described in [RFC8366]), the issuer field from a CertReqTemplate response message content, or by other configuration means.¶

Routing of CMP messages:¶

• Each PKI entity sending messages upstream MUST know the address needed for transferring messages to the next PKI management entity in case online transfer is used.¶

  Note: This address may depend on the recipient, the certificate profile, and the used transfer mechanism.¶

Authentication of PKI entities:¶

• Each PKI entity MUST have credentials to authenticate itself. For signature-based protection, it MUST have a private key and the corresponding certificate along with its chain.¶

• Each PKI entity MUST be able to establish trust in the PKI it receives responses from. When signature-based protection is used, it MUST have the trust anchor(s) and any certificate status information needed to perform path validation of CMP protection certificates used for signature-based protection.¶

  Note: A trust anchor is usually a root certificate of the PKI addressed by the requesting EE. It may be established by configuration or in an out-of-band manner. For an EE, it may be established using an enrollment voucher [RFC8366] or in-band of CMP by the caPubs field in a certificate response message.¶

Authorization of PKI management operations:¶

• Each EE or RA MUST have sufficient information to be able to authorize the PKI management entity to perform the upstream PKI management operation.¶

  Note: This may be achieved, for example, by using the cmcRA extended key usage in server certificates, by local configuration (such as specific name patterns for subject Distinguished Name (DN) or Subject Alternative Name (SAN) portions that may identify an RA) and/or by having a dedicated root CA usable only for authenticating PKI management entities.¶

• Each PKI management entity MUST have sufficient information to be able to authorize the downstream PKI entity requesting the PKI management operation.¶

  Note: For authorizing an RA, the same examples apply as above. The authorization of EEs can be very specific to the application domain based on local PKI policy.¶

3.5. Generic Validation of a PKI Message

This section describes generic validation steps of each PKI entity receiving a PKI request or response message before any further processing or forwarding. If a PKI management entity decides to terminate a PKI management operation because a check failed, it MUST send a negative response or an error message as described in Section 3.6. The PKIFailureInfo bits given below in parentheses MAY be used in the failInfo field of the PKIStatusInfo as described in Section 3.6.4; also see Appendix F of [RFC4210].¶

All PKI message header fields not mentioned in this section, like the recipient and generalInfo fields, SHOULD be handled gracefully upon receipt.¶

The following list describes the basic set of message input validation steps. Without these checks, the protocol becomes dysfunctional.¶

• The formal ASN.1 syntax of the whole message MUST be compliant with the definitions given in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. (failInfo: badDataFormat)¶
• The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: unsupportedVersion)¶
• The transactionID MUST be present. (failInfo bit: badDataFormat)¶
• The PKI message body type MUST be one of the message types supported by the receiving PKI entity and MUST be allowed in the current state of the PKI management operation identified by the given transactionID. (failInfo bit: badRequest)¶

The following list describes the set of message input validation steps required to ensure secure protocol operation:¶

• The senderNonce MUST be present and MUST contain at least 128 bits of data. (failInfo bit: badSenderNonce)¶

• Unless the PKI message is the first message of a PKI management operation,¶

  • the recipNonce MUST be present and MUST equal the senderNonce of the previous message or equal the senderNonce of the most recent request message for which the response was delayed, in case of delayed delivery as specified in Section 4.4. (failInfo bit: badRecipientNonce)¶
• Messages without protection MUST be rejected except for error messages as described in Section 3.6.4.¶

• The message protection MUST be validated when present, and messages with an invalid protection MUST be rejected.¶

  • The protection MUST be signature-based except if MAC-based protection is used as described in Sections 4.1.5 and 4.1.6.3. (failInfo bit: wrongIntegrity)¶
  • If present, the senderKID MUST identify the key material needed for verifying the message protection. (failInfo bit: badMessageCheck)¶
  • If signature-based protection is used, the CMP protection certificate MUST be successfully validated, including path validation using a trust anchor, and MUST be authorized according to local policies. If the keyUsage extension is present in the CMP protection certificate, the digitalSignature bit MUST be set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)¶
  • The sender of a request message MUST be authorized to request the operation according to PKI policies. (failInfo bit: notAuthorized)¶

Note: The requirements for checking certificates given in [RFC5280] MUST be followed for signature-based CMP message protection. Unless the message is a positive ip/cp/kup, where the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking SHOULD be performed on the CMP protection certificates. If the response message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is REQUIRED. For other cases, it MAY be acceptable to omit certificate status checking when respective information is not available.¶

Depending on local policies, one or more of the input validation checks described below need to be implemented:¶

• If signature-based protection is used, the sender field MUST match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck)¶

• If the messageTime is present and¶

  • the receiving system has a reliable system time, the messageTime MUST be close to the current time of the receiving system, where the threshold will vary by use case. (failInfo bit: badTime)¶
  • the receiving system does not have a reliable system time, the messageTime MAY be used for time synchronization.¶

3.6. Error Handling

This section describes how a PKI entity handles error conditions on messages it receives. Each error condition should be logged appropriately to allow root-cause analysis of failure cases.¶

Error Message -- error

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message indicating the error that occurred
  error                       REQUIRED
    pKIStatusInfo             REQUIRED
      status                  REQUIRED
    -- MUST have the value "rejection"
      statusString            OPTIONAL
    -- This field should contain any human-readable text for
    --   debugging, for logging, or to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present and contain the relevant PKIFailureInfo bits

protection                    RECOMMENDED
    -- As described in Section 3.2

extraCerts                    RECOMMENDED
    -- As described in Section 3.3

4.1. Enrolling End Entities

There are various approaches for requesting a certificate from a PKI.¶

These approaches differ in the way the EE authenticates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as follows:¶

• using a certificate from an external PKI, e.g., a manufacturer-issued device certificate, and the corresponding private key¶
• using a private key and certificate issued from the same PKI that is addressed for requesting a certificate¶
• using the certificate to be updated and the corresponding private key¶
• using shared secret information known to the EE and the PKI management entity¶

An EE requests a certificate indirectly or directly from a CA. When the PKI management entity handles the request as described in Section 5.1.1 and responds with a message containing the requested certificate, the EE MUST reply with a confirmation message unless implicitConfirm was granted. The PKI management entity MUST then handle it as described in Section 5.1.2 and respond with a confirmation, closing the PKI management operation.¶

The message sequences described in this section allow the EE to request certification of a locally or centrally generated public-private key pair. The public key and the subject name identifying the EE MUST be present in the certTemplate of the certificate request message.¶

Note: If the EE does not know for which subject name to request the certificate, it can use the subject name from the CMP protection certificate in case of signature-based protection or the identifier of the shared secret in case of MAC-based protection.¶

Typically, the EE provides a signature-based proof-of-possession of the private key associated with the public key contained in the certificate request, as defined by [RFC4211], Section 4.1, clause 3. To this end, it is assumed that the private key can technically be used for signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA, regardless of potentially intended restrictions of the key usage.¶

Note: Section 4 of [RFC4211] allows for providing proof-of-possession using any method that a key can be used for. In conformance with Section 8.1.5.1.1.2 of [NIST.SP.800-57p1r5], the newly generated private key may be used for self-signature, if technically possible, even if the keyUsage extension requested in the certificate request prohibits generation of digital signatures.¶

The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request message containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions.¶

The proof-of-possession is provided by signing the certReq containing the certTemplate with the subject name and public key. To bind this proof-of-possession to the proof-of-identity of the requesting EE, the subject name in the certTemplate needs to identify the same entity as the subject name in the CMP protection certificate or match the identifier used with MAC-based protection.¶

Note: This binding may be lost if a PKI management entity reprotects this request message.¶

The EE MAY indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message as described in Section 3.1.¶

In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it MUST properly authenticate the message and authorize the sender as a trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an Initialization Response (ip) message. Authorization can also be signature-based, using a certificate issued by another PKI that is explicitly authorized for this purpose. A certificate received in caPubs MUST NOT be accepted as a trust anchor if it is the root CA certificate of the certificate used for protecting the message.¶

Step# EE                                  PKI management entity
  1   format ir
  2                      ->   ir      ->
  3                                        handle or
                                             forward ir
  4                                        format or receive ip
  5                                        possibly grant
                                             implicitConfirm
  6                      <-   ip      <-
  7   handle ip

-----------------  if implicitConfirm not granted  -----------------

  8   format certConf
  9                      ->   certConf ->
 10                                        handle or
                                             forward certConf
 11                                        format or receive pkiConf
 12                      <-   pkiConf  <-
 13   handle pkiConf

Initialization Request -- ir

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE for a new certificate
  ir                          REQUIRED
    -- MUST contain a sequence of one CertReqMsg
    -- If more certificates are required, further PKI management
    --   operations needs to be initiated
    certReq                   REQUIRED
      certReqId               REQUIRED
    -- MUST be 0
      certTemplate            REQUIRED
        version               OPTIONAL
    -- MUST be 2 if supplied
        subject               REQUIRED
    -- The EE's identity MUST be carried in the subject field
    --   and/or the subjectAltName extension.
    -- If subject name is present only in the subjectAltName
    --   extension, then the subject field MUST be NULL-DN
        publicKey             OPTIONAL
    -- MUST be present if local key generation is used
    -- MAY be absent if central key generation is requested
          algorithm           OPTIONAL
    -- MUST be present if local key generation is used and MUST
    --   include the subject public key algorithm identifier
    -- MAY be present if central key generation is requested and,
    --   if present, informs the KGA of algorithm and parameter
    --   preferences regarding the to-be-generated key pair
          subjectPublicKey    REQUIRED
    -- MUST contain the public key to be certified in case of local
    --   key generation
    -- MUST be a zero-length BIT STRING if central key generation
    --   is requested
        extensions            OPTIONAL
    -- MAY include end-entity-specific X.509 extensions of the
    --   requested certificate, like subject alternative name, key
    --   usage, and extended key usage
    -- The subjectAltName extension MUST be present if the EE subject
    --   name includes a subject alternative name.
    popo                      OPTIONAL
    -- MUST be present if local key generation is used
    -- MUST be absent if central key generation is requested
      signature               OPTIONAL
    -- MUST be used by an EE if the key can be used for signing, and
    --   if used, it MUST have the type POPOSigningKey
        poposkInput           PROHIBITED
    -- MUST NOT be used; it is not needed because subject and
    --   publicKey are both present in the certTemplate
        algorithmIdentifier   REQUIRED
    -- The signature algorithm MUST be consistent with the publicKey
    --   algorithm field of the certTemplate
        signature             REQUIRED
    -- MUST contain the signature value computed over the DER-encoded
    --   certReq
      raVerified              OPTIONAL
    -- MAY be used by an RA after verifying the proof-of-possession
    --   provided by the EE

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3


Initialization Response -- ip

Field                         Value

header
    -- As described in Section 3.1

body
    -- The response of the CA to the request as appropriate
  ip                          REQUIRED
    caPubs                    OPTIONAL
    -- MAY be used if the certifiedKeyPair field is present
    -- If used, it MUST contain only a trust anchor, e.g., root
    --   certificate, of the certificate contained in certOrEncCert
    response                  REQUIRED
    -- MUST contain a sequence of one CertResponse
      certReqId              REQUIRED
    -- MUST be 0
      status                  REQUIRED
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- positive values allowed: "accepted", "grantedWithMods"
    -- negative values allowed: "rejection"
    -- "waiting" only allowed with a polling use case as described
    --   in Section 4.4
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or
    --   to display in a GUI
        failInfo              OPTIONAL
    -- MAY be present if status is "rejection"
    -- MUST be absent if status is "accepted" or "grantedWithMods"
      certifiedKeyPair        OPTIONAL
    -- MUST be present if status is "accepted" or "grantedWithMods"
    -- MUST be absent if status is "rejection"
        certOrEncCert         REQUIRED
    -- MUST be present if status is "accepted" or "grantedWithMods"
          certificate         REQUIRED
    -- MUST be present when certifiedKeyPair is present
    -- MUST contain the newly enrolled X.509 certificate
        privateKey            OPTIONAL
    -- MUST be absent in case of local key generation or "rejection"
    -- MUST contain the encrypted private key in an EnvelopedData
    --   structure as specified in Section 4.1.6 in case the
    --   private key was generated centrally

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3
    -- MUST contain the chain of the certificate present in
    --   certOrEncCert
    -- Duplicate certificates MAY be omitted


Certificate Confirmation -- certConf

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE sends a confirmation to the PKI
    --   management entity to accept or reject the issued
    --   certificates
  certConf                    REQUIRED
    -- MUST contain a sequence of one CertStatus
    CertStatus                REQUIRED
      certHash                REQUIRED
    -- The hash algorithm to use MUST be the hash algorithm indicated
    --   in the below hashAlg field.  If the hashAlg field is not
    --   set, it MUST be the hash algorithm defined by the algorithm
    --   identifier of the certificate signature or the dedicated
    --   hash algorithm defined in [RFC9481] for the used certificate
    --   signature algorithm.
      certReqId               REQUIRED
    -- MUST be 0
      statusInfo              OPTIONAL
    -- PKIStatusInfo structure should be present
    -- Omission indicates acceptance of the indicated certificate
        status                REQUIRED
    -- positive values allowed: "accepted"
    -- negative values allowed: "rejection"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or
    --   to display in a GUI
        failInfo              OPTIONAL
    -- MAY be present if status is "rejection"
    -- MUST be absent if status is "accepted"
      hashAlg                 OPTIONAL
    -- The hash algorithm to use for calculating the above certHash
    -- If used, the pvno field in the header MUST be cmp2021 (3).
    --   For backward compatibility, use of this field is
    --   NOT RECOMMENDED if the hash algorithm to use can be
    --   identified by other means; see above.

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first request message
    --   of this PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the PKI
    --   management entity caches the CMP protection certificate from
    --   the first request message of this PKI management operation


PKI Confirmation -- pkiConf

Field                         Value

header
    -- As described in Section 3.1

body
  pkiconf                     REQUIRED
    -- The content of this field MUST be NULL

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first response
    --   message of this PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the EE has
    --   cached the CMP protection certificate from the first
    --   response message of this PKI management operation

    controls
      type                    RECOMMENDED
    -- MUST be the value id-regCtrl-oldCertID, if present
      value
        issuer                REQUIRED
        serialNumber          REQUIRED
    -- MUST contain the issuer and serialNumber of the certificate
    --   to be updated

Certification Request -- p10cr

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE for a new certificate using a PKCS #10
    --   certificate request
  p10cr                       REQUIRED
    certificationRequestInfo  REQUIRED
      version                 REQUIRED
    -- MUST be 0 to indicate PKCS #10 v1.7
      subject                 REQUIRED
    -- The EE subject name MUST be carried in the subject field
    --   and/or the subjectAltName extension.
    -- If subject name is present only in the subjectAltName
    --   extension, then the subject field MUST be NULL-DN
      subjectPKInfo           REQUIRED
        algorithm             REQUIRED
    -- MUST include the subject public key algorithm identifier
        subjectPublicKey      REQUIRED
    -- MUST include the public key to be certified
      attributes              OPTIONAL
    -- MAY include end-entity-specific X.509 extensions of the
    --   requested certificate like subject alternative name,
    --   key usage, and extended key usage
    -- The subjectAltName extension MUST be present if the EE
    --   subject name includes a subject alternative name.
    signatureAlgorithm        REQUIRED
    -- The signature algorithm MUST be consistent with the
    --   subjectPKInfo field.
    signature                 REQUIRED
    -- MUST contain the self-signature for proof-of-possession

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described for the underlying PKI management operation

+----------------------------------+
| EnvelopedData                    |
| [RFC5652], Section 6             |
| +------------------------------+ |
| | SignedData                   | |
| | [RFC5652], Section 5         | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage     | | |
| | | [RFC5958]                | | |
| | | +----------------------+ | | |
| | | | private key          | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+

        privateKey            REQUIRED
    -- MUST be an EnvelopedData structure, as specified in
    --   Section 6 of CMS [RFC5652]
          version             REQUIRED
    -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
    --   KeyTransRecipientInfo
    -- MUST be 0 for recipientInfo type PasswordRecipientInfo
          recipientInfos      REQUIRED
    -- MUST contain a sequence of one RecipientInfo, which MUST be
    --   ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
    --   kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
    --   pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
          encryptedContentInfo
                              REQUIRED
            contentType       REQUIRED
    -- MUST be id-signedData
            contentEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the algorithm used for
    --   content encryption
    -- The algorithm type MUST be PROT_SYM_ALG as specified in
    --   [RFC9481], Section 5
            encryptedContent  REQUIRED
    -- MUST be the SignedData structure, as specified in Section 5
    -- of CMS [RFC5652] and [RFC8933], in encrypted form
              version         REQUIRED
    -- MUST be 3
              digestAlgorithms
                              REQUIRED
    -- MUST contain a sequence of one AlgorithmIdentifier element
    -- MUST be the algorithm identifier of the digest algorithm
    --   used for generating the signature and match the signature
    --   algorithm specified in signatureAlgorithm; see [RFC8933]
              encapContentInfo
                              REQUIRED
    -- MUST contain the content that is to be signed
                eContentType  REQUIRED
    -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
                eContent      REQUIRED
    -- MUST be of type AsymmetricKeyPackage and
    -- MUST contain a sequence of one OneAsymmetricKey element
                  version     REQUIRED
    -- MUST be 1 (indicating v2)
                  privateKeyAlgorithm
                              REQUIRED
    -- The privateKeyAlgorithm field MUST contain the algorithm
    --   identifier of the asymmetric key pair algorithm
                  privateKey  REQUIRED
                  publicKey   REQUIRED
    -- MUST contain the public key corresponding to the private key
    --   for simplicity and consistency with v2 of OneAsymmetricKey
              certificates    REQUIRED
    -- MUST contain the certificate for the private key used to sign
    --   the signedData content, together with its chain
    -- The first certificate in this field MUST be the KGA
    --   certificate used for protecting this content
    -- Self-signed certificates should not be included and MUST NOT
    --   be trusted based on their inclusion in any case
                signerInfos   REQUIRED
    -- MUST contain a sequence of one SignerInfo element
                version       REQUIRED
    -- MUST be 3
                sid           REQUIRED
                  subjectKeyIdentifier
                              REQUIRED
    -- MUST be the subjectKeyIdentifier of the KGA certificate
                digestAlgorithm
                              REQUIRED
    -- MUST be the same as in the digestAlgorithms field of
    --   encryptedContent
                signedAttrs   REQUIRED
    -- MUST contain an id-contentType attribute containing the value
    --   id-ct-KP-aKeyPackage
    -- MUST contain an id-messageDigest attribute containing the
    --   message digest of eContent
    -- MAY contain an id-signingTime attribute containing the time
    --   of a signature.  It SHOULD be omitted if the transactionTime
    --   field is not present in the PKIHeader.
    -- For details on the signed attributes, see Sections 5.3 and
    --   11 of CMS [RFC5652] and [RFC8933]
                signatureAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the signature algorithm
    --   used for calculation of the signature bits
    -- The signature algorithm type MUST be MSG_SIG_ALG, as
    --   specified in [RFC9481], Section 3, and MUST be consistent
    --   with the subjectPublicKeyInfo field of the KGA certificate
                signature     REQUIRED
    -- MUST be the digital signature of the encapContentInfo

            ktri              REQUIRED
    -- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
    --   of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 2
              rid             REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the rKeyId choice, and the
    --   subjectKeyIdentifier MUST equal the senderKID in the
    --   PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used.
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key transport
    --   algorithm.  The algorithm type MUST be KM_KT_ALG as
    --   specified in [RFC9481], Section 4.2
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

            kari              REQUIRED
    -- MUST be KeyAgreeRecipientInfo as specified in Section
    --   6.2.2 of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 3
              originator      REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the subjectKeyIdentifier
    --   choice, and the subjectKeyIdentifier MUST equal the
    --   senderKID in the PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used.
              ukm             RECOMMENDED
    -- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
    --   (ECMQV) is used; see [RFC5753]
    -- SHOULD be present to ensure uniqueness of the key
    --   encryption key
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key agreement
    --   algorithm
    -- The algorithm type MUST be KM_KA_ALG as specified in
    --   [RFC9481], Section 4.1
    -- The parameters field of the key agreement algorithm MUST
    --   contain the key wrap algorithm.  The algorithm type
    --   MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
              recipientEncryptedKeys
                              REQUIRED
    -- MUST contain a sequence of one RecipientEncryptedKey
                rid           REQUIRED
    -- MUST contain the subjectKeyIdentifier of the CMP protection
    --   certificate, if available, in the rKeyId choice, and the
    --   subjectKeyIdentifier MUST equal the senderKID in the
    --   PKIHeader.
    -- If the CMP protection certificate does not contain a
    --   subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
    --   be used
                  encryptedKey
                              REQUIRED
    -- MUST be the encrypted content-encryption key

            pwri              REQUIRED
    -- MUST be PasswordRecipientInfo as specified in
    --   Section 6.2.4 of CMS [RFC5652]
              version         REQUIRED
    -- MUST be 0
              keyDerivationAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key derivation
    --   algorithm
    -- The algorithm type MUST be KM_KD_ALG as specified in
    --   [RFC9481], Section 4.4
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key wrap algorithm
    -- The algorithm type MUST be KM_KW_ALG as specified in
    --   [RFC9481], Section 4.3
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

4.2. Revoking a Certificate

This PKI management operation should be used by an entity to request revocation of a certificate. Here, the revocation request is used by an EE to revoke one of its own certificates.¶

The revocation request message MUST be signed using the certificate that is to be revoked to prove the authorization to revoke. The revocation request message is signature-protected using this certificate. This requires that the EE still possesses the private key. If this is not the case, the revocation has to be initiated by other means, e.g., revocation by the RA, as specified in Section 5.3.2.¶

An EE requests revoking a certificate of its own at the CA that issued this certificate. The PKI management entity handles the request as described in Section 5.1.3, and responds with a message that contains the status of the revocation from the CA.¶

The specific prerequisite augmenting the prerequisites in Section 3.4 is as follows:¶

• The certificate the EE wishes to revoke is not yet expired or revoked.¶

Message Flow:¶

Step# EE                                  PKI management entity
 1   format rr
 2                      ->   rr      ->
 3                                        handle or forward rr
 4                                        format or receive rp
 5                      <-   rp      <-
 6   handle rp

For this PKI management operation, the EE MUST include a sequence of one RevDetails structure in the rr message body. In the case no generic error occurred, the response to the rr MUST be an rp message containing a single status field.¶

Detailed Message Description:¶

Revocation Request -- rr

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE to revoke its certificate
  rr                          REQUIRED
    -- MUST contain a sequence of one element of type RevDetails
    -- If more revocations are desired, further PKI management
    --   operations need to be initiated
    certDetails               REQUIRED
    -- MUST be present and is of type CertTemplate
      serialNumber            REQUIRED
    -- MUST contain the certificate serialNumber attribute of the
    --   certificate to be revoked
      issuer                  REQUIRED
    -- MUST contain the issuer attribute of the certificate to be
    --   revoked
    crlEntryDetails           REQUIRED
    -- MUST contain a sequence of one reasonCode of type CRLReason
    --   (see [RFC5280], Section 5.3.1)
    -- If the reason for this revocation is not known or shall not
    --   be published, the reasonCode MUST be 0 (unspecified)
protection                    REQUIRED
    -- As described in Section 3.2 and using the private key related
    --   to the certificate to be revoked

extraCerts                    REQUIRED
    -- As described in Section 3.3


Revocation Response -- rp

Field                         Value

header
    -- As described in Section 3.1

body
    -- The response of the PKI management entity to the request as
    --   appropriate
  rp                          REQUIRED
    status                    REQUIRED
    -- MUST contain a sequence of one element of type PKIStatusInfo
      status                  REQUIRED
    -- positive value allowed: "accepted"
    -- negative value allowed: "rejection"
      statusString            OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or
    --   to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present if the status is "rejection"
    -- MUST be absent if the status is "accepted"

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3

4.3. Support Messages

The following support messages offer on-demand, in-band delivery of content relevant to the EE provided by a PKI management entity. CMP general messages and general response are used for this purpose. Depending on the environment, these requests may be answered by an RA or CA (see also Section 5.1.4).¶

The general messages and general response messages contain InfoTypeAndValue structures. In addition to those infoType values defined in [RFC4210] and CMP Updates [RFC9480], further OIDs MAY be used to define new PKI management operations or new general-purpose support messages as needed in specific environments.¶

The following contents are specified in this document:¶

• Get CA certificates.¶
• Get root CA certificate update.¶
• Get certificate request template.¶
• Get new Certificate Revocation Lists (CRLs).¶

The following message flow and contents are common to all general message (genm) and general response (genp) messages.¶

Message Flow:¶

Step# EE                                   PKI management entity
 1   format genm
 2                      ->   genm    ->
 3                                        handle or forward genm
 4                                        format or receive genp
 5                      <-   genp    <-
 6   handle genp

Detailed Message Description:¶

General Message -- genm

Field                         Value

header
    -- As described in Section 3.1

body
    -- A request by the EE for information
  genm                        REQUIRED
    -- MUST contain a sequence of one element of type
    --   InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying one of the specific PKI
    --   management operations described below
    infoValue                 OPTIONAL
    -- MUST be as specified for the specific PKI management operation

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3


General Response -- genp

Field                         Value

header
    -- As described in Section 3.1

body
    -- The response of the PKI management entity providing
    --   information
  genp                        REQUIRED
    -- MUST contain a sequence of one element of type
    --   InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying the specific PKI management
    --   operation described below
    infoValue                 OPTIONAL
    -- MUST be as specified for the specific PKI management operation

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3

      infoValue               OPTIONAL
    -- MUST be absent if no CA certificate is available
    -- MUST be present if CA certificates are available
    --   if present, MUST be a sequence of CMPCertificate

      infoValue               RECOMMENDED
    -- MUST contain the root CA certificate to be updated if needed
    --   for unique identification

      infoValue               OPTIONAL
    -- MUST be absent if no update of the root CA certificate is
    --   available
    -- MUST be present if an update of the root CA certificate
    --   is available and MUST be of type RootCaKeyUpdateContent
        newWithNew            REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the new root CA certificate
        newWithOld            REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain a certificate containing the new public
    --   root CA key signed with the old private root CA key
        oldWithNew            OPTIONAL
    -- MAY be present if infoValue is present
    -- MUST contain a certificate containing the old public
    --   root CA key signed with the new private root CA key

      InfoValue               OPTIONAL
    -- MUST be absent if no requirements are available
    -- MUST be present if the PKI management entity has any
    --   requirements on the contents of the certificate template
        certTemplate          REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the required CertTemplate structure elements
    -- The SubjectPublicKeyInfo field MUST be absent
        keySpec               OPTIONAL
    -- MUST be absent if no requirements on the public key are
    --   available
    -- MUST be present if the PKI management entity has any
    --   requirements on the keys generated
    -- MUST contain a sequence of one AttributeTypeAndValue per
    --   supported algorithm with attribute id-regCtrl-algId or
    --   id-regCtrl-rsaKeyLen

      infoValue               REQUIRED
    -- MUST contain a sequence of one CRLStatus element
        source                REQUIRED
    -- MUST contain the dpn choice of type DistributionPointName if
    --   the CRL distribution point name is available
    -- Otherwise, MUST contain the issuer choice identifying the CA
    --   that issues the CRL.  It MUST contain the issuer DN in the
    --   directoryName field of a GeneralName element.
        thisUpdate            OPTIONAL
    -- MUST contain the thisUpdate field of the latest CRL the EE
    --   has gotten from the issuer specified in the given dpn or
    --   issuer field
    -- MUST be omitted if the EE does not have any instance of the
    --   requested CRL

      infoValue               OPTIONAL
    -- MUST be absent if no CRL to be returned is available
    -- MUST contain a sequence of one CRL update from the referenced
    --   source if a thisUpdate value was not given or a more recent
    --   CRL is available

4.4. Handling Delayed Delivery

This is a variant of all PKI management operations described in this document. It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication or due to delays in handling the request. The polling mechanism has been specified in Section 5.3.22 of [RFC4210] and updated by [RFC9480].¶

Depending on the PKI architecture, the entity initiating delayed delivery is not necessarily the PKI management entity directly addressed by the EE.¶

When initiating delayed delivery of a message received from an EE, the PKI management entity MUST respond with a message including the status "waiting". In response to an ir/cr/kur/p10cr message, it must place the status "waiting" in an ip/cp/kup message and for responses to other request message types in an error message. On receiving this response, the EE MUST store in its transaction context the senderNonce of the preceding request message because this value will be needed for checking the recipNonce of the final response to be received after polling. It sends a poll request with certReqId 0 if referring to the CertResponse element contained in the ip/cp/kup message, else -1 to refer to the whole message. In case the final response is not yet available, the PKI management entity that initiated the delayed delivery MUST answer with a poll response with the same certReqId. The included checkAfter time value indicates the minimum number of seconds that should elapse before the EE sends a new pollReq message to the PKI management entity. Polling earlier than indicated by the checkAfter value may increase the number of message round trips. This is repeated until a final response is available or any party involved gives up on the current PKI management operation, i.e., a timeout occurs.¶

When the PKI management entity that initiated delayed delivery can provide the final response for the original request message of the EE, it MUST send this response to the EE. Using this response, the EE can continue the current PKI management operation as usual.¶

No specific prerequisites apply in addition to those of the respective PKI management operation.¶

Message Flow:¶

Step# EE                                  PKI management entity
 1   format request
       message
 2                  ->     request     ->
 3                                        handle or forward
                                            request
 4                                        format ip/cp/kup/error
                                            with status "waiting"
                                            response in case no
                                            immediate final response
                                            is available
 5                   <- ip/cp/kup/error <-
 6   handle
       ip/cp/kup/error
       with status
       "waiting"

--------------------------  start polling  --------------------------

 7   format pollReq
 8                     ->    pollReq   ->
 9                                        handle or forward pollReq
10                                        in case the final response
                                            for the original request
                                            is available, continue
                                            with step 14
                                          otherwise, format or
                                            receive pollRep with
                                            checkAfter value
11                     <-    pollRep   <-
12   handle pollRep
13   let checkAfter
       time elapse and
       continue with
       step 7

-----------------  end polling, continue as usual  ------------------

14                                        format or receive
                                            final response on
                                            the original request
15                     <-   response   <-
16   handle final
       response

Detailed Message Description:¶

Response with Status "waiting" -- ip/cp/kup/error

Field                         Value

header
    -- As described in Section 3.1

body
    -- As described for the respective PKI management operation, with
    --   the following adaptations:
      status                  REQUIRED -- in case of ip/cp/kup
      pKIStatusInfo           REQUIRED -- in case of error response
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- MUST be status "waiting"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or
    --   to display in a GUI
        failInfo              PROHIBITED

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    OPTIONAL
    -- As described in Section 3.3


Polling Request -- pollReq

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE asking for the final response or for a
    --   time to check again
  pollReq                     REQUIRED
    certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first request message
    --   of the PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the PKI
    --   management entity caches the CMP protection certificate from
    --   the first request message of the PKI management operation


Polling Response -- pollRep

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message indicates the delay after which the EE SHOULD
    --   send another pollReq message for this transaction
  pollRep                     REQUIRED
    certReqId                 REQUIRED
    -- MUST be 0 if referring to a CertResponse element, else -1
    checkAfter                REQUIRED
    -- MUST be the time in seconds to elapse before a new pollReq
    --   should be sent
    reason                    OPTIONAL
    -- MAY be any human-readable text for debugging, for logging, or
    --   to display in a GUI

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same credentials as in the first response
    --   message of the PKI management operation

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- MAY be omitted if the message size is critical and the EE has
    --   cached the CMP protection certificate from the first
    --   response message of the PKI management operation


Final Response - Any Type of Response Message

Field                         Value

header
    -- MUST be the header, as described for the response message
    --   of the respective PKI management operation

body
    -- The response of the PKI management entity to the initial
    --   request, as described in the respective PKI management
    --   operation

protection                    REQUIRED
    -- MUST be as described for the response message of the
    --   respective PKI management operation

extraCerts                    REQUIRED
    -- MUST be as described for the response message of the
    --   respective PKI management operation

5.1. Responding to Requests

The PKI management entity terminating the PKI management operation at CMP level MUST respond to all received requests by returning a related CMP response message or an error. Any intermediate PKI management entity MAY respond, depending on the PKI configuration and policy.¶

In addition to the checks described in Section 3.5, the responding PKI management entity MUST check that a request that initiates a new PKI management operation does not use a transactionID that is currently in use. The failInfo bit value to use is transactionIdInUse as described in Section 3.6.4. If any of these verification steps or any of the essential checks described in Section 3.5 and in the following subsections fails, the PKI management entity MUST proceed as described in Section 3.6.¶

The responding PKI management entity MUST copy the sender field of the request to the recipient field of the response, MUST copy the senderNonce of the request to the recipNonce of the response, and MUST use the same transactionID for the response.¶

5.2. Forwarding Messages

In case the PKI solution consists of intermediate PKI management entities (i.e., LRA or RA), each CMP request message coming from an EE or any other downstream PKI management entity MUST either be forwarded to the next (upstream) PKI management entity as described in this section, or answered as described in Section 5.1. Any received response message or a locally generated error message MUST be forwarded to the next (downstream) PKI entity.¶

In addition to the checks described in Section 3.5, the forwarding PKI management entity MAY verify the proof-of-possession for ir/cr/kur/p10cr messages. If one of these verification procedures fails, the RA proceeds as described in Section 3.6.¶

A PKI management entity SHOULD NOT change the received message unless its role in the PKI system requires it. This is because changes to the message header or body imply reprotection. Changes to the protection breaks end-to-end authentication of the message source. Changes to the certificate template in a certificate request breaks proof-of-possession. More details are available in the following subsections. Concrete PKI system specifications may define when to do so in more detail.¶

This is particularly relevant in the upstream communication of a request message.¶

Each forwarding PKI management entity has one or more functionalities. It may:¶

• verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,¶
• add or modify fields of certificate request messages,¶
• replace a MAC-based protection with a signature-based protection that can also be verified further upstream and vice versa,¶
• double-check if the messages transferred back and forth are properly protected and well-formed,¶
• provide an authentic indication that it has performed all required checks,¶
• initiate a delayed delivery due to delays transferring messages or handling requests, or¶
• collect messages from multiple RAs and forward them jointly.¶

Note: PKI management entities forwarding messages may also store data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.¶

The decision if a message should be forwarded is:¶

• unchanged with the original protection,¶
• unchanged with an additional protection, or¶
• changed with an additional protection¶

depending on the PKI solution design and the associated security policy, e.g., as defined in the certificate policy (CP) / certification practice statement (CPS) documents [RFC3647].¶

A PKI management entity SHOULD add or MAY replace a protection of a message if it¶

• needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entities or¶
• needs to protect the message using a key and certificate from a different PKI.¶

If retaining end-to-end message authentication is required, an additional protection SHALL be added instead of replacing the original protection.¶

A PKI management entity MUST replace a protection of a message if it¶

• performs changes to the header or the body of the message or¶
• needs to convert from or to a MAC-based protection.¶

This is particularly relevant in the upstream communication of certificate request messages.¶

Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity MAY change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certificates to support subsequent PKI entities. This may be particularly helpful to augment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constrained devices.¶

Nested Message - nested

Field                         Value

header
    -- As described in Section 3.1

body
    -- Container to provide additional protection to original
    --   messages and to bundle request messages or alternatively
    --   response messages
  PKIMessages                 REQUIRED
    -- MUST be a sequence of one or more CMP messages

protection                    REQUIRED
    -- As described in Section 3.2, using the CMP protection key of
    --   the PKI management entity

extraCerts                    REQUIRED
    -- As described in Section 3.3

Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive response
 5                      <-  response <-
 6   forward response

Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive nested
 5                      <-  nested   <-
 6   handle nested

    popo
      raVerified              REQUIRED
    -- MUST have the value NULL and indicates that the PKI
    --   management entity verified the popo of the original message

5.3. Acting on Behalf of Other PKI Entities

A PKI management entity may need to request a PKI management operation on behalf of another PKI entity. In this case, the PKI management entity initiates the respective PKI management operation as described in Section 4, acting in the role of the EE.¶

Note: The request message protection will not authenticate the EE, but it will authenticate the RA acting on behalf of the EE.¶

6.1. HTTP Transfer

This transfer mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transfer is used, the specifications described in [RFC6712] and updated by CMP Updates [RFC9480] MUST be followed.¶

PKI management operations MUST use a URI path consisting of '/.well-known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 3.3 of CMP Updates [RFC9480]. It SHOULD be followed by an operation label depending on the type of PKI management operation.¶

If operation labels are used:¶

• independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.¶
• any certConf or pollReq messages SHALL be sent to the same endpoint as determined by the PKI management operation.¶
• when a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.¶

By sending a request to its preferred endpoint, the PKI entity will recognize, via the HTTP response status code, whether a configured URI is supported by the PKI management entity.¶

In case a PKI management entity receives an unexpected HTTP status code from upstream, it MUST respond downstream with an error message as described in Section 3.6, using a failInfo bit corresponding to the status code, e.g., systemFailure.¶

For certificate management, the major security goal is integrity and data origin authentication. For delivery of centrally generated keys, confidentiality is also a must. These goals are sufficiently achieved by CMP itself, also in an end-to-end fashion.¶

If a second line of defense is required or general privacy concerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in [RFC9110]. In addition, the recommendations provided in [RFC9325] should be followed.¶

Note: The requirements for checking certificates given in [RFC5280] and either [RFC5246] or [RFC8446] must be followed for the TLS layer. Certificate status checking should be used for the TLS certificates of all communication partners.¶

TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication are available, e.g., a PKI management operation with MAC-based protection is used.¶

Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authentication. A pre-shared key (PSK) mechanism may be used with shared secret information with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.¶

Note: The provisioning of client certificates and PSKs is out of scope of this document.¶

6.2. CoAP Transfer

This transfer mechanism can be used by a PKI entity to transfer CMP messages over CoAP [RFC7252], e.g., in constrained environments. If CoAP transfer is used, the specifications described in CMP over CoAP [RFC9482] MUST be followed.¶

PKI management operations MUST use a URI path consisting of '/.well-known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 2.1 of CMP over CoAP [RFC9482]. It SHOULD be followed by an operation label depending on the type of PKI management operation.¶

If operation labels are used:¶

• independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.¶
• any certConf or pollReq messages SHALL be sent to the same endpoint, as determined by the PKI management operation.¶
• when a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.¶

By sending a request to its preferred endpoint, the PKI entity will recognize, via the CoAP response status code, whether a configured URI is supported by the PKI management entity. The CoAP-inherent discovery mechanisms MAY also be used.¶

In case a PKI management entity receives an unexpected CoAP status code from upstream, it MUST respond downstream with an error message, as described in Section 3.6, using a failInfo bit corresponding to the status code, e.g., systemFailure.¶

Like for HTTP transfer, to offer a second line of defense or to provide hop-by-hop privacy protection, DTLS may be utilized as described in CMP over CoAP [RFC9482]. If DTLS is utilized, the same boundary conditions (peer authentication, etc.) as those stated for TLS to protect HTTP transfer in Section 6.1 apply to DTLS likewise.¶

Note: The provisioning of client certificates and PSKs is out of scope of this document.¶

6.3. Piggybacking on Other Reliable Transfer

CMP messages MAY also be transferred on some other reliable protocol, e.g., Extensible Authentication Protocol (EAP) or Message Queuing Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms similar to those specified for HTTP in [RFC6712] need to be implemented.¶

A more detailed specification is out of scope of this document and would need to be given, for instance, in the scope of the transfer protocol used.¶

6.4. Offline Transfer

For transferring CMP messages between PKI entities, any mechanism that is able to store and forward binary objects of sufficient length and with sufficient reliability while preserving the order of messages for each transaction can be used.¶

The transfer mechanism should be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases, the PKI entities MUST report an error as specified in Section 3.6, as far as possible.¶

7.1. PKI Management Operations

The following table provides an overview of the PKI management operations specified in Sections 4 and 5 and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, or not applicable. Variants amend or change behavior of base PKI management operations and are therefore also included.¶

The PKI management operation specifications in Section 4 assume that either the RA or CA is the PKI management entity that terminates the Certificate Management Protocol. If the RA terminates CMP, it either responds directly as described in Section 5.1, or it forwards the certificate management operation towards the CA not using CMP. Section 5.2 describes different options of how an RA can forward a CMP message using CMP. Section 5.3 offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in Section 4.¶

1)

The RA should be able to change the CMP message protection from MAC-based to signature-based protection; see Section 5.2.3.1.¶

2)

The RA should be able to request certificate revocation on behalf of an EE (see Section 5.3.2), e.g., in order to handle incidents.¶

3)

An alternative would be to perform revocation at the CA without using CMP, for instance, using a local administration interface.¶

7.2. Message Transfer

CMP does not have specific needs regarding message transfer, except that, for each request message sent, eventually a sequence of one response message should be received. Therefore, virtually any reliable transfer mechanism can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this document does not require any specific transfer protocol to be supported by conforming implementations.¶

On different links between PKI entities (e.g., EE-RA and RA-CA), different transfer mechanisms, as specified in Section 6, may be used.¶

HTTP SHOULD be supported and CoAP MAY be supported at all PKI entities for maximizing general interoperability at transfer level. Yet full flexibility is retained to choose whatever transfer mechanism is suitable, for instance, for devices and system architectures with specific constraints.¶

The following table lists the name and level of support specified for each transfer mechanism.¶