Lightweight Certificate Management Protocol (CMP) Profile

1.1. Motivation for profiling 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.¶

Though CMP is a very solid and capable protocol it is so far not used very widely. The most important reason appears to be that the protocol offers a too large set of features and options. On the one hand, this makes CMP applicable to a very wide range of scenarios, but on the other hand a full implementation of all options is not realistic because this would take undue effort.¶

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

As also 3GPP and UNISIG already put across, profiling is a way of coping with the challenges mentioned above. 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 all the general and applicable aspects of the general protocol are taken over and only the peculiarities of the target scenario need to be dealt with specifically.¶

Defining such a profile for a new target environment take a 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 with the intended usage 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 do not need to come up with individual profiles.¶

1.2. Motivation for a lightweight profile for CMP

The profiles specified in Appendix D and E of RFC 4210 [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 SSH. Therefore, the security of these architectures highly relies upon the security and availability of the implemented certificate management procedures.¶

Due to increasing security needs in operational networks as well as availability requirements, especially on critical infrastructures and systems with a high volume of certificates, a state-of-the-art certificate management must be constantly available and cost-efficient, which calls for high automation and reliability. The NIST Framework for Improving Critical Infrastructure Cybersecurity [NIST.CSWP.04162018] also refers to proper processes for issuance, management, verification, revocation, and audit for authorized devices, users and processes involving identity and credential management. Such PKI operation according to commonly accepted best practices is also required in IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher.¶

Further challenges in many industrial systems are network segmentation and asynchronous communication, while PKI operation typically is not deployed on-site but in a more protected environment of a data center or trust center. Certificate management must be able to cope with such network architectures. CMP offers the required flexibility and functionality, namely self-contained messages, efficient polling, and support for asynchronous message transfer while retaining end-to-end security.¶

1.3. Existing CMP profiles

As already stated, RFC 4210 [RFC4210] contains profiles with mandatory and optional PKI management operations in Appendix D and E. Those profiles focus on management of human user certificates and do only partly address the specific needs for certificate management automation for unattended machines or application-oriented end entities.¶

RFC 4210 [RFC4210] specifies in Appendix D the following mandatory PKI management operations. All requirements regarding algorithm support have been updated by CMP Algorithms Section 7.2 [I-D.ietf-lamps-cmp-algorithms], all operations may enroll up to two certificates, one for a locally generated and optionally another one for a centrally generated key pair, and all require use of certConf/pkiConf messages for confirmation.¶

• Initial registration/certification; an (uninitialized) end entity requests a (first) certificate from a CA using shared secret based message authentication. The content is similar to the PKI management operation specified in Section 4.1.4 of this document.¶
• Certificate request; an (initialized) end entity requests another certificate from a CA using signature-based or shared secret-based message authentication. The content is similar to the PKI management operation specified in Section 4.1.2 of this document.¶
• Key update; an (initialized) end entity requests a certificate from a CA (to update the key pair and/or corresponding certificate that it already possesses) using signature-based or shared secret-based message authentication. The content is similar to the PKI management operation specified in Section 4.1.3 of this document.¶

Two certificates may be enrolled and authentication is based on shared secrets because these PKI management operations focus on the enrollment of certificates of humans.¶

RFC 4210 [RFC4210] specifies in Appendix E the following optional PKI management operations. All requirements regarding algorithm support have been updated by CMP Algorithms Section 7.2 [I-D.ietf-lamps-cmp-algorithms].¶

• Root CA key update; a root CA updates its key pair and produces a CA key update announcement message, which can be made available (via some transport mechanism) to the relevant end entities. This operation only supports a push model. The content is similar to the PKI management operation supporting the pull model specified in Section 4.4.2 of this document.¶
• Information request/response; an end entity sends a general message to the PKI requesting details that will be required for later PKI management operations. The content is similar to the PKI management operation specified in Section 4.4.3 of this document.¶
• Cross-certification request/response (1-way); creation of a single cross-certificate (i.e., not two at once). The requesting CA MAY choose who is responsible for publication of the cross-certificate created by the responding CA through use of the PKIPublicationInfo control.¶
• In-band initialization using an external identity certificate (this PKI management operation may also enroll up to two certificates and requires use of certConf/pkiConf messages for confirmation as specified in Appendix D of RFC 4210 [RFC4210]). An (uninitialized) end entity wishes to initialize into the PKI with a CA, CA-1. It uses, for authentication purposes, a pre-existing identity certificate issued by another (external) CA, CA-X. A trust relationship must already have been established already between CA-1 and CA-X so that CA-1 can validate the EE's identity certificate signed by CA-X. Furthermore, some mechanism must already have been established within the Personal Security Environment (PSE) of the EE enabling it to authenticate and verify PKIMessages signed by CA-1. The content is similar to the PKI management operation specified in Section 4.1.1 of this document.¶

Both these Appendixes D and E focus on EE-to-CA/RA PKI management operations and do not address further profiling of RA to CA communication as typically needed for full backend automation.¶

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 EE and RA/CA is specified in that document.¶

UNISIG has included a CMP profile for certificate enrollment in the subset 137 specifying the ETRAM/ECTS on-line key management for train control systems [UNISIG.Subset-137] in 2015.¶

Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] to add tailored means for automated PKI management operations for unattended devices and services.¶

1.4. Compatibility with existing CMP profiles

The profile specified in this document is compatible with RFC 4210 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with the following exceptions:¶

• signature-based protection is the default protection; an initial PKI management operation may also use MAC-based protection,¶
• certification of a second key pair within the same PKI management operation is not supported,¶
• proof-of-possession (POPO) with self-signature of the certTemplate according to RFC 4210 Section 4.1 [RFC4210] clause 3 is the recommended default POPO method (deviations are possible for EEs when requesting central key generation, for (L)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 the push model) are omitted.¶

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 on-line key management in rail networks as specified in UNISIG Subset-137 [UNISIG.Subset-137], except that:¶

