Internet-Draft | Lightweight CMP Profile | February 2022 |
Brockhaus, et al. | Expires 5 August 2022 | [Page] |
This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More special and complex use cases are supported as well, by features specified as recommended or optional.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 August 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC-CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms], when available.¶
This document specifies PKI management operations supporting machine-to-machine and IoT use cases. Its focus is to maximize automation and interoperability between all involved PKI entities, ranging from end entities (EE) over any number of intermediate PKI management entities such as Registration Authorities (RA) to the CMP endpoints of Certification Authority (CA) systems. This profile makes use of the concepts and syntax specified in CMP [RFC4210], [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP transfer for CMP [RFC6712], and CoAP transfer for CMP [I-D.ietf-ace-cmpv2-coap-transport]. Especially CMP, CRMF, and CMS are very feature-rich standards, while in most application scenarios only a limited subset of the specified functionality is needed. Additionally, the standards are not always precise enough on how to interpret and implement the described concepts. Therefore, this document aims at tailoring the available options and specifying at an adequate detail how to use them to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible.¶
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 Section 1.8 and Section 7 should be used to figure out which parts of Section 4 to Section 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.¶
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 solid and very 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 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 effort and minimizes resource needs, which is particularly important for memory-constrained devices. To this end, when there was a choice to have necessary complexity more on the EE or PKI management entity side, it has been pushed towards PKI management entities, where typically more computational resources are available and the development can be consolidated better. 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 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 scenarios need to be dealt with specifically.¶
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 do not need to come up with individual profiles from scratch.¶
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 operations.¶
Due to increasing security needs in operational networks as well as availability requirements, especially on 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, the NIST Framework for Improving Critical Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper processes for issuance, management, verification, revocation, and audit for authorized devices, users, and processes involving identity and credential management. Such PKI management operations according to commonly accepted best practices are 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 management entities like Certification Authorities (CA) typically are 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.¶
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 only partly address the specific needs of certificate management automation for unattended devices or machine-to-machine application scenarios.¶
Both Appendixes D and E focus on EE-to-RA/CA PKI management operations and do not address further profiling of RA-to-CA communication as typically needed for full backend automation. All requirements regarding algorithm support for RFC 4210 Appendix D and E [RFC4210] have been updated by CMP Algorithms Section 7.1 [I-D.ietf-lamps-cmp-algorithms].¶
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 enrollment of TLS certificates in the Subset-137 specifying the ETRAM/ETCS on-line key management for train control systems [UNISIG.Subset-137] in 2015.¶
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.¶
In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other environments using NETCONF/YANG modules, SZTP-CSR [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes different types of certificate requests to obtain a public-key certificate for a locally generated key pair. One option is using a CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offers both proof-of-possession and proof-of-identity. To allow PKI management entities to also comply with this profile, the p10cr message must be formatted by the EE as described in Section 4.1.4 of this profile, and it may be forwarded as specified in Section 5.2.¶
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous Enrollment [I-D.ietf-anima-brski-async-enroll] describes a generalization regarding the employed enrollment protocols to allow alternatives to EST [RFC7030]. For the use of CMP, it requires adherence to this profile.¶
The profile specified in this document is compatible with RFC 4210 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with the following exceptions:¶
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:¶
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:¶
RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean Time coded as generalizedTime.¶
Note: 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. Both time formats are described in RFC 5280 Section 4.1.2.5 [RFC5280].¶
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: It remains unclear from UNISIG Subset-137 for which certificate(s) the caPubs field should be used. For security reasons, it cannot be used for delivering the root CA certificate needed for validating the signature-based protection of the given response message (as stated indirectly also in its UNISIG Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]).¶
This profile requires that the certConf message has one CertStatus element where the statusInfo field is recommended.¶
Note: 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).¶
To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements on generating PKI management messages on the sender side. On the other hand, 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 operations 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, 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 receive").¶
When in Section 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] 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.¶
Section 2 introduces the general PKI architecture and approach to certificate management that is assumed in this document. Then it lists the PKI management operations specified in this document, partitioning them into mandatory, recommended, and optional ones.¶
Section 3 profiles the generic aspects of the PKI management operations specified in detail in Section 4 and Section 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, exchange 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 [RFC6712] transfer optionally using TLS, and [I-D.ietf-ace-cmpv2-coap-transport] transfer 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.¶
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.¶
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:¶
Local registration authority, a specific form of RA with proximity to the end entities.¶
Note: For ease of reading, this document uses the term "RA" also for LRAs in all cases where the difference is not relevant.¶
The following terminology is reused from RFC 4210 [RFC4210], as follows:¶
To facilitate secure automatic certificate enrollment, the device hosting an EE is typically equipped with a manufacturer-issued device certificate. Such a certificate is typically installed during production and is meant to identify the device throughout its lifetime. This certificate can be used to protect the initial enrollment of operational certificates after installation of the EE in its operational environment. In contrast to the manufacturer-issued device certificate, operational certificates are issued by the owner or operator of the device to identify the device or one of its components for operational use, e.g., in a security protocol like IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a manufacturer-issued device 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 triple of the certificate, the corresponding private key, and the certificate chain.¶
All certificate management operations specified in this document follow the pull model, i.e., are initiated by an EE (or by an RA acting as an EE). The EE creates a CMP request message, protects it using some asymmetric credential or shared secret information and sends it to its locally reachable PKI management entity. This PKI management entity may be a CA or more typically an RA, which checks the request, responds to it itself, or forwards the request upstream to the next PKI management entity. In case an RA changes the CMP request message header or body or wants to demonstrate 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----+ operators service partner +---------on site--------+----back-end services-----+-trust center-+
In operational environments the certificate management architecture can have multiple LRAs bundling requests from multiple EEs at dedicated locations and one (or more than one) central RA aggregating the requests from the LRAs. Every LRA in this scenario has shared secret information (one per EE) for MAC-based protection or a CMP protection key and certificate allowing it to (re-)protect CMP messages it processes. The figure above shows an architecture example with at least one LRA, RA, and CA. It is also possible not to have an RA or LRA or that there is no CA with a CMP interface. Depending on the network infrastructure, the message transfer between PKI management entities may be based on synchronous online connections, asynchronous connections, or even offline (e.g., file-based) transfer.¶
Note: CMP response messages could also be used proactively to implement the push model towards the EE. In this case the EE acts as receiver, not initiating the interaction with the PKI. Also, when using a commissioning tool or a registrar agent as described in BRSKI with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], certificate enrollment in a push model is needed. CMP in general and the messages specified in this profile offer all required capabilities, but the message flow and state machine as described in Section 4 must be adapted to implement a push model.¶
Third-party CAs may implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management. Therefore, the RA may need to adapt the exchanged CMP messages to the flavor of certificate management interaction required by the CA.¶
This section covers the generic aspects of the PKI management operations specified in Section 4 and Section 5 as upfront general requirements to minimize redundancy in the description and to ease implementation.¶
As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages have the following general structure:¶
+--------------------------------------------+ | PKIMessage | | +----------------------------------------+ | | | header | | | +----------------------------------------+ | | +----------------------------------------+ | | | body | | | +----------------------------------------+ | | +----------------------------------------+ | | | protection (OPTIONAL) | | | +----------------------------------------+ | | +----------------------------------------+ | | | extraCerts (OPTIONAL) | | | +----------------------------------------+ | +--------------------------------------------+
The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.¶
In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections.¶
The CMP message body contains the PKI management operation-specific information. It is described in Section 4 and Section 5.¶
The generic prerequisites needed by the PKI entities in order to be able to perform PKI management operations are described in Section 3.4.¶
The generic validation steps to be performed by PKI entities on receiving a CMP message are described in Section 3.5.¶
The generic aspects of handling and reporting errors are described in Section 3.6.¶
This section describes the generic header fields of all CMP messages with signature-based protection.¶
In case a message has MAC-based protection the changes are described in Section 4.1.5. The variations will affect the fields sender, protectionAlg, and senderKID.¶
Any PKI management operation-specific fields or variations are described in Section 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 RFC-CMP-Updates sender REQUIRED -- SHOULD contain a name representing the originator of the -- message; otherwise, the NULL-DN (a zero-length -- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- SHOULD be the subject of the CMP protection certificate, i.e., -- the certificate corresponding to the private key used to sign -- the message -- In a multi-hop scenario, the receiving entity SHOULD NOT 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 multi-hop scenario its -- correctness cannot be guaranteed. messageTime RECOMMENDED -- MUST be the time at which the message was produced, if present 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 a -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and -- MUST be consistent with the subjectPublicKeyInfo field of -- the protection certificate -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as -- specified in [RFC-CMP-Alg] Section 6.1 senderKID RECOMMENDED -- MUST be the SubjectKeyIdentifier of the CMP protection -- certificate in case of signature-based protection 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: SHOULD 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 -- RECOMENDED 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 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 [RFC-CMP-Updates] CertProfileValue REQUIRED -- MUST contain exactly one UTF8String element -- MUST contain the name of a certificate profile¶
This section describes the generic protection field contents of all CMP messages with signature-based protection. The private key used to sign a CMP message is called "protection key" and the related certificate 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 specified in Section 3.6 is not possible and therefore MAY be omitted.¶
For MAC-based protection as specified in Section 4.1.5 major differences apply as described there.¶
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 CMP Updates Section 2.2 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a sending PKI management entity.¶
This section describes the generic extraCerts field of all CMP messages with signature-based protection. Any specific requirements on the extraCerts are specified in the respective PKI management operation.¶
extraCerts -- SHOULD contain the CMP protection certificate together with -- its chain, if needed -- If present, 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. -- 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.¶
This subsection describes what is generally needed by the PKI entities to be able to perform PKI management operations.¶
Identification of PKI entities:¶
Each EE SHOULD 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, e.g., [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.¶
Note: This address may depend on the recipient, the certificate profile, and on the used transfer mechanism.¶
Authentication of PKI entities:¶
Each PKI entity MUST be able to establish trust in 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 usually is 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 for performing 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 DN or 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.¶
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, see also RFC 4210 Appendix F [RFC4210].¶
All PKI message header fields not mentioned in this section like the recipient and generalInfo fields SHOULD be handled gracefully on reception.¶
The following list describes the basic set of message input validation steps. Without these checks the protocol becomes dysfunctional.¶
The following list describes the set of message input validation steps required to ensure secure protocol operation:¶
Unless the PKI message is the first message of a PKI management operation,¶
The message protection MUST be validated:¶
Note: The requirements for checking certificates given in RFC 5280 [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.¶
Depending on local policies, one or more of the input validation checks described below need to be implemented:¶
This section describes how a PKI entity handles error conditions on messages it receives. Each error condition SHOULD be logged appropriately.¶
An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in upstream direction, either.¶
In case an EE rejects a newly issued certificate contained in an ip, cp, or kup message and implicit confirmation has not been granted, the EE MUST report this using a certConf message with "rejection" status and await the pkiConf response as described in Section 4.1.1.¶
On all other error conditions regarding response messages, the EE or PKI management entity MUST regard the current PKI management operation as terminated with failure. The error conditions include¶
Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. Then they also MUST regard the current PKI management operation as terminated with failure and MUST NOT attempt to send an error message downstream.¶
In case the PKI management entity detects an error condition, e.g., rejecting the request due to policy decision, in the body of an ir, cr, p10cr, kur, or rr message received from downstream, it SHOULD report the error in the specific response message, i.e., an ip, cp, kup, or rp with "rejection" status, as described in Section 4.1.1 and Section 4.2. This can also happen in case of polling.¶
In case the PKI management entity detects any other error condition on requests, including pollReq, certConf, genm, and nested messages, received from downstream and on responses received from upstream, such as invalid message header, body type, protection, or extraCerts according to the checks described in Section 3.5 it MUST report them downstream in the form of an error message as described in Section 3.6.4.¶
Batching of messages using nested messages as described in Section 5.2.2.2 requires special error handling.¶
If the error condition is on an upstream nested message containing batched requests, it MUST NOT attempt to respond to the individual requests included in it.¶
In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.¶
In case a PKI management entity detects an error condition on the downstream nested message received in response to a nested message sent before, it MAY ignore this error condition and handle the response as described in Section 5.2.2.2. Otherwise, it MUST propagate the error by responding with an error message to each of the requests contained in the nested message it sent originally.¶
When sending any kind of negative response, including error messages, a PKI entity MUST indicate the error condition in the PKIStatusInfo structure of the respective message as described below. It then MUST regard the current PKI management operation as terminated with failure.¶
The PKIStatusInfo structure is used to report errors. It may be part of various message types, in particular: certConf, ip, cp, kup, and error. The PKIStatusInfo structure consists of the following fields:¶
status: Here the PKIStatus value "rejection" MUST be used.¶
Note: When a PKI management entity indicates delayed delivery of a CMP response message to the EE with an error message as described in Section 4.4, the status "waiting" is used there.¶
failInfo: Here the PKIFailureInfo bits MAY be used in the way explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo bits regarding the validation described in Section 3.5 are referenced there. The PKIFailureInfo bits referenced in Section 5.1 and Section 6 are described here:¶
An EE receiving a systemUnavail or systemFailure failInfo 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 indicating the 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 and contain the relevant PKIFailureInfo bits protection REQUIRED -- As described in Section 3.2 extraCerts OPTIONAL -- As described in Section 3.3¶
This chapter focuses on the communication of an EE with the PKI management entity it directly talks to. Depending on the network and PKI solution, this can be an RA or directly a CA. Handling of a message by a PKI management entity is described in Section 5.¶
The PKI management operations specified in this section cover the following:¶
These operations mainly specify the message body of the CMP messages and utilize the specification of the message header, protection and extraCerts as specified in Section 3. The messages are named by the respective field names in PKIBody like ir, ip, cr, cp, etc., see RFC 4210 Section 5.1.2 [RFC4210].¶
The following diagram shows the EE state machine covering all PKI management operations described in this section, including negative responses, error messages described in Section 3.6.4, as well as ip/cp/kup/error messages with status "waiting", pollReq, and pollRep messages described in Section 4.4.¶
On receiving messages from upstream, the EE MUST perform the general validation checks described in Section 3.5. The behavior in case an error occurs is described in Section 3.6.¶
State machine: start | | send ir/cr/p10cr/kur/rr/genm v waiting for response | +--------------------------+--------------------------+ | | | | receives ip/cp/kup with | received ip/cp/kup/error | received | status "accepted" or | with status "waiting" | rp/genp or | "grantedWithMods" | | ip/cp/kup/ | v | error | +-------> polling | with status | | | | "rejection" | | received | send | | | pollRep | pollReq | | | v | | | waiting for response | | | | | | +------------+--------+ | | | | | | received ip/cp/kup | | received | | with status "accepted" | | rp/genp or | | or "grantedWithMods" | | ip/cp/kup/error | | | | with status | +---------->+<-------------+ | "rejection" | | | | +-----------+-----+ | | | | | | | implicitConfirm | implicitConfirm | | | granted | not granted | | | | | | | | send certConf | | | v | | | waiting for pkiConf*) | | | | | | | | received | | | | pkiConf | | +-----------------+------->+<-------+-----------------+ | v end *) in case of a delayed delivery of pkiConf responses the same polling mechanism is initiated as for rp or genp messages, by sending an error message with status "waiting".¶
Note: All CMP messages belonging to the same PKI management operation MUST have the same transactionID because the message receiver identifies the elements of the operation in this way.¶
This section is aligned with CMP [RFC4210], CMP Updates [I-D.ietf-lamps-cmp-updates], and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].¶
Guidelines as well as an algorithm use profile for this document are available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms].¶
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:¶
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 then MUST handle it as described in Section 5.1.3 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. 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 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 common 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 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 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 trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an initialization response (ir) 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.¶
This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e.g., a manufacturer-issued IDevID certificate [IEEE.802.1AR_2018], to authenticate itself to the new PKI.¶
Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) [I-D.ietf-anima-brski-async-enroll] describes a generalization regarding enrollment protocols alternative to EST [RFC7030]. As replacement of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapping LDevID certificates.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
Message flow:¶
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¶
For this PKI management operation, the EE MUST include exactly one CertReqMsg in the ir. If more certificates are required, further requests MUST be sent using separate PKI management operation.¶
The EE SHOULD include the implicitConfirm extension in the header of the ir message as described in Section 3.1, unless it knows that certificate confirmation is needed. This leaves the choice to the PKI management entities whether the EE must send a certConf message on receiving a new certificate. Depending on the PKI policy and requirements for managing EE certificates, it can be important for PKI management entities to learn if the EE accepted the new certificate. In such cases, when responding with an ip message, the PKI management entity MUST NOT include the implicitConfirm extension. In case the PKI management entity does not need any explicit confirmation from the EE, it MUST include the extension as described in Section 3.1. This prevents explicit certificate confirmation and saves the overhead of a further message round-trip.¶
If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation MUST be performed as follows. If the EE successfully received the certificate, it MUST send a certConf message in due time. On receiving a valid certConf message, the PKI management entity MUST respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time it MUST handle this like a rejection by the EE. In case of rejection, depending on its policy the PKI management entity MAY revoke the newly issued certificate, notify a monitoring system, or log the event internally.¶
Note: Depending on PKI policy, a new certificate may be published by a PKI management entity, and explicit confirmation may be required. In this case it is advisable not to do the publication until a positive certificate confirmation has been received. This way the need to revoke the certificate on negative confirmation is avoided.¶
If the certificate request was rejected by the CA, the PKI management entity must return an ip message containing the status code "rejection" as described in Section 3.6 and no certifiedKeyPair field. The EE MUST NOT react to such an ip message with a certConf message and the PKI management operation MUST be terminated.¶
Detailed message description:¶
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 exactly one CertReqMsg -- If more certificates are required, further PKI management -- operations MUST be initiated certReq REQUIRED certReqId REQUIRED -- MUST be 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 identifier subjectPublicKey REQUIRED -- MUST contain the public key to be certified in case of local -- key generation 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 RECOMMENDED -- MUST be used by an EE if the key can be used for signing and -- has 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 -- certTemplate 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 exactly 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 polling use case as described in -- Section 4.4 statusString OPTIONAL -- MAY be any human-readable text for debugging, 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 -- Self-signed certificates 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 as confirmation to the PKI -- management entity to accept or reject the issued certificates certConf REQUIRED -- MUST contain exactly one CertStatus CertStatus REQUIRED certHash REQUIRED -- MUST be the hash of the certificate, using the hash algorithm -- indicated in hashAlg, see below, or the same one as used to -- create the certificate signature certReqId REQUIRED -- MUST be 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 -- MAY be present if status is "rejection" -- MUST be absent if status is "accepted" hashAlg OPTIONAL -- The hash algorithm to use for calculating certHash -- SHOULD NOT be used in all cases where the AlgorithmIdentifier -- of the certificate signature specifies a hash algorithm -- If used, the pvno field in the header MUST be cmp2021 (3) 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 extraCerts 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 extraCerts from the first response message of -- this PKI management operation¶
This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The EE uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes:¶
This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certificate it wishes to update as the protection certificate. Both for authenticating itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes:¶
As part of the certReq structure of the kur the oldCertId control is added after the certTemplate field.¶
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¶
This PKI management operation can be used by an EE to request a certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF [RFC4211]. This offers a variation of the PKI management operations specified in Section 4.1.2.¶
In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr message as a form of certificate signing request (CSR) to optionally include in device bootstrapping to obtain an identity certificate as part of the onboarding information. Such a CSR is of form ietf-sztp-types:cmp-csr from module ietf-sztp-csr. The requirements given below on p10cr message MUST be adhered to.¶
In this PKI management operation, the public key and all further certificate template data MUST be contained in the subjectPKInfo and other certificationRequestInfo fields of the PKCS#10 structure.¶
The prerequisites are the same as given in Section 4.1.2.¶
The message sequence for this PKI management operation is identical to that given in Section 4.1.2, with the following changes:¶
Detailed description of the p10cr message:¶
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 a 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 for the underlying PKI management operation extraCerts REQUIRED -- As described for the underlying PKI management operation¶
This is a variant of the PKI management operations described in Section 4.1.1 to Section 4.1.4. It should be used by an EE to request a certificate of a new PKI in case it does not have a certificate to prove its identity to the target PKI, but has some secret information shared with the PKI management entity. Therefore, the request and response messages are MAC-protected using this shared secret information. The distribution of this shared secret is out of scope for this document. The PKI management entity checking the MAC-based protection SHOULD replace this protection according to Section 5.2.3 in case the next hop does not know the shared secret information.¶
Note: The entropy of the shared secret information is crucial for the level of protection when using MAC-based protection. Further guidance is available in the security considerations of CMP updated by [I-D.ietf-lamps-cmp-updates].¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
Rather than using private keys, certificates, and trust anchors, the EE and the PKI management entity MUST share secret information.¶
Note: The shared secret information MUST be established out-of-band, e.g., by a service technician during initial local configuration.¶
The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes:¶
See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for details on message authentication code algorithms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg field, e.g., used for key derivation, like a salt and an iteration count. Such fields SHOULD remain constant for message protection throughout this PKI management operation to reduce the computational overhead.¶
This is a variant of the PKI management operations described in Section 4.1.1 to Section 4.1.4 and the variant described in Section 4.1.5. It needs to be used in case an EE is not able to generate its new public-private key pair itself or central generation of the EE key material is preferred. It is a matter of the local implementation which PKI management entity will act as Key Generation Authority (KGA) and perform the key generation. This PKI management entity MUST use a certificate containing the additional extended key usage extension id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority.¶
As described in Section 5.3.1, the KGA can use one of the PKI management operations described in the sections above to request the certificate for this key pair on behalf of the EE.¶
Generally speaking, in machine-to-machine scenarios it is strongly preferable to generate public-private key pairs locally at the EE. Together with proof-of-possession of the private key in the certificate request, this is advisable to make sure that the entity identified in the newly issued certificate is the only entity that knows the private key.¶
Reasons for central key generation may include the following:¶
Lack of sufficient initial entropy.¶
Note: Good random numbers are needed not only for key generation but also for session keys and nonces in any security protocol. Therefore, a decent security architecture should anyways support good random number generation on the EE side or provide enough initial entropy for the RNG seed to guarantee good pseudo-random number generation. Yet maybe this is not the case at the time of requesting an initial certificate during manufacturing.¶
Lack of computational resources, in particular for RSA key generation.¶
Note: Since key generation could be performed in advance to the certificate enrollment communication, it is often not time critical.¶
Note: As mentioned in Section 2, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.¶
The EE requesting central key generation MUST omit the publicKey field from the certTemplate or, in case it has a preference on the key type to be generated, provide it in the algorithm sub-field and fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both variants indicate to the PKI management entity that a new key pair shall be generated centrally on behalf of the EE.¶
Note: As the protection of centrally generated keys in the response message has been extended to EncryptedKey by CMP Updates Section 2.7 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile requires using EnvelopedData as specified in CMS Section 6 [RFC5652]. When EnvelopedData is to be used in a PKI management operation, CMP v3 MUST be indicated in the message header already for the initial request message, see CMP Updates Section 2.19 and Section 2.20 [I-D.ietf-lamps-cmp-updates].¶
+----------------------------------+ | EnvelopedData | | [RFC5652] section 6 | | +------------------------------+ | | | SignedData | | | | [RFC5652] section 5 | | | | +--------------------------+ | | | | | AsymmetricKeyPackage | | | | | | [RFC5958] | | | | | | +----------------------+ | | | | | | | privateKey | | | | | | | | OCTET STRING | | | | | | | +----------------------+ | | | | | +--------------------------+ | | | +------------------------------+ | +----------------------------------+
The PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message also containing the newly issued certificate.¶
The private key MUST be provided as an AsymmetricKeyPackage structure as defined in RFC 5958 [RFC5958].¶
This AsymmetricKeyPackage structure MUST be wrapped in a SignedData structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], signed by the KGA generating the key pair. The signature MUST be performed using a private key related to a certificate asserting the extended key usage id-kp-cmKGA as described in CMP Updates Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate key pairs on behalf of an EE. The EE SHOULD validate the signer certificate contained in the SignedData structure and verify the presence of this extended key usage in the signer certificate.¶
Note: When using password-based key management technique as described in Section 4.1.6.3 it may not be possible or meaningful to the EE to validate the KGA signature and the related certificate in the SignedData structure since shared secret information is used for initial authentication. In this case the EE MAY omit this validation.¶
The SignedData structure MUST be wrapped in an EnvelopedData structure, as specified in CMS Section 6 [RFC5652], encrypting it using a newly generated symmetric content-encryption key.¶
This content-encryption key MUST be securely provided as part of the EnvelopedData structure to the EE using one of three key management techniques. The choice of the key management technique to be used by the PKI management entity depends on the authentication mechanism the EE chose to protect the request message. See CMP Updates Section 2.7 [I-D.ietf-lamps-cmp-updates] for more details on which key management technique to use.¶
Signature-based protection of the request message:¶
MAC-based protected of the request message:¶
If central key generation is supported, support of the key agreement key management technique is REQUIRED and support of key transport and password-based key management techniques are OPTION, for two reasons: The key agreement key management technique is supported by most asymmetric algorithms, while the key transport key management technique is supported only by a very few of them. The password-based key management technique shall only be used in combination with MAC-based protection, which is a sideline in this document.¶
Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations:¶
For encrypting the SignedData structure a fresh content-encryption key to be used by the symmetric encryption algorithm MUST be generated with sufficient entropy.¶
Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.¶
The detailed description of the privateKey field as follows:¶
privateKey OPTIONAL -- MUST be an EnvelopedData structure as specified in CMS -- Section 6 [RFC5652] version REQUIRED -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and -- KeyTransRecipientInfo -- MUST be 0 for recipientInfo type PasswordRecipientInfo recipientInfos REQUIRED -- MUST contain exactly one RecipientInfo, which MUST be -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), -- ktri of type KeyTransRecipientInfo (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 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] and [RFC8933] in encrypted form version REQUIRED -- MUST be 3 digestAlgorithms REQUIRED -- MUST contain exactly 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 and [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 exactly 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 exactly 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 digestAlgorithms 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 signature -- For details on the signed attributes see CMS Section 5.3 and -- Section 11 [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 a MSG_SIG_ALG as -- specified in RFC-CMP-Alg Section 3 and MUST be consistent -- with the subjectPublicKeyInfo field of the KGA certificate signature REQUIRED -- MUST be the digital signature of the encapContentInfo¶
NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that are defined in RFC 5652 [RFC5652] but are not explicitly specified here SHOULD NOT be used.¶
This variant can be applied in combination with the PKI management operations specified in Section 4.1.1 to Section 4.1.3 using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST allow for the key usage "keyAgreement" and therefore, the related key pair MUST be used for establishment of the content-encryption key. For this key management technique the KeyAgreeRecipientInfo structure MUST be used in the contentInfo field.¶
The KeyAgreeRecipientInfo structure included into the EnvelopedData structure is specified in CMS Section 6.2.2 [RFC5652].¶
The detailed description of the KeyAgreeRecipientInfo structure looks like this:¶
kari REQUIRED -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section -- 6.2.2 [RFC5652] version REQUIRED -- MUST be 3 originator REQUIRED -- MUST contain the subjectKeyIdentifier of the certificate, -- and thereby identifies the sender's public key. -- MUST contain the same value as the senderKID in the -- message header ukm RECOMMENDED -- MUST be used when 1-pass ECMQV is used -- 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 a KM_KA_ALG as specified in -- RFC-CMP-Alg Section 4.1 -- The parameters field of the key agreement algorithm MUST -- contains the key wrap algorithm -- The algorithm type 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 message header encryptedKey REQUIRED -- MUST be the encrypted content-encryption key¶
This variant can be applied in combination with the PKI management operations specified in Section 4.1.1 to Section 4.1.3 using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST allow for the key usage "keyEncipherment" and not for "keyAgreement". Therefore, the related key pair MUST be used for encipherment of the content-encryption key. For this key management technique, the KeyTransRecipientInfo structure MUST be used in the contentInfo field.¶
The KeyTransRecipientInfo structure included into the EnvelopedData structure is specified in CMS Section 6.2.1 [RFC5652].¶
The detailed description of the KeyTransRecipientInfo structure looks like this:¶
ktri REQUIRED -- MUST be a KeyTransRecipientInfo as specified in CMS -- Section 6.2.1 [RFC5652] version REQUIRED -- MUST be 2 rid REQUIRED -- MUST contain the subjectKeyIdentifier choice subjectKeyIdentifier REQUIRED -- MUST contain the same value as the senderKID in the -- respective request message header keyEncryptionAlgorithm REQUIRED -- MUST be the algorithm identifier of the key transport -- algorithm -- The algorithm type MUST be a KM_KT_ALG as specified in -- RFC-CMP-Alg Section 4.2 encryptedKey REQUIRED -- MUST be the encrypted content-encryption key¶
This variant can be applied in combination with the PKI management operation specified in Section 4.1.5 using MAC-based protection of CMP messages. The shared secret information used for the MAC-based protection MUST also be used for the encryption of the content-encryption key but with a different salt value applied in the key derivation algorithm. For this key management technique, the PasswordRecipientInfo structure MUST be used in the contentInfo field.¶
Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the shared secret information SHALL NOT be less than the security strength of the centrally generated key pair. Further guidance is available in Section 9.¶
The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in CMS Section 6.2.4 [RFC5652].¶
The detailed description of the PasswordRecipientInfo structure looks like this:¶
pwri REQUIRED -- MUST be a PasswordRecipientInfo as specified in CMS -- Section 6.2.4 [RFC5652] version REQUIRED -- MUST be 0 keyDerivationAlgorithm REQUIRED -- MUST be the algorithm identifier of the key derivation -- algorithm -- The algorithm type MUST be a KM_KD_ALG as specified in -- RFC-CMP-Alg Section 4.4 keyEncryptionAlgorithm REQUIRED -- MUST be the algorithm identifier of the key wrap algorithm -- The algorithm type MUST be a KM_KW_ALG as specified in -- RFC-CMP-Alg Section 4.3 encryptedKey REQUIRED -- MUST be the encrypted content-encryption key¶
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 the revocation of an own certificate at the CA that issued this certificate. The PKI management entity handles the request as described in Section 5.1.4 and responds with a message that contains the status of the revocation from the CA.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
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 exactly one RevDetails structure in the rr message body. In 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 exactly one element of type RevDetails -- If more revocations are desired, further PKI management -- operations MUST 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 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 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¶
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.5).¶
The general messages and general response messages contain InfoTypeAndValue structures. In addition to those infoType values defined in RFC 4210 [RFC4210] and CMP Updates [I-D.ietf-lamps-cmp-updates] 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:¶
In the following the aspects common to all general messages (genm) and general response (genp) messages are described.¶
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 exactly 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 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 specified for the specific PKI management operation protection REQUIRED -- As described in Section 3.2 extraCerts REQUIRED -- As described in Section 3.3¶
This PKI management operation can be used by an EE to request CA certificates from the PKI management entity.¶
An EE requests CA certificates, e.g., for chain construction, from an PKI management entity by sending a general message with OID id-it-caCerts as specified in CMP Updates Section 2.13 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds with a general response with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or with no content in case no CA certificate is available.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
The message sequence for this PKI management operation is as given above, with the following specific content:¶
The infoValue field of the general response containing the id-it-caCerts OID looks like this:¶
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¶
This PKI management operation can be used by an EE to request an updated root CA Certificate as described in Section 4.4 of RFC 4210 [RFC4210].¶
An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it-rootCaCert, which SHOULD include the old root CA certificate in the message body, as specified in CMP Updates Section 2.14 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds with a general response with OID id-it-rootCaKeyUpdate that either contains the update of the root CA certificate consisting of up to three certificates, or with no content in case no update is available.¶
Note: This mechanism may also be used to update trusted non-root certificates, i.e., trusted intermediate CA or issuing CA certificates.¶
The newWithNew certificate is the new root CA certificate and is REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present in the response message because it is needed for the receiving entity trusting the old root CA certificate to gain trust in the new root CA certificate. The oldWithNew certificate is OPTIONAL because it is only needed in rare scenarios where entities do not already trust the old root CA.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
The message sequence for this PKI management operation is as given above, with the following specific content:¶
The infoValue field of the general request containing the id-it-rootCaCert OID looks like this:¶
infoValue RECOMMENDED -- MUST contain the root CA certificate to be updated, if -- available¶
The infoValue field of the general response containing the id-it-rootCaKeyUpdate OID looks like this:¶
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¶
This PKI management operation can be used by an EE to request a template with parameters for future certificate requests.¶
An EE requests certificate request parameters from the PKI management entity by sending a general message with OID id-it-certReqTemplate as specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. The EE MAY indicate the certificate profile to use in the id-it-certProfile extension of the generalInfo field in the PKIHeader of the general message as described in Section 3.1. The PKI management entity responds with a general response with the same OID that either contains requirements on the certificate request template, or with no content in case no specific requirements are imposed by the PKI. The CertReqTemplateValue contains requirements on certificate fields and extensions in a certTemplate. Optionally it contains a keySpec field containing requirements on algorithms acceptable for key pair generation.¶
The EE SHOULD follow the requirements from the received CertTemplate, by including in the certificate requests all the fields requested, taking over all the field values provided and filling in any remaining fields values. The EE SHOULD NOT add further fields, name components, and extensions or their (sub-)components.¶
Note: We deliberately do not use "MUST" or "MUST NOT" here in order to allow more flexibility in case the rules given here are not sufficient for specific scenarios. The EE can populate the certificate request as wanted and ignore any of the requirements contained in the CertReqTemplateValue. On the other hand, a PKI management entity is free to ignore or replace any parts of the content of the certificate request provided by the EE. The CertReqTemplate PKI management operation offers means to ease a joint understanding which fields and/or which field values should be used. An example is provided in Appendix A.¶
In case a field of type Name, e.g., subject, is present in the CertTemplate but has the value NULL-DN (i.e., has an empty list of RDN components), the field SHOULD be included in the certificate request and filled with content provided by the EE. Similarly, in case an X.509v3 extension is present but its extnValue is empty, this means that the extension SHOULD be included and filled with content provided by the EE. In case a Name component, for instance a common name or serial number, is given but has an empty string value, the EE SHOULD fill in a value. Similarly, in case an extension has sub-components (e.g., an IP address in a SubjectAltName field) with empty value, the EE SHOULD fill in a value.¶
The EE MUST ignore (i.e., not include and fill in) empty fields, extensions, and sub-components that it does not understand or does not know suitable values to be filled in.¶
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue MUST be omitted. In case the PKI management entity wishes to make stipulation on algorithms the EE may use for key generation, this MUST be specified using the keySpec field as specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates].¶
The keySpec field, if present, specifies the public key types optionally with parameters, and/or RSA key lengths for which a certificate may be requested.¶
The value of a keySpec element with the OID id-regCtrl-algId, as specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], MUST be of type AlgorithmIdentifier and give an algorithm other than RSA. For EC keys the curve information MUST be specified as described in the respective standard documents.¶
The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], MUST be a positive integer value and give an RSA key length.¶
In the CertTemplate of the CertReqTemplateValue the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST be omitted.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
The message sequence for this PKI management operation is as given above, with the following specific content:¶
The infoValue field of the general response containing the id-it-certReqTemplate OID looks like this:¶
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 one AttributeTypeAndValue per supported -- algorithm with attribute id-regCtrl-algId or -- id-regCtrl-rsaKeyLen¶
This PKI management operation can be used by an EE to request a new CRL. If a CA offers methods to access a CRL, it may include CRL distribution points or authority information access extensions as specified in RFC 5280 [RFC5280] into the issued certificates. In addition, CMP offers CRL provisioning functionality as part of the PKI management operation.¶
An EE requests a CRL update from the PKI management entity by sending a general message with OID id-it-crlStatusList. The EE MUST include the CRL source identifying the requested CRL and, if available, the thisUpdate time of the most current CRL instance it already has, as specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond with a general response with OID id-it-crls. If no thisUpdate value was given by the EE, the PKI management entity MUST return the latest CRL available. If a thisUpdate value was given, the PKI management entity MUST return the latest available CRL in case this CRL is more recent, otherwise the infoValue in the response message MUST be absent.¶
The EE MUST identify the requested CRL either by its CRL distribution point name or issuer name. The CRL distribution point name can either be provided form the CRL distribution points extension of the certificate to be validated or from the issuing distribution point extension from the CRL to be updated. If no CRL distribution name is available to identify the CRL, the EE can use the issuer name either from the certificate to be validated or from the CRL to be updated.¶
The PKI management entity SHOULD treat a CRL distribution point name as an internal pointer to identify a CRL for which is available at the PKI management entity directly. It is not intended as a way to fetch an arbitrary CRL from an external location.¶
In addition to the prerequisites specified in Section 3.4, the EE MUST know which CRL to request.¶
Note: If the EE does not want to request a specific CRL it MAY use instead a general message with OID id-it-currentCrl as specified in RFC 4210 Section 5.3.19.6 [RFC4210].¶
The message sequence for this PKI management operation is as given above, with the following specific content:¶
The infoValue field of the general request containing the id-it-crlStatusList OID looks like this:¶
CRLSource REQUIRED -- MUST contain exactly one CRLSource structure -- 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 -- SHOULD contain the thisUpdate field of the latest CRL form -- the issuer specified in the given dpn or issuer field, -- in case such a CRL is already known by the EE¶
The infoValue field of the general response containing the id-it-crls OID looks like this:¶
infoValue OPTIONAL -- MUST be absent if no CRL to be returned is available -- MUST contain one CRL update from the referenced source, if a -- thisUpdate value was not given or a more recent CRL is -- available¶
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 RFC 4210 Section 5.3.22 [RFC4210] and updated by [I-D.ietf-lamps-cmp-updates].¶
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 an ip/cp/kup/error message including the status "waiting". 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. 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 original request 15 <- response <- 16 handle final response¶
Detailed description of the ip/cp/kup/error response, pollReq, and pollRep:¶
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, 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 extraCerts 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 -- 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 -- 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 extraCerts 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¶
This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).¶
A PKI management entity may directly respond to request messages from downstream and report errors. In case the PKI management entity is an RA it typically forwards the received request messages upstream after checking them and forwards respective response messages downstream. Besides responding to messages or forwarding them, a PKI management entity may request or revoke certificates on behalf of EEs. A PKI management entity may also need to manage its own certificates and thus act as an EE using the PKI management operations specified in Section 4.¶
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 SHOULD 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 on reporting failure as described in Section 3.6.4 is transactionIdInUse. If any of these verification steps or any of the essential checks described in the following subsections fails, the PKI management entity MUST proceed as described in Section 3.6.¶
The responding PKI management entity SHOULD 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.¶
An ir/cr/p10cr/kur message is used to request a certificate as described in Section 4.1. The responding PKI management entity MUST proceed as follows unless it initiates delayed delivery as described in Section 5.1.2.¶
The PKI management entity SHOULD check the message body according to the applicable requirements from Section 4.1. Possible failInfo bit values used for error reporting in case a check failed include badCertId and badCertTemplate. It MUST verify the presence and value of the proof-of-possession (failInfo bit: badPOP), unless central key generation is requested. In case the special POP value "raVerified" is given, it SHOULD check that the request message was signed using a certificate containing the cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management entity SHOULD perform also any further checks on the certTemplate contents (failInfo: badCertTemplate) according to any applicable PKI policy and certificate profile.¶
If the requested certificate is available, the PKI management entity MUST respond with a positive ip/cp/kup message as described in Section 4.1.¶
Note: If central key generation is performed by the responding PKI management entity, the responding PKI management entity MUST include in the response the privateKey field as specified in Section 4.1.6. It may have issued the certificate for the newly generated key pair itself if it is a CA, or have requested the certificate on behalf of the EE as described in Section 5.3.1, or have received it by other means from a CA.¶
The prerequisites of the respective PKI management operation as specified in Section 4.1 apply.¶
Note: If the EE requested omission of the certConf message, the PKI management entity SHOULD handle it as described in Section 4.1.1 and therefore MAY grant this by including the implicitConfirm extension in the response header.¶
This functional extension can be used by a PKI management entity in case the response to a request takes longer than usual. In this case the PKI management entity MUST completely validate the request as usual and then start preparing the response or forward the request further upstream as soon as possible. In the meantime, it MUST respond with an ip/cp/kup/error message including the status "waiting" and handle subsequent polling as described in Section 4.4.¶
Note: Typically, as stated in Section 5.2.3, an intermediate PKI management entity should not change the sender and recipient nonces even in case it modifies a request or a response message. In the special case of delayed delivery initiated by an intermediate PKI management entity, there is an exception. Between the EE and this PKI management entity, pollReq and pollRep messages are exchanged handling the nonces as usual. Yet when the final response from upstream has arrived at the PKI management entity, this response contains the recipNonce copied (as usual) from the senderNonce in the original request message. The PKI management entity that initiated the delayed delivery may replace the recipNonce in the response message with the senderNonce of the last received pollReq because the downstream entities, including the EE, might expect it in this way. Yet the check specified in Section 3.5 allows to alternatively use the senderNonce of the original request.¶
No specific prerequisites apply in addition to those of the respective PKI management operation.¶
A PKI management entity MUST handle a certConf message if it has responded before with a positive ip/cp/kup message not granting implicit confirmation. It SHOULD check the message body according to the requirements given in Section 4.1.1 (failInfo bit: badCertId) and react as described there.¶
The prerequisites of the respective PKI management operation as specified in Section 4.1 apply.¶
An rr message is used to request revocation of a certificate. The responding PKI management entity SHOULD check the message body according to the requirements in Section 4.2. It MUST make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or revoked (failInfo bit: certRevoked). On success it MUST respond with a positive rp message as described in Section 4.2.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
A genm message is used to retrieve extra content. The responding PKI management entity SHOULD check the message body according to the applicable requirements in Section 4.3 and perform any further checks depending on the PKI policy. On success it MUST respond with a genp message as described there.¶
Note: The responding PKI management entity may generate the response from scratch or reuse the contents of previous responses. Therefore, it may be worth caching the body of the response message as long as the contained information is still valid, such that further requests for the same contents can be answered immediately.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
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 SHOULD be forwarded to the next (upstream) PKI management entity as described in this section and otherwise MUST be answered as described in Section 5.1. Any received response message or 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/p10cr/kur 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 necessary. The PKI management entity SHOULD only update the message protection and the certificate template in a certificate request message 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 forwarding PKI management entity has one or more functionalities. It may¶
The decision if a message should be forwarded¶
depends on the PKI solution design and the associated security policy (CP/CPS [RFC3647]).¶
A PKI management entity MUST replace or add a protection of a message if it¶
A PKI management entity MUST replace a protection of a message if it¶
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.¶
This variant means that a PKI management entity forwards a CMP message without changing the header, body, or protection. In this case the PKI management entity acts more like a proxy, e.g., on a network boundary, implementing no specific RA-like security functionality that requires an authentic indication to the PKI. Still the PKI management entity might implement checks that result in refusing to forward the request message and instead responding as specified in Section 3.6.¶
This variant of forwarding a message or the one described in Section 5.2.2.1 SHOULD be used for kur messages and for central key generation.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
This variant of forwarding a message means that a PKI management entity adds another protection to PKI management messages before forwarding them.¶
The nested message is a PKI management message containing a PKIMessages sequence as its body containing one or more CMP messages.¶
As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there are various use cases for adding another protection by a PKI management entity. Specific procedures are described in more detail in the following sections.¶
Detailed message description:¶
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¶
A PKI management entity may authentically indicate successful validation and approval of a request message by adding an extra signature to the original message.¶
By adding a protection using its own CMP protecting key the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI. Applying an additional protection is specifically relevant when forwarding a message that requests a certificate update or central key generation. This is because the original protection of the EE must be preserved while adding an indication of approval by the PKI management entity.¶
The PKI management entity wrapping the original request message in a nested message structure MUST take over the recipient, recipNonce, and transactionID of the original message to the nested message and apply signature-based protection. The additional signature serves as proof of verification and authorization by this PKI management entity.¶
The PKI management entity receiving such a nested message that contains a single request message MUST validate the additional protection signature on the nested message and check the authorization for the approval it implies.¶
The PKI management entity responding to the request contained in the nested message sends the response message as described in Section 5.1, without wrapping it in a nested message.¶
Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is the same as the one used in the included message.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
Message flow:¶
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¶
A PKI management entity MAY bundle any number of PKI management messages for batch processing or to transfer a bulk of PKI management messages using the nested message structure. In this use case, nested messages are used both on the upstream interface towards the next PKI management entity and on the downstream interface from the PKI management entity towards the EE.¶
This PKI management operation is typically used on the interface between an LRA and an RA to bundle several messages for offline delivery. In this case the LRA needs to initiate delayed delivery as described in Section 5.1.2. If the RA needs different routing information per nested PKI management message a suitable mechanism may need to be implemented. Since this mechanism strongly depends on the requirements of the target architecture, it is out of scope of this document.¶
A nested message containing requests is generated locally at the PKI management entity. For the upstream nested message, the PKI management entity acts as a protocol end point and therefore a fresh transactionID and a fresh senderNonce MUST be used in the header of the nested message. An upstream nested message may contain request messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. While building the upstream nested message the PKI management entity SHOULD store the sender, transactionID, and senderNonce fields of all bundled messages together with the transactionID of the upstream nested message.¶
Such an upstream nested message is sent to the next PKI management entity. The upstream PKI management entity that unbundles it MUST handle each of the included request messages as usual. It MUST answer with a downstream nested message. This downstream nested message MUST use the transactionID of the upstream nested message and return the senderNonce of the upstream nested message as the recipNonce of the downstream nested message. The downstream nested message SHOULD bundle the individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp, genp, error) for all original request messages of the upstream nested message. While unbundling the downstream nested message, the former PKI management entity can determine lost and unexpected responses based on the previously stored transactionIDs. When it forwards the unbundled responses, any extra messages SHOULD be dropped, and any missing response message (failInfo bit: systemUnavail) MUST be answered with an error message to inform the respective requester about the failed certificate management operation.¶
Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is different to those used in the included messages.¶
The protection of the nested messages SHOULD NOT be regarded as an indication of verification or approval of the bundled PKI request messages.¶
No specific prerequisites apply in addition to those specified in Section 3.4.¶
Message flow:¶
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¶
The following two alternatives can be used by any PKI management entity forwarding a CMP message with or without changes while providing its own protection and in this way asserting approval of the message.¶
By replacing the existing protection using its own CMP protecting key the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI.¶
Before replacing the existing protection by a new protection, the PKI management entity MUST verify the protection provided and approve its content, including any modifications that it may perform. It MUST also check that the sender, as authenticated by the message protection, is authorized for the given operation.¶
These message adaptations MUST NOT be applied to kur messages described in Section 4.1.3 since their original protection using the key and certificate to be updated needs to be preserved, unless the regCtrl OldCertId is used to strongly identify the certificate to be updated.¶
These message adaptations MUST NOT be applied to certificate request messages described in for central key generation Section 4.1.6 since their original protection needs to be preserved up to the Key Generation Authority, which needs to use it for encrypting the new private key for the EE.¶
In both the kur and central key generation cases, if a PKI management entity needs to state its approval of the original request message it MUST provide this using a nested message as specified in Section 5.2.2.1.¶
When an intermediate PKI management entity modifies a message, it SHOULD NOT change the transactionID nor the sender and recipient nonces.¶
This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or body while preserving any included proof-of-possession.¶
In case the PKI management entity breaks an existing proof-of-possession, the message adaptation described in Section 5.2.3.2 needs to be applied instead.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
This variant of forwarding a message needs to be used if a PKI management entity breaks a signature-based proof-of-possession in a certificate request message, for instance because it forwards an ir or cr message with modifications of the certTemplate, i.e., modification, addition, or removal of fields.¶
The PKI management entity MUST verify the proof-of-possession contained in the original message using the included public key. If successful, the PKI management entity MUST change the popo field value to raVerified.¶
Specific prerequisites augmenting the prerequisites in Section 3.4:¶
The new popo field MUST contain the raVerified choice in the certReq structure of the modified message as follows:¶
popo raVerified REQUIRED -- MUST have the value NULL and indicates that the PKI -- management entity verified the popo of the original message¶
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.¶
A PKI management entity may use on of the PKI management operations described in Section 4.1 to request a certificate on behalf of another PKI entity. It either generates the key pair itself and inserts the new public key in the subjectPublicKey field of the request certTemplate, or it uses a certificate request received from downstream, e.g., by means of a different protocol. In the latter case it SHOULD verify the received proof-of-possession.¶
No specific prerequisites apply in addition to those specified in Section 4.1.¶
Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the one described in Section 5.2.3 because in both cases the message is protected by the PKI management entity.¶
The message sequence for this PKI management operation is identical to the respective PKI management operation given in Section 4.1, with the following changes:¶
A PKI management entity may use the PKI management operation described in Section 4.2 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.¶
No specific prerequisites apply in addition to those specified in Section 4.2.¶
Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the ones described in Section 5.2.3.¶
The message sequence for this PKI management operation is identical to that given in Section 4.2, with the following changes:¶
CMP messages are designed to be self-contained, such that in principle any reliable transfer mechanism can be used. HTTP SHOULD and CoAP MAY be used for online transfer. CMP messages MAY also be piggybacked on any other reliable transfer protocol. File-based transfer MAY be used in case offline transfer is required.¶
Independently of the means of transfer, it can happen that messages are lost or that a communication partner does not respond. To prevent waiting indefinitely, each CMP client component SHOULD use a configurable per-request timeout, and each CMP server component SHOULD use a configurable per-response timeout in case a further Request message is to be expected from the client side within the same transaction. In this way a hanging transaction can be closed cleanly with an error as described in Section 3.6 (failInfo bit: systemUnavail) and related resources (for instance, any cached extraCerts) can be freed.¶
Moreover, there are various situations where the delivery of messages gets delayed. For instance, a serving PKI management entity might take longer than expected to form a response due to administrative processes, resource constraints, or upstream message delivery delays. The transport layer itself may cause delays, for instance due to offline transport, network segmentation, or intermittent network connectivity. Part of these issues can be detected and handled at CMP level using pollReq and pollRep messages as described in Section 4.4, while others are better handled at transfer level. Depending on the transfer protocol and system architecture, solutions for handling delays at transfer level may be present and can be used for CMP connections, for instance connection re-establishment and message retransmission.¶
Note: Long timeout periods are helpful to minimize the need for polling and maximize chances to handle transfer issues at lower levels.¶
Note: When using TCP and similar reliable connection-oriented transport protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This may improve efficiency, though is not required from a security point of view.¶
When conveying CMP messages in HTTP, CoAP, or MIME-based transfer protocols, the internet media type "application/pkixcmp" MUST be set for transfer encoding as specified in Section 5.3 of RFC 2510 [RFC2510], Section 2.4 of CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP [RFC6712].¶
This transfer mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transfer 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 URI paths consisting of '/.well-known/cmp/' followed by an operation label depending on the type of PKI management operation.¶
PKI management operation | operation label | Details |
---|---|---|
Enroll client to new PKI | /initialization | Section 4.1.1 |
Enroll client to existing PKI | /certification | Section 4.1.2 |
Update client certificate | /keyupdate | Section 4.1.3 |
Enroll client using PKCS#10 | /p10 | Section 4.1.4 |
Revoke client certificate | /revocation | Section 4.2 |
Get CA certificates | /getcacerts | Section 4.3.1 |
Get root CA certificate update | /getrootupdate | Section 4.3.2 |
Get certificate request template | /getcertreqtemplate | Section 4.3.1 |
Get CRL updates | /getcrls | Section 4.3.4 |
Batching messages¶ Note: This path element is applicable only between PKI management entities.¶ |
/nested | Section 5.2.2.2 |
Independently of any variants used (see Section 4.1.5, Section 4.1.6, and Section 4.4) the operation label corresponding to the PKI management operation SHALL be used.¶
Any certConf or pollReq messages are 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 is 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, also confidentiality is 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 [RFC2818]. The CMP transfer via HTTPS MUST use TLS server authentication and SHOULD use TLS client authentication.¶
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 is acceptable using shared secret information with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is RECOMMENDED.¶
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 as described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed.¶
PKI management operations SHOULD use URI paths consisting of '/.well-known/cmp/' followed by an operation label depending on the type of PKI management operation.¶
PKI management operation | operation label | Details |
---|---|---|
Enroll client to new PKI | /ir | Section 4.1.1 |
Enroll client to existing PKI | /cr | Section 4.1.2 |
Update client certificate | /kur | Section 4.1.3 |
Enroll client using PKCS#10 | /p10 | Section 4.1.4 |
Revoke client certificate | /rr | Section 4.2 |
Get CA certificates | /crts | Section 4.3.1 |
Get root CA certificate update | /rcu | Section 4.3.2 |
Get certificate request template | /att | Section 4.3.3 |
Get CRL updates | /crls | Section 4.3.4 |
Batching messages¶ Note: This path element is applicable only between PKI management entities.¶ |
/nest | Section 5.2.2.2 |
Independently of any variants used (see Section 4.1.5, Section 4.1.6, and Section 4.4) the operation label corresponding to the PKI management operation SHALL be used.¶
Any certConf or pollReq messages are 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 is 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 [I-D.ietf-ace-cmpv2-coap-transport].¶
CMP messages MAY also be transfer on some other reliable protocol. Connection, delay, and error handling mechanisms similar to those specified for HTTP in Section 6.1 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.¶
For transferring 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 transfer mechanism SHOULD be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases the PKI entities SHOULD report an error as specified in Section 3.6 as far as possible.¶
CMP messages MAY be transferred between PKI entities using file-based mechanisms, for instance when an offline EE or a PKI management entity performs delayed delivery. Each file MUST contain the ASN.1 DER encoding of one CMP message only, where the message may be nested. There MUST be no extraneous header or trailer information in the file. The file name extension ".pki" MUST be used.¶
Other asynchronous transfer protocols, e.g., email or website up-/download, MAY transfer CMP messages between PKI entities. A MIME wrapping is defined for those environments that are MIME-native. The MIME wrapping in this section is specified in RFC 8551 Section 3.1 [RFC8551].¶
The ASN.1 DER encoding of the CMP messages MUST be transferred using the "application/pkixcmp" content type and base64-encoded content transfer encoding as specified in [RFC2510], section 5.3. A filename MUST be included either in a "content-type" or a "content-disposition" statement. The file name extension ".pki" MUST be used.¶
This section defines which level of support for the various features specified in this profile is required for which type of PKI entity.¶
The following table provides an overview of the PKI management operations specified in Section 4 and Section 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.¶
ID | PKI management operations and variants | EE | RA | CA |
---|---|---|---|---|
Generic | generic aspects of PKI management operations, Section 3 | MUST | MUST | MUST |
IR | Requesting a certificate from a new PKI with signature-based protection, Section 4.1.1 | MUST | MUST | MUST |
CR | Requesting an additional certificate with signature-based protection, Section 4.1.2 | MAY | MAY | MAY |
KUR | Updating an existing certificate with signature-based protection, Section 4.1.3 | MUST | MUST | MUST |
P10CR | Requesting a certificate from a legacy PKI using a PKCS#10 request, Section 4.1.4 | MAY | MAY | MAY |
MAC | Requesting a certificate from a PKI with MAC-based protection (IR, CR, KUR, and P10CR if supported), Section 4.1.5 | SHOULD | SHOULD | SHOULD |
CKeyGen | Adding central key generation to a certificate request (IR, CR, KUR, and P10CR if supported). (If supported, key agreement key management technique is REQUIRED, and key transport and password-based key management techniques are OPTIONAL.), Section 4.1.6 | MAY | MAY | MAY |
RR | Revoking a certificate, Section 4.2 | SHOULD | SHOULD | SHOULD |
CACerts | Get CA certificates, Section 4.3.1 | MAY | MAY | MAY |
RootUpd | Get root CA certificate update, Section 4.3.2 | MAY | MAY | MAY |
ReqTempl | Get certificate request template, Section 4.3.3 | MAY | MAY | MAY |
CRLUpd | CRL update retrieval, Section 4.3.4 | MAY | MAY | MAY |
Polling | Handling delayed delivery, Section 4.4 | MAY | MAY | MAY |
CertResp | Responding to a certificate request (IR, CR, KUR, and P10CR if supported), Section 5.1.1 | N/A | MAY | MUST |
InitPoll | Initiating delayed delivery, Section 5.1.2 | N/A | MAY | MAY |
CertConf | Responding to a confirmation message, Section 5.1.3 | MUST | MAY | MUST |
RevResp | Responding to a revocation request, Section 5.1.4 | N/A | MAY | SHOULD |
GenResp | Responding to a support message (CACerts, RootUpd, ReqTempl, CRLUpd if supported), Section 5.1.5 | N/A | MAY | MAY |
FwdKeep | Forwarding messages - not changing protection, Section 5.2.1 | N/A | MUST | N/A |
FwdAddS | Adding protection to a request message, Section 5.2.2.1 | N/A | MUST | MUST |
FwdAddB | Batching messages, Section 5.2.2.2 | N/A | MAY | MAY |
FwdRepKP | Forwarding messages - replacing protection, not changing any included proof-of-possession, Section 5.2.3.1 | N/A | MAY | N/A |
FwdRepBP | Forwarding messages - replacing protection, breaking proof-of-possession, Section 5.2.3.2 | N/A | MAY | MAY |
CertOnB | Acting on behalf of other PKI entities - requesting certificates, Section 5.3.1 | N/A | MAY | N/A |
RevROnB | Acting on behalf of other PKI entities - revoking a certificate, Section 5.3.2 | N/A | SHOULD | SHOULD |
CMP does not have specific needs regarding message transfer, except that for each request message sent, eventually exactly 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 transfer is RECOMMENDED to use for 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.¶
ID | Message transfer type | EE | RA | CA |
---|---|---|---|---|
HTTP | HTTP transfer, Section 6.1 | SHOULD | SHOULD | SHOULD |
CoAP | CoAP transfer, Section 6.2 | MAY | MAY | MAY |
Piggyb | Piggybacking on other reliable transfer, Section 6.3 | MAY | MAY | MAY |
Offline | Offline transfer, Section 6.4 | MAY | MAY | MAY |
This document does not request changes to the IANA registry.¶
The security considerations as laid out in CMP [RFC4210] updated by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply.¶
For TLS using shared secret information-based authentication, both PSK and PAKE provide the same amount of protection against a real-time authentication attack which is directly the amount of entropy in the shared secret. The difference between a pre-shared key (PSK) and a password-authenticated key exchange (PAKE) protocol is in the level of long-term confidentiality of the TLS messages against brute-force decryption, where a PSK-based cipher suite only provides security according to the entropy of the shared secret, while a PAKE-based cipher suite provides full security independent of the entropy of the shared secret.¶
We thank the various reviewers of this document.¶
Suppose the server requires that the certTemplate contains¶
Then the infoValue with certTemplate and keySpec fields returned to the EE will be encoded as follows:¶
SEQUENCE { SEQUENCE { [3] { SEQUENCE {} } [5] { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) UTF8String "" } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) UTF8String "myDept" } } SET { SEQUENCE { OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) UTF8String "myGroup" } } } } [9] { SEQUENCE { OBJECT IDENTIFIER subjectAltName (2 5 29 17) OCTET STRING, encapsulates { SEQUENCE { [2] "www.myServer.com" [7] "" } } } SEQUENCE { OBJECT IDENTIFIER keyUsage (2 5 29 15) BOOLEAN TRUE OCTET STRING, encapsulates { BIT STRING 3 unused bits "10001"B } } SEQUENCE { OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE {} } } } } SEQUENCE { SEQUENCE { OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11) SEQUENCE { OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) } } SEQUENCE { OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) INTEGER 2048 } } }¶
Note: This appendix will be deleted in the final version of the document.¶
From version 09 -> 10:¶
From version 08 -> 09:¶
From version 07 -> 08:¶
From version 06 -> 07:¶
From version 05 -> 06:¶
From version 04 -> 05:¶
From version 03 -> 04:¶
From version 02 -> 03:¶
From version 01 -> 02:¶
From version 00 -> 01:¶
From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf-lamps-lightweight-cmp-profile-00:¶
From version 02 -> 03:¶
From version 01 -> 02:¶
From version 00 -> 01:¶
From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft-brockhaus-lamps-lightweight-cmp-profile-00:¶