• A certificate enrollment request message consists of only one certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 [UNISIG.Subset-137] allows to transport more than one certificate request message, this conflicts with this document.¶
• As of RFC 4210 [RFC4210] the messageTime is required to be Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly states that the messageTime in required to be 'UTC time', it is not clear if this means a coding as UTCTime or generalizedTime and if other time zones than Greenwich Mean Time shall be allowed. Therefore, UNISIG Subset-137 [UNISIG.Subset-137] may conflict with RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 Section 4.1.2.5 [RFC5280].¶
• This profile requires usage of the same type of protection for all messages of one PKI management operation. This means, in case the request message is MAC protected, also the response, certConf, and pkiConf messages have a MAC-based protection. As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] specifies for the first certificate request MAC protection for all messages send by the client and signature protection for all messages send by the server, this conflicts with this document.¶
• Use of caPubs is not required but typically allowed in combination with MAC-based protected PKI management operations. On the other hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using caPubs. Note that in case the protection of the response is changed to signature-based protection using a certificate issued under the root CA that is to be transported in the caPubs field, this is not a secure delivery of the root CA certificate.¶
• This profile requires that the certConf message has one CertStatus element where the statusInfo field is recommended. In contrast, UNISIG Subset-137 Table 18 [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 (since moreover using implicitConfirm is not allowed there, neither).¶

1.5. Scope of this document

This document specifies requirements on generating PKI management messages on the sender side. It does not specify strictness of verification on the receiving side and how in detail to handle error cases.¶

Especially on the EE side this profile aims at a lightweight implementation. This means that the number of PKI management operations that implementations must support are reduced to a reasonable minimum to support most 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 resources needed.¶

For the sake of robustness and preservation of security properties implementations should, as far 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 accept").¶

When in Section 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly specified, it SHOULD not be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence.¶

1.6. Structure of this document

Section 2 introduces the general PKI architecture and approach to certificate management using CMP that is assumed in this document. Then it enlists the PKI management operations specified in this document and describes them in general words. The list of supported PKI management operations is divided into mandatory, recommended, and optional ones.¶

Section 3 profiles the CMP message header, protection, and extraCerts fields as they are general elements of CMP messages.¶

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

Section 5 profiles the message exchange between PKI management entities. In the first place this consists of forwarding messages coming from or going to an EE. This may include delayed delivery of messages, which involves polling for certificate responses. Additionally, it specifies operations where a PKI management entity manages certificates on behalf of an EE or for itself.¶

Section 6 outlines several mechanisms for CMP message transfer, namely HTTP-based transfer as already specified in RFC 6712 [RFC6712], using an additional TLS layer, or offline file-based transport. CoAP [RFC7252] and piggybacking CMP messages¶

1.7. Convention and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.¶

Technical terminology is used in conformance with RFC 4210 [RFC4210], RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR [IEEE.802.1AR_2018]. The following key words are used:¶

CA:

Certification authority, which issues certificates.¶

RA:

Registration authority, an optional PKI component to which a CA delegates certificate management functions such as authorization checks.¶

LRA:

Local registration authority, an optional RA system component with proximity to the end entities.¶

KGA:

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

EE:

End entity, a user, device, or service that holds 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 RFC 4210 [RFC4210] and used as follows:¶

PKI management operation:

All CMP messages belonging to one transaction context. The transaction is identified in the transactionID field of the message header.¶

PKI management entity:

All non-EE PKI entities such as LRA, RA, and CA.¶

PKI entity:

EEs and PKI management entities¶

2.1. Solution architecture

In order to facilitate secure automatic certificate enrollment if the device hosting an EE is equipped with a manufacturer issued certificate during production. Such a manufacturer issued certificate is installed during production to identify the device throughout its lifetime. This manufacturer certificate can be used to protect the initial enrollment of operational certificates after installation of the EE on site in its operational environment. An operational certificate is issued by the owner or operator of the device to identify the device during operation for use, e.g., in a security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a manufacturer certificate is called IDevID certificate and an operational certificate is called LDevID certificate.¶

Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises the triplet of the certificate and the corresponding private key as well as certificate chain up to the root certificate.¶

All certificate management transactions specified in this document are initiated by the EE. The EE creates a CMP request message, protects it using some asymmetric credential or shared secret information, as far as available, and sends it to its locally reachable PKI component. This PKI component may be an LRA, RA, or the CA, which checks the request, responds to it itself, or forwards the request upstream to the next PKI component. In case an (L)RA changes the CMP request message header or body or wants to prove a successful verification or authorization, it can apply a protection of its own. Especially the communication between an LRA and RA can be performed synchronously or asynchronously. Synchronous communication describes a timely uninterrupted communication between two communication partners, while asynchronous communication is not performed in a timely consistent manner, e.g., because of a delayed message delivery.¶

+-----+            +-----+                +-----+            +-----+
|     |            |     |                |     |            |     |
| EE  |<---------->| LRA |<-------------->| RA  |<---------->| CA  |
|     |            |     |                |     |            |     |
+-----+            +-----+                +-----+            +-----+

        synchronous        (a)synchronous       (a)synchronous
   +----connection----+------connection------+----connection----+

        on site at                operators          service partner
+----------plant---------+-----backend services-----+-trust center-+

In operation environments a layered LRA-RA-CA architecture can be deployed, e.g., with LRAs bundling requests from multiple EEs at dedicated locations and one (or more than one) central RA aggregating the requests from multiple LRAs. Every (L)RA in this scenario typically has a shared secret information (one per EE) for password-based protection or a CMP protection key and certificate containing an extended key usage as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] allowing it to protect CMP messages it processes. The figure above shows an architecture using one LRA and one RA. It is also possible to have only an RA or multiple LRAs and/or RAs. Depending on the network infrastructure, the message transfer between PKI management entities may be based on synchronous online connections, delayed asynchronous connections, or even offline (e.g., file-based) transfer.¶

This profile focusses on specifying the pull model, where the EE always requests a specific PKI management operation.¶

Note: CMP response messages, especially in case of central key generation, as described in Section 4.1.6, could also be used proactively to implement the push model towards the EE.¶

Third-party CAs typically implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management. Therefore, the LRA or the RA may need to adapt the exchanged CMP messages to the flavor of certificate management interaction required by the CA.¶

2.2. Basic generic CMP message content

Section 3 specifies the generic parts of the CMP messages as used later in Section 4 and Section 5.¶

• Header of a CMP message; see Section 3.1.¶
• Protection of a CMP message; see Section 3.2.¶
• ExtraCerts field of a CMP message; see Section 3.3.¶

2.3. Supported PKI management operations

Following the scope outlined in Section 1.5, this section gives a brief overview of the PKI management operations specified in Section 4 and Section 5 and states whether implementation by compliant EE or PKI management entities is mandatory, recommended, or optional.¶

2.4. CMP message transport

On different links between PKI entities, e.g., EE-RA and RA-CA, different transport MAY be used. As CMP does not have specific needs regarding message transport, virtually any reliable transport mechanism may be used, e.g., HTTP, CoAP, and offline file-based transport. Therefore, this document does not require any specific transport protocol to be supported by conforming implementations.¶

HTTP transfer is RECOMMENDED to use for all PKI entities, yet full flexibility is retained to choose whatever transport is suitable, for instance for devices with special constraints.¶

3.1. General description of the CMP message header

This section describes the generic header field of all CMP messages with signature-based protection. The only variations described here are in the recipient, transactionID, and recipNonce fileds of the first message of a PKI management operation.¶

In case a message has MAC-based protection the changes are described in Section 4.1.4. The variations will affect the fields sender, protectionAlg, and senderKID.¶

For requirements regarding proper random number generation please refer to [RFC4086]. Any message-specific fields or variations are described in Section 4 and Section 5.¶

header
  pvno                        REQUIRED
    -- MUST be set to 3 to indicate CMP V3 in all cases where
    -- EnvelopedData is supported and expected to be used in this PKI
    -- management operation
    -- MUST be set to 2 to indicate CMP V2 in all other cases
    -- For details on version negotiation see RFC-CMP-Updates
  sender                      REQUIRED
    -- MUST contain a name representing the originator of the message
    -- SHOULD be the subject of the CMP protection certificate, i.e.,
    -- the certificate for the private key used to sign the message
  recipient                   REQUIRED
    -- SHOULD be the name of the intended recipient and
    -- MAY be a NULL-DN, i.e., a zero-length SEQUENCE OF
    -- RelativeDistinguishedNames, if the sender does not know the
    -- DN of the recipient
    -- If this is the first message of a transaction: SHOULD be the
    -- subject of the issuing CA certificate
    -- In all other messages: SHOULD be the same name as in the
    -- sender field of the previous message in the same transaction
  messageTime                 RECOMMENDED
    -- MUST be the time at which the message was produced, if
    -- present
  protectionAlg               REQUIRED
    -- MUST be the algorithm OID of the algorithm used for
    -- calculating the protection bits
    -- The signature algorithm MUST be a MSG_SIG_ALG as specified in
    -- RFC-CMP-Alg Section 3 and MUST be consistent with the
    -- subjectPublicKeyInfo field of the protection certificate
    -- The MAC algorithm MUST be a MSG_MAC_ALG as specified in
    -- RFC-CMP-Alg Section 6
    algorithm                 REQUIRED
    -- MUST be the OID of the signature or MAC algorithm
  senderKID                   RECOMMENDED
    -- MUST be the SubjectKeyIdentifier of the CMP protection
    -- certificate or a reference of the shared secret information
    -- used for the protection
  transactionID               REQUIRED
    -- If this is the first message of a transaction:
    -- MUST be 128 bits of random data for the start of a
    -- transaction, 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
    -- transaction
  senderNonce                 REQUIRED
    -- MUST be cryptographically secure and fresh 128 random bits
  recipNonce                  RECOMMENDED
    -- If this is the first message of a transaction: SHOULD be
    -- absent
    -- 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
    -- The field is optional in ir/cr/kur/p10cr requests and
    -- ip/cp/kup response messages and PROHIBTED in other types of
    -- messages
    -- Added to request messages to request omission of the certConf
    -- message
    -- See [RFC4210] Section 5.1.1.1.
    -- Added to response messages to grant omission of the certConf
    -- message
      ImplicitConfirmValue    REQUIRED
    -- ImplicitConfirmValue of the request message MUST be NULL if
    -- the EE wants to request not to send a confirmation message
    -- ImplicitConfirmValue MUST be NULL if the PKI management
    -- entity wants to grant not sending a confirmation message

3.2. General description of the CMP message protection

This section describes the generic protection field of all CMP messages with signature-based protection. The certificate for the private key used to sign a CMP message is called 'protection certificate'. Any included keyUsage extension SHOULD allow digitalSignature.¶

protection                    RECOMMENDED
    -- MUST contain the signature calculated using the private key
    -- of the entity protecting the message. The signature
    -- algorithm used MUST be given in the protectionAlg field.

Generally, CMP message protection is required for CMP messages, but there are cases where protection of error messages as specified in Section 4.3 and Section 5.3 is not possible and therefore MAY be omitted.¶

For MAC-based protection as specified in Section 4.1.4 major differences apply as described in the respective section.¶

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

Note: The extended key usages specified in CMP Updates [I-D.ietf-lamps-cmp-updates] can be used for authorization of a sending PKI management entity.¶

Note: The requirements for checking certificates given in [RFC5280] MUST be the followed for signature-based CMP message protection. In case the CMP protection certificate is not the CA certificate that signed the newly issued certificate, certificate status checking SHOULD be used for the CMP protection certificates of communication partners.¶

3.3. General description of CMP message extraCerts

This section describes the generic extraCerts field of all CMP messages with signature-based protection. If extraCerts are required, recommended, or optional is specified in the respective PKI management operation.¶

extraCerts
    -- SHOULD contain the CMP protection certificate together with
    -- its chain, if needed and the self-signed root certificate
    -- SHOULD be omitted
    -- If present, the first certificate in this field MUST be
    -- the CMP protection certificate and each followed by its chain
    -- where each element SHOULD directly certify the one
    -- immediately preceding it.
    -- Self-signed certificates SHOULD be omitted from extraCerts,
    -- unless they are the same as the protection certificate and
    -- MUST NOT be trusted based on their inclusion in any case

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

4.1. Requesting a new certificate from a PKI

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

These approaches differ in the way the EE authenticates itself to the PKI and in the way that the key pair to be certified is generated. The authentication mechanisms may be as follows:¶

• Using a certificate from a trusted PKI and the corresponding private key, e.g., a manufacturer issued certificate¶
• Using the certificate to be updated and the corresponding private key¶
• Using shared secret information known to the EE and the PKI¶

An EE requests a certificate indirectly or directly from a CA. When the PKI management entity responds with a message containing the requested certificate, the EE MUST reply with a confirmation message. The PKI management entity then MUST respond with a confirmation, closing the transaction.¶

The message sequences in this section allow the EE to request certification of a locally generated public-private key pair. For requirements regarding proper random number and key generation please refer to [RFC4086]. The EE SHOULD provide a signature-based proof-of-possession of the private key associated with the public key contained in the certificate request as defined by RFC 4211 Section 4.1 [RFC4211] case 3. To this end it is assumed that the private key can technically be used for signing. This is the case for the most commonly used algorithms RSA and ECDSA, regardless of potentially intended restrictions of the key usage.¶

Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 [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 POPO. As will be detailed in Section 5.1.2, the targeted PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions. Especially when removing the protection provided by the EE and applying a new protection, the PKI management entity MUST verify in particular the included proof-of-possession self-signature of the certTemplate or the PKCS#10 certificationRequestInfo using the public key of the requested certificate and MUST check that the EE, as authenticated by the message protection, is authorized to request a certificate with the subject as specified in the certTemplate.¶

When an EE verifies the protection of a response message with signature-based protection it needs a trust anchor to verify the protection certificate. There are several ways to install the Root CA certificate of a new PKI on an EE. The installation can be performed in an out-of-band manner, using general messages, a voucher [RFC8366], or other formats for enrollment, or in-band of CMP by the caPubs field in the certificate response message. In case the installation of the new root CA certificate is performed using the caPubs field, the certificate response message MUST be properly authenticated, and the sender of this message MUST be authorized to install new root CA certificates on the EE. This authorization is typically indicated by using shared secret information, but it can also be indicated by using a private key with a certificate issued by another PKI authorized for this purpose, for the CMP message protection.¶

Step# EE                                  PKI management entity
  1   format ir
  2                      ->   ir      ->
  3                                        handle, re-protect or
                                             forward ir
  4                                        format or receive ip
  5                                        possibly grant implicit
                                             confirm
  6                      <-   ip      <-
  7   handle ip
  8                                        In case of status
                                             "rejection" in the
                                             ip message, no certConf
                                             and pkiConf are sent
  9   format certConf (optional)
 10                      ->   certConf ->
 11                                        handle, re-protect or
                                             forward certConf
 12                                        format or receive pkiConf
 13                      <-   pkiconf  <-
 14   handle pkiConf (optional)

Certification Request -- ir

Field                         Value

header
    -- As described in Section 3.1

body
    -- The request of the EE for a new certificate
  ir                          REQUIRED
    -- MUST be exactly one CertReqMsg
    -- If more certificates are required, further requests MUST be
    -- packaged in separate PKI Messages
    certReq                   REQUIRED
      certReqId               REQUIRED
    -- MUST be set to 0
      certTemplate            REQUIRED
        version               OPTIONAL
    -- MUST be 2 if supplied.
        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 a NULL-DN
        publicKey             REQUIRED
          algorithm           REQUIRED
    -- MUST include the subject public key algorithm OID and valueany
    -- parameters
    -- In case a central key generation is requested, this field
    -- contains the algorithm and parameter preferences of the
    -- requesting entity regarding the to-be-generated key pair
          subjectPublicKey    REQUIRED
    -- MUST contain the public key to be certified in case of
    -- local key generation
    -- MUST contain a zero-length BIT STRING in case a 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                      REQUIRED
      POPOSigningKey          OPTIONAL
    -- MUST be used in case subjectPublicKey contains a public key
    -- MUST be absent in case subjectPublicKey contains a
    -- zero-length BIT STRING
        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 field of the certTemplate
        signature             REQUIRED
    -- MUST be the signature computed over the DER-encoded
    -- certTemplate

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3


Certification 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 used it MUST contain only the root certificate of the
    -- certificate contained in certOrEncCert
    response                  REQUIRED
    -- MUST be exactly one CertResponse
      certReqId               REQUIRED
    -- MUST be set to 0
      status                  REQUIRED
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- positive values allowed: "accepted", "grantedWithMods"
    -- negative values allowed: "rejection"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, logging or to
    -- display in a GUI
        failInfo              OPTIONAL
    -- MUST be present if status is "rejection"
    -- MUST be absent if the 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 when certifiedKeyPair is present
          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
    -- MUST contain the encrypted private key in an EnvelopedData
    -- structure as specified in section 5.1.5 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
    -- Self-signed root certificate SHOULD be omitted
    -- Duplicate certificates MAY be omitted


Certificate Confirmation -- certConf

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE sends confirmation to the PKI
    -- management entity to accept or reject the issued certificates
  certConf                    REQUIRED
    -- MUST be exactly one CertStatus
    CertStatus                REQUIRED
      certHash                REQUIRED
    -- MUST be the hash of the certificate, using the same hash
    -- algorithm as used to create the certificate signature
      certReqId               REQUIRED
    -- MUST be set to 0
      statusInfo              RECOMMENDED
    -- 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, logging, or to
    -- display in a GUI
        failInfo              OPTIONAL
    -- MUST be present if status is "rejection"
    -- MUST be absent if the status is "accepted"

protection                    REQUIRED
    -- As described in Section 3.2
    -- MUST use the same certificate as for protecting the ir

extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- Any certificates in extraCerts MAY be omitted if the message
    -- size is critical and the PKI management entity caches the
    -- extraCerts from the ir

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 certificate as for protecting the ip
extraCerts                    RECOMMENDED
    -- As described in Section 3.3
    -- Any certificates in extraCerts MAY be omitted if the message
    -- size is critical and the EE has cached the extraCerts from the
    -- ip

    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 set to 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 a NULL-DN
      subjectPKInfo           REQUIRED
        algorithm             REQUIRED
    -- MUST include the subject public key algorithm ID
        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 containing the self-signature for proof-of-possession

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    REQUIRED
    -- As described in Section 3.3

+----------------------------------+
| EnvelopedData                    |
| [RFC5652] section 6              |
| +------------------------------+ |
| | SignedData                   | |
| | [RFC5652] section 5          | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage     | | |
| | | [RFC5958]                | | |
| | | +----------------------+ | | |
| | | | privateKey           | | | |
| | | | OCTET STRING         | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+

        privateKey            OPTIONAL
    -- MUST be an EnvelopedData structure as specified in
    -- CMS [RFC5652] section 6
          version             REQUIRED
    -- MUST be set to 2 for recipientInfo type KeyAgreeRecipientInfo
    -- and KeyTransRecipientInfo
    -- MUST be set to 0 for recipientInfo type PasswordRecipientInfo
          recipientInfos      REQUIRED
    -- MUST be exactly one RecipientInfo
            recipientInfo     REQUIRED
    -- MUST be either KeyAgreeRecipientInfo (see section 4.1.6.1),
    -- KeyTransRecipientInfo (see section 4.1.6.2), or
    -- PasswordRecipientInfo (see section 4.1.6.3)
    -- If central key generation is supported, support of
    -- KeyAgreeRecipientInfo is REQUIRED and support of
    -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL
          encryptedContentInfo
                              REQUIRED
            contentType       REQUIRED
    -- MUST be id-signedData
            contentEncryptionAlgorithm
                              REQUIRED
    -- MUST specify the algorithm OID of the algorithm used for
    -- content encryption
    -- The algorithm MUST be a PROT_SYM_ALG as specified in
    -- RFC-CMP-Alg Section 5
            encryptedContent  REQUIRED
    -- MUST be the SignedData structure as specified in
    -- CMS Section 5 [RFC5652] in encrypted form
              version         REQUIRED
    -- MUST be set to 3 if X.509 V3 certificates are included
              digestAlgorithms
                              REQUIRED
    -- MUST be exactly one digestAlgorithm OID
                digestAlgorithmIdentifier
                              REQUIRED
    -- MUST be the OID of the digest algorithm used for generating
    -- the signature and match the signature algorithm specified in
    -- signatureAlgorithm
              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
                  AsymmetricKeyPackage
                              REQUIRED
    -- MUST contain exactly one OneAsymmetricKey element
                    OneAsymmetricKey
                              REQUIRED
                      version REQUIRED
    -- MUST be set to 1
                      privateKeyAlgorithm
                              REQUIRED
    -- The privateKeyAlgorithm field MUST contain
    -- the OID of the asymmetric key pair algorithm
                      privateKey
                              REQUIRED
    -- MUST contain the new private key
                      attributes
                              OPTIONAL
    -- The attributes field SHOULD not be used
                      publicKey
                              REQUIRED
    -- MUST contain the public key corresponding to the private key
    -- for simplicity and consistency with V2 of OneAsymmetricKey
              certificates    REQUIRED
    -- SHOULD contain the certificate, for the private key used
    -- to sign the content, together with its chain
    -- If present, the first certificate in this field MUST
    -- be the 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
              crls            OPTIONAL
    -- MAY be present to provide status information on the protection
    -- certificate or its CA certificates
              signerInfos     REQUIRED
    -- MUST be exactly one signerInfo
                version       REQUIRED
    -- MUST be set to 3
                sid           REQUIRED
                  subjectKeyIdentifier
                              REQUIRED
    -- MUST be the subjectKeyIdentifier of the protection certificate
                digestAlgorithm
                              REQUIRED
    -- MUST be the same as in digestAlgorithmIdentifier
                signedAttrs   REQUIRED
    -- MUST contain an id-contentType attribute containing the same
    -- value as eContentType
    -- MUST contain an id-messageDigest attribute containing the
    -- message digest of eContent
    -- MAY contain an id-signingTime attribute containing the time of
    -- signature
    -- For details on the signed attributes see CMS Section 5.3
    -- and Section 11 [RFC5652]
                signatureAlgorithm
                              REQUIRED
    -- MUST be the algorithm OID of the signature algorithm used for
    -- calculation of the signature bits
    -- The signature algorithm MUST be a MSG_SIG_ALG as specified in
    -- RFC-CMP-Alg Section 3 and MUST be consistent with the
    -- subjectPublicKeyInfo field of the CMP KGA certificate
                signature     REQUIRED
    -- MUST be the result of the digital signature generation

            recipientInfo     REQUIRED
    -- MUST be KeyAgreeRecipientInfo as specified in
              version         REQUIRED
    -- MUST be set to 3
              originator      REQUIRED
    -- MUST contain the originatorKey choice
                algorithm     REQUIRED
    -- MUST be the algorithm OID of the key agreement algorithm
    -- The algorithm MUST be a KM_KA_ALG as specified in
    -- RFC-CMP-Alg Section 4.1
                publicKey     REQUIRED
    -- MUST be the ephemeral public key of the sending party
              ukm             RECOMMENDED
    -- MUST be used when 1-pass ECMQV is used
    -- SHOULD be present to ensure uniqueness of the key
    -- encryption key, see [RFC8419]
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm OID of the key wrap algorithm
    -- The algorithm MUST be a KM_KW_ALG as specified in
    -- RFC-CMP-Alg Section 4.3
              recipientEncryptedKeys
                              REQUIRED
    -- MUST contain exactly one RecipientEncryptedKey element
                  rid         REQUIRED
    -- MUST contain the rKeyId choice
                    rKeyId    REQUIRED
                      subjectKeyIdentifier
                              REQUIRED
    -- MUST contain the same value as the senderKID in the
    -- respective request messages
                  encryptedKey
                              REQUIRED
    -- MUST be the encrypted content-encryption key

            recipientInfo     REQUIRED
    -- MUST be KeyTransRecipientInfo as specified in
    -- CMS section 6.2.1 [RFC5652]
              version         REQUIRED
    -- MUST be set to 2
              rid             REQUIRED
       -- MUST contain the subjectKeyIdentifier choice
                subjectKeyIdentifier
                              REQUIRED
    -- MUST contain the same value as the senderKID in the respective
    -- request messages
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm OID of the key transport algorithm
    -- The algorithm MUST be a KM_KT_ALG as specified in RFC-CMP-Alg
    -- Section 4.2
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

            recipientInfo     REQUIRED
    -- MUST be PasswordRecipientInfo as specified in
    -- CMS section 6.2.4 [RFC5652]
              version         REQUIRED
    -- MUST be set to 0
              keyDerivationAlgorithm
                              REQUIRED
    -- MUST be the algorithm OID of the key derivation algorithm
    -- The algorithm MUST be a KM_KD_ALG as specified in RFC-CMP-Alg
    -- Section 4.4
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm OID of the key wrap algorithm
    -- The algorithm MUST be a KM_KW_ALG as specified in RFC-CMP-Alg
    -- Section 4.3
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

Step# EE                                   PKI management entity
 1   format ir/cr/p10cr/kur
     As described in the
       respective section
       in this document
 2                    ->ir/cr/p10cr/kur->
 3                                        handle request as described
                                            in the respective section
                                            in this document
 4                                        in case no immediate final
                                            response is possible,
                                            receive or format ip, cp
                                            or kup message containing
                                            status "waiting"
 5                      <-  ip/cp/kup  <-
 6   handle ip/cp/kup with status "waiting"
 7   format pollReq
 8                      ->   pollReq   ->
 9                                        handle, re-protect or
                                            forward pollReq
10                                        in case the requested
                                            certificate or a
                                            corresponding response
                                            message is available,
                                            receive or format ip, cp,
                                            or kup containing the
                                            issued certificate, else
                                          format or receive pollRep
                                            with appropriate
                                            checkAfter value
11                      <-   pollRep   <-
12   handle pollRep
13   let checkAfter
       time elapse
14   continue with line 7

Response with status 'waiting'  -- ip/cp/kup

Field                         Value

header
    -- MUST contain a header as described for the first response
    -- message of the respective PKI management operation

body
    -- The response of the PKI management entity to the request in
    -- case no immediate appropriate response can be sent
  ip/cp/kup                   REQUIRED
    response                  REQUIRED
    -- MUST contain exactly one CertResponse
      certReqId               REQUIRED
    -- MUST be 0
      status                  REQUIRED
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- MUST be "waiting"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, logging or to
    -- display in a GUI
        failInfo              PROHIBITED
      certifiedKeyPair        PROHIBITED

protection                    REQUIRED
    -- MUST contain protection as described for the first response
    -- message of the respective PKI management operation, except
    -- that the PKI management entity that initiated the delayed
    -- enrollment and created this response MUST apply its own
    -- protection

extraCerts                    REQUIRED
    -- MUST contain certificates as described for the first response
    -- message of the respective PKI management operation. Yet since
    -- no new certificate is included yet, no respective certificate
    -- chain is included


Polling Request -- pollReq

Field                         Value

header
    -- MUST contain a header as described for the certConf message
    -- of the respective PKI management operation

body
    -- The message of the EE asks for the final response or for a
    -- time to check again
  pollReq                     REQUIRED
    -- MUST contain exactly one element
    certReqId                 REQUIRED
    -- MUST be 0

protection                    REQUIRED
    -- MUST contain protection as described for the certConf message
    -- of the respective PKI management operation

extraCerts                    OPTIONAL
    -- MUST be as described for the certConf message of the
    -- respective PKI management operation


Polling Response -- pollRep

Field                         Value

header
    -- MUST contain a header as described for the pkiConf message
    -- of the respective PKI management operation

body
    -- The message indicates the delay after which the EE may send
    -- another pollReq message for this transaction
  pollRep                     REQUIRED
    -- MUST contain exactly one entry
    certReqId                 REQUIRED
    -- MUST be 0
    checkAfter                REQUIRED
    -- time in seconds to elapse before a new pollReq should be sent
    reason                    OPTIONAL
    -- MAY be any human-readable text for debugging, logging or to
    -- display in a GUI

protection                    REQUIRED
    -- MUST contain protection as described for the pkiConf message
    -- of the respective profile, except that the PKI management
    -- entity that initiated the delayed enrollment and created this
    -- response MUST apply its own protection

extraCerts                    OPTIONAL
    -- If present, it MUST contain certificates as described for the
    -- pkiConf message of the respective PKI management operation.


Final response -- ip/cp/kup

Field                         Value

header
    -- MUST contain a header as described for the first
    -- except that the PKI management entity that initiated the
    -- delayed enrollment MUST replace the recipNonce by be the
    -- senderNonce of the last pollReq message

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

protection                    REQUIRED
    -- MUST contain protection as described for the first response
    -- message of the respective PKI management operation, except
    -- that the PKI management entity that initiated the delayed
    -- enrollment MUST re-protect the response message

extraCerts                    REQUIRED
    -- MUST contain certificates as described for the first
    -- response message of the respective PKI management operation

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. A PKI management entity could also act as 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.¶

An EE requests the revocation of an own certificate at the CA that issued this certificate. The PKI management entity responds with a message that contains the status of the revocation from the CA.¶

Preconditions:¶

1

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, re-protect or
                                             forward rr
  4                                        format or receive rp
  5                      <-   rp      <-
  6   handle rp

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

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 exactly one element of type RevDetails
    -- If more revocations are desired, further requests MUST be
    -- packaged in separate PKI Messages
    certDetails               REQUIRED
    -- MUST be present and be of type CertTemplate
      serialNumber            REQUIRED
    -- MUST contain the certificate serialNumber attribute of the
    -- X.509 certificate to be revoked
      issuer                  REQUIRED
    -- MUST contain the issuer attribute of the X.509 certificate to
    -- be revoked
    crlEntryDetails           REQUIRED
    -- MUST contain exactly 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 responds of the PKI management entity to the request as
    -- appropriate
  rp                          REQUIRED
    status                    REQUIRED
    -- MUST contain exactly 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, logging or to
    -- display in a GUI
      failInfo                OPTIONAL
    -- MAY be present if and only if status is "rejection"

protection                    REQUIRED
    -- As described in section 3.2

extraCerts                    REQUIRED
    -- As described in section 3.3

4.3. Error reporting

This functionality should be used by an EE to report error conditions upstream to the PKI management entity such that the involved PKI management entities can immediately free their resources related to the current transaction. Error reporting by a PKI management entity downstream to the EE is described in Section 5.3.¶

In case the error condition is related to specific details of an ip, cp, or kup response message and a confirmation is expected the error condition MUST be reported in the respective certConf message with negative contents.¶

General error conditions, e.g., problems with the message header, protection, or extraCerts, and negative feedback on rp, pollRep, or pkiConf messages MUST be reported in the form of an error message.¶

In both situations the EE reports the status "rejection" in the PKIStatusInfo structure of the respective message.¶

Depending on the PKI architecture, the addressed PKI management entity MUST forward the error message (upstream) to the next PKI management entity and MUST terminate this PKI management operation on receiving any response.¶

The PKIStatusInfo structure is used to report errors. The PKIStatusInfo structure consists of the following fields:¶

• status: Here the PKIStatus value "rejection" is the only one allowed.¶
• statusString: Here any human-readable valid value for logging or to display in a GUI SHOULD be added.¶

• failInfo: Here the PKIFailureInfo values MAY be used in the way explained in Appendix F of RFC 4210 [RFC4210]. The following PKIFailureInfo values have specific usage and therefore are described in detail here:¶

  • transactionIdInUse: This is sent by a PKI management entity in case the received request contains a transaction ID that has already been used for another transaction. An EE receiving such error message SHOULD resend the request in a new transaction using a different transaction ID.¶
  • systemUnavail or systemFailure: This is sent by a PKI management entity in case a back-end system is not available or currently not functioning correctly. An EE receiving such error message SHOULD resend the request in a new transaction after some time.¶

Detailed error message description:¶

Error Message -- error

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message sent by the EE or the (L)RA/CA to indicate an
    -- error that occurred
  error                       REQUIRED
    pKIStatusInfo             REQUIRED
      status                  REQUIRED
    -- MUST have the value "rejection"
      statusString            RECOMMENDED
    -- SHOULD be any human-readable text for debugging, logging
    -- or to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    OPTIONAL
    -- As described in Section 3.3

4.4. Support messages

The following support messages offer on demand in-band transport of content relevant to the EE that may be provided by the 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 LRA, RA, or CA.¶

The general messages and general response messages transport InfoTypeAndValue structures. In addition to those infoType values defined in RFC 4210 [RFC4210] 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 updates¶
• PGet certificate request templates¶

The PKI management operation is similar to that given in Appendix E.5 of RFC 4210 [RFC4210]. In this section the aspects common to all general messages (genm) and to all general responses (genp) are described.¶

The behavior in case an error occurs is described in Section 4.3.¶

Message flow:¶

Step# EE                                   PKI management entity
 1   format genm
 2                      ->   genm    ->
 3                                        handle, re-protect 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 to receive information
  genm                        REQUIRED
    -- MUST contain exactly one element of type
    -- InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying the specific PKI
    -- management operation described below
    infoValue                 OPTIONAL
    -- MUST be as described in the specific PKI
    -- management operation described below

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 to an
    -- information request
  genp                        REQUIRED
    -- MUST contain exactly one element of type
    -- InfoTypeAndValue
    infoType                  REQUIRED
    -- MUST be the OID identifying the specific PKI
    -- management operation described below
    infoValue                 OPTIONAL
    -- MUST be as described in the specific PKI
    -- management operation described below

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
    -- MUST be a sequence of CMPCertificate

      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 RootCaKeyUpdate
        newWithNew            REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the new root CA certificate
        newWithOld            RECOMMENDED
    -- SHOULD 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 content of the certificates template
        certTemplate          REQUIRED
    -- MUST be present if infoValue is present
    -- MUST contain the prefilled CertTemplate structure elements
    -- The SubjectPublicKeyInfo MUST contain no algorithm ID i.e.,
    -- the null OBJECT IDENTIFIER) in the algorithm field and a
    -- zero-length BIT STRING in the subjectPublicKey field
        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 key generation
    -- MUST contain one AttributeTypeAndValue per supported algorithm
    -- with attribute id-regCtrl-algId or id-regCtrl-rsaKeyLen

5.1. Forwarding messages

In case the PKI solution consists of several PKI management entities, each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or certConf) or error message coming from an EE or any other downstream PKI management entity MUST be sent to the next (upstream) PKI management entity. Any received response message MUST be forwarded downstream to the next PKI management entity or EE.¶

The PKI management entity SHOULD verify the protection, the syntax, the required message fields, the message type, and if applicable the authorization and the proof-of-possession of the message. Additional checks or actions MAY be applied depending on the PKI solution requirements and concept. If one of these verification procedures fails, the (L)RA SHOULD switch to the operation described in Section 5.3, i.e., respond with a negative response message and then MUST NOT forward the request message further upstream.¶

A PKI management entity SHOULD not change the received message unless necessary. The PKI management entity SHOULD only update the message protection if this is technically necessary. Concrete PKI system specifications may define in more detail when to do so.¶

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

Each hop in a chain of PKI management entity has one or more functionalities, e.g., a PKI management entity may¶

• verify the identities of EEs or base authorization decisions for certification request processing on specific knowledge of the local setup, e.g., by consulting an inventory or asset management system,¶
• add fields to certificate request messages,¶
• store data from a message in a database for later usage or audit purposes,¶
• provide traversal of a network boundary,¶
• replace a MAC-based protection by a signature-based protection that can be verified also further upstream,¶
• 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 enrollment due to offline upstream communication or registration officer interaction,¶
• grant the request of an EE to omit sending a confirmation message, or¶
• collect messages from ultiple LRAs and forward them jointly.¶

Therefore, the decision if a message should be forwarded¶

• unchanged with the original protection,¶
• unchanged with a new protection, or¶
• changed with a new protection¶

depends on the PKI solution design and the associated security policy (CP/CPS [RFC3647]).¶

This section specifies the options a PKI management entity may implement and use.¶

A PKI management entity MAY update the protection of a message if it¶

• performs changes to the header or the body of the message,¶
• needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI components,¶
• needs to protect the message using a key and certificate from a different PKI, or¶
• needs to replace or produce 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 the next hop. 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.¶

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

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

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

5.2. Revoking certificates on behalf of another's PKI entities

This PKI management operation can be used by a PKI management entity to revoke a certificate of another PKI entity. This revocation request message MUST be signed by the PKI management entity using its own CMP protection key to prove to the PKI authorization to revoke the certificate on behalf of that PKI entity.¶

Preconditions:¶

1

the certificate to be revoked MUST be known to the PKI management entity¶

2

the PKI management entity MUST have the authorization to revoke the certificates of other entities issued by the corresponding CA¶

The message sequence for this PKI management operation is identical to that given in Section 4.2, with the following changes:¶

1

it is not required that the certificate to be revoked is not yet expired or revoked¶

2

the PKI management entity acts as EE for this message exchange¶

3

the rr message MUST be signed using the CMP protection key of the PKI management entity.¶

5.3. Error reporting

This functionality should be used by the PKI management entity to report any arising error conditions downstream to the EE. Note that error reporting by the EE upstream to the PKI management entity is described in Section 4.3.¶

In case the error condition is related to specific details of an ir, cr, p10cr, or kur request message it MUST be reported in the specific response message, i.e., an ip, cp, or kup with negative contents.¶

General error conditions, e.g., problems with the message header, protection, or extraCerts, and negative feedback on rr, pollReq, certConf, or error messages MUST be reported in the form of an error message.¶

In both situations the PKI management entity reports the errors in the PKIStatusInfo structure of the respective message as described in Section 4.3.¶

An EE receiving any such negative feedback SHOULD log the error appropriately and MUST terminate the current transaction.¶

6.1. HTTP transport

This transport mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transport is used the specifications as described in [RFC6712] and updated by CMP Updates [I-D.ietf-lamps-cmp-updates] MUST be followed.¶

PKI management operations SHOULD use the following URI path:¶

Subsequent certConf, error, and pollReq messages are sent to the URI of the respective PKI management operation.¶

The PKI entity will recognize by the HTTP response status code if a configured URI is supported by the PKI management entity by sending a request to its preferred enrollment endpoint.¶

6.2. HTTPS transport using certificates

This transport mechanism can be used by a PKI entity to further protect the HTTP transport described in Section 6.1 using TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] with certificate-based authentication as described in [RFC2818]. Using this transport mechanism, the CMP transport via HTTPS MUST use TLS server authentication and SHOULD use TLS client authentication.¶

TLS client:¶

• The client SHOULD use a TLS client certificate as far as available. If no dedicated TLS certificate is available on an EE side, this EE SHOULD use an already existing certificate identifying the EE (e.g., a manufacturer issued certificate). Each PKI management entity SHOULD use a dedicated TLS client certificate on its upstream (client) interface.¶
• If no usable client certificate is available at the client, server-only authenticated TLS MUST be used.¶
• The client MUST validate the TLS server certificate of its communication partner.¶

TLS server:¶

• The server MUST use a TLS server certificate.¶
• The server MUST validate the TLS certificate of its clients if client authentication is available.¶

Note: The requirements for checking certificates given in [RFC5280], [RFC5246] and [RFC8446] MUST be followed for the TLS layer. Certificate status checking SHOULD be used for the TLS certificates of communication partners.¶

6.3. HTTPS transport using shared secrets

This transport mechanism can be used by a PKI entity to further protect the HTTP transport as described in Section 6.1 using TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual authentication based on shared secret information as described in [RFC5054].¶

< TBD: Add an appropriate shared secret-based mechanism for TLS 1.3. >¶

TLS client:¶

• The client MUST use its shared secret information for authentication.¶

TLS server:¶

• The server MUST use a suitable shared secret information for authentication.¶

< TBD: It needs to be clarified which cipher suite shall be recommended as there seems to be no support for TLS-SRP un JavaSE. >¶

6.4. Offline transport

For transporting CMP messages between PKI entities any mechanism can be used 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.¶

The transport mechanism SHOULD be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases the PKI entities using this mechanism SHOULD report an error as specified in Section 4.3 as fare as possible.¶

6.5. CoAP transport

In constrained environments where no HTTP transport is desired or possible, CoAP [RFC7252] as specified in [I-D.ietf-ace-cmpv2-coap-transport] MAY be used.¶

6.6. Piggybacking on other reliable transport

For online transfer where no HTTP transport is desired or possible CMP messages MAY also be transported on some other reliable protocol. Connection and error handling mechanisms like 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 in a separate document, for instance in the scope of the transport protocol used.¶