RFC 9483
Lightweight Certificate Management Protocol (CMP) Profile
Part 1 of 20 🎀
- RFC number: 9483
- Title: Lightweight Certificate Management Protocol (CMP) Profile
- Authors: H. Brockhaus, D. von Oheimb, and S. Fries, all from Siemens
- Category: Standards Track (ISSN 2070-1721)
- Date: November 2023
- Obsoletes / Updates: The title block doesn't list anything being obsoleted or updated.
Abstract
okay so this doc is all about making PKI management simple, interoperable, and automatic 🤖💖 It's built for industrial and Internet of Things (IoT) scenarios. The trick is that it profiles the Certificate Management Protocol (CMP), the Certificate Request Message Format (CRMF), and transfer over HTTP or the Constrained Application Protocol (CoAP). It does this in a succinct but detailed, self-contained way 🦋 To keep secure certificate management as lightweight as possible for simple setups and constrained devices, only the most crucial operations and options are marked as mandatory. The fancier, more complex use cases get optional features on top ✨
Status of This Memo
This is an Internet Standards Track document 🌸
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚
Info about this doc's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9483 💅
Copyright Notice ©
Copyright (c) 2023 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, which you can find at https://trustee.ietf.org/license-info as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License 🎀
Table of Contents
1. Introduction
1.1. How to Read This Document
1.2. Conventions and Terminology
1.3. Motivation for a Lightweight Profile of CMP
1.4. Special Requirements of Industrial and IoT Scenarios
1.5. Existing CMP Profiles
1.6. Compatibility with Existing CMP Profiles
1.7. Use of CMP in SZTP and BRSKI Environments
1.8. Scope of This Document
1.9. Structure of This Document
2. Solution Architecture
3. Generic Aspects of PKI Messages and PKI Management Operations
3.1. General Description of the CMP Message Header
3.2. General Description of the CMP Message Protection
3.3. General Description of CMP Message ExtraCerts
3.4. Generic PKI Management Operation Prerequisites
3.5. Generic Validation of a PKI Message
3.6. Error Handling
3.6.1. Reporting Error Conditions Upstream
3.6.2. Reporting Error Conditions Downstream
3.6.3. Handling Error Conditions on Nested Messages Used for
Batching
3.6.4. PKIStatusInfo and Error Messages
4. PKI Management Operations
4.1. Enrolling End Entities
4.1.1. Enrolling an End Entity to a New PKI
4.1.2. Enrolling an End Entity to a Known PKI
4.1.3. Updating a Valid Certificate
4.1.4. Enrolling an End Entity Using a PKCS #10 Request
4.1.5. Using MAC-Based Protection for Enrollment
4.1.6. Adding Central Key Pair Generation to Enrollment
4.1.6.1. Using the Key Transport Key Management Technique
4.1.6.2. Using the Key Agreement Key Management Technique
4.1.6.3. Using the Password-Based Key Management Technique
4.2. Revoking a Certificate
4.3. Support Messages
4.3.1. Get CA Certificates
4.3.2. Get Root CA Certificate Update
4.3.3. Get Certificate Request Template
4.3.4. CRL Update Retrieval
4.4. Handling Delayed Delivery
5. PKI Management Entity Operations
5.1. Responding to Requests
5.1.1. Responding to a Certificate Request
5.1.2. Responding to a Confirmation Message
5.1.3. Responding to a Revocation Request
5.1.4. Responding to a Support Message
5.1.5. Initiating Delayed Delivery
5.2. Forwarding Messages
5.2.1. Not Changing Protection
5.2.2. Adding Protection and Batching of Messages
5.2.2.1. Adding Protection to a Request Message
5.2.2.2. Batching Messages
5.2.3. Replacing Protection
5.2.3.1. Not Changing Proof-of-Possession
5.2.3.2. Using raVerified
5.3. Acting on Behalf of Other PKI Entities
5.3.1. Requesting a Certificate
5.3.2. Revoking a Certificate
6. CMP Message Transfer Mechanisms
6.1. HTTP Transfer
6.2. CoAP Transfer
6.3. Piggybacking on Other Reliable Transfer
6.4. Offline Transfer
6.4.1. File-Based Transfer
6.4.2. Other Asynchronous Transfer Protocols
7. Conformance Requirements
7.1. PKI Management Operations
7.2. Message Transfer
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Example CertReqTemplate
Acknowledgements
Authors' Addresses1. Introduction ✨
This doc is all about PKI management operations for machine-to-machine and IoT use cases 🦾 The big goal is maximum automation and interoperability between every PKI entity involved. That runs from end entities (EEs), through any number of intermediate PKI management entities such as registration authorities (RAs), all the way to the Certificate Management Protocol (CMP) [RFC4210] endpoints of certification authority (CA) systems 🌈 This profile uses the concepts and syntax from CMP [RFC4210] [RFC9480] [RFC9481], Certificate Request Message Format (CRMF) [RFC4211] [RFC9045], Cryptographic Message Syntax (CMS) [RFC5652] [RFC8933], HTTP transfer for CMP [RFC6712], and CoAP transfer for CMP [RFC9482].
Here's the tea 🍵 CMP, CRMF, and CMS are super feature-rich, but most real-world scenarios only touch a small slice of that functionality. The standards also aren't always precise enough about how to interpret and implement things. So this doc tailors the available options and explains how to use them in enough detail that building interoperable, automated certificate management feels straightforward and lightweight 💜
While this document was being developed, drafts meant to obsolete RFC 4210 [PKIX-CMP] and RFC 6712 [HTTP-CMP] were posted. They include the full set of changes described in CMP Updates [RFC9480] 🎀
1.1. How to Read This Document
Real talk, this document got longer than the authors wanted 🙈 But apart from Section 3, which has the general requirements, you don't have to read the whole thing front to back. The guidance in Sections 1.9 and 7 is your map 🗺️ It tells you which parts of Sections 4 to 6 matter for your certificate management solution, depending on the PKI management operations, their variants, and the types of message transfer you need.
Since conformity to this document only requires implementing the functionality declared mandatory in Section 7, the profile still counts as lightweight. Especially for end entities, the mandatory-to-implement set of features is pretty small, so it's giving easy mode 💅✨
1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here 🔥 Anything in lowercase is just regular English, no cap 🧢
Heads up on "PROHIBITED" 🚫 It means the respective ASN.1 field SHALL NOT be present or used.
Technical terminology follows [RFC4210], [RFC4211], [RFC5280], and IEEE 802.1AR [IEEE.802.1AR_2018] 📖 Here's the vocab you'll need:
- CA: Certification authority, which issues certificates. 👑
- RA: Registration authority, an optional PKI component that a CA delegates certificate management functions to. Think end entity authentication and authorization checks for incoming requests. An RA can also convert between different certificate management protocols and other protocols that handle some certificate management operations 🧚
- LRA: Local registration authority, a specific form of RA that sits close to the end entities 📍
- Note: For ease of reading, this document also uses the term "RA" for LRAs in every case where the difference doesn't matter.
- KGA: Key generation authority, an optional system component, usually colocated with an RA or CA, that offers key generation services to end entities 🔑
- EE: End entity, typically a device or service that holds a public-private key pair and manages a public key certificate for it. An identifier for the EE is given as the subject of its certificate 🦋
The following terminology is reused from [RFC4210]:
- PKI management operation: All CMP messages belonging to a single transaction. The transaction is identified by the
transactionIDfield of the message headers 🌸 - PKI management entity: A non-EE PKI entity, i.e., an RA or a CA. 🏛️
- PKI entity: An EE or PKI management entity. 🫶
CMP messages are referred to by the names of the PKIBody choices defined in Section 5.1.2 of [RFC4210], and they're described further in Section 4 of this document 💌
The following terms are introduced in this document:
- CMP protection key: The private key used to sign a CMP message. 🔐
- CMP protection certificate: The certificate related to the CMP protection key. If the
keyUsageextension is present, it MUST includedigitalSignature. 💖
💜 to be continued in part 2 💜
1.3. Motivation for a Lightweight Profile of CMP ✨
okay so CMP was standardized way back in 1999 and it's already baked into a bunch of PKI products 💅. Then in 2005 we got a totally reworked, glow-up version 2 of CMP [RFC4210] and CRMF [RFC4211], and in 2012 there was a spec for moving CMP messages over HTTP [RFC6712]. iconic history 🦋
ngl CMP is a really capable protocol and it deserves more love 💖 CMP [RFC4210] and CMP Updates [RFC9480] come with a HUGE set of features and options. On one hand that makes it fit a super wide range of scenarios 🌈 On the other hand, actually implementing every single option is not realistic, because it would take way too much effort 💀
so to keep things lean, this spec kept the set of mandatory PKI management operations and variants pretty small 🎀 That means less dev work and fewer resources burned, which matters a LOT for memory-constrained devices 🧚 The vibe here: when there was a choice between putting the complexity on the EE or in the PKI management entity, this profile put it in the PKI management entity, since those usually have more computing power to spare 💜 Then there are additional recommended PKI management operations and variants for more complex scenarios that are still super useful for environments with specific demands or boundary conditions ⭐ And the optional PKI management operations are for the less common scenarios and requirements 🫶
also, honestly, a lot of the Certificate Management Protocol is kind of vague or not specified in full detail 😭 The profiles in Appendices D and E of [RFC4210] do define some more detailed PKI management operations, but the specific needs of highly automated machine-to-machine scenarios aren't covered well enough yet 🙈
profiling is basically how you cut down feature richness and complexity to just what a specific use case needs 🍓 3GPP and UNISIG already profile CMP to deal with exactly these challenges 👑 To profile something means you take advantage of what the protocol is great at, explicitly narrow down the options to the ones your purpose needs, and clear up every ambiguity you spot ✨ That way the general parts of the protocol get used, and only the special requirements of the target scenarios need the distinct features the protocol offers 🦋
defining a brand new profile for a new environment takes HIGH effort 😩 You have to really understand the range of available options, make sure the selected ones are consistent with each other, and make sure they actually cover the intended application scenario. Since most industrial PKI management use cases have a lot in common, it's worth sharing that effort, and that's exactly what this document is for 🤝 Other standardization bodies can reference this document and tailor the PKI management operations further to their own needs, so they don't have to start every profile from scratch 💅
1.4. Special Requirements of Industrial and IoT Scenarios 🏭
the profiles in Appendices D and E of [RFC4210] were built mainly for managing certificates of human end entities 🙋♀️ But with distributed systems and client-server architectures evolving, certificates for machines and the applications running on them have become super common 🤖 That trend has gotten even stronger in emerging industrial and IoT scenarios 📈 The good news is CMP is flexible enough to support them well 🫶
today's IT security architectures for industrial solutions usually use certificates for endpoint authentication within protocols like IPsec, TLS, or Secure Shell (SSH) 🔐 So the security of these architectures really depends on the security and availability of the certificate management operations they implement. no pressure lol 💀
with rising security and availability needs in operational technology, especially for critical infrastructures and systems with a huge number of certificates, a state-of-the-art certificate management system has to be constantly available AND cost-efficient 😤 That calls for high automation and reliability ✨ That's why the "Framework for Improving Critical Infrastructure Cybersecurity" [NIST.CSWP.04162018] talks about proper processes for issuance, management, verification, revocation, and audit of authorized devices, users, and processes involving identity and credential management 🧾 According to commonly accepted best practices, such PKI management operations are also required in [IEC.62443-3-3] for security level 2 and higher 🔥
other challenges in many industrial systems are network segmentation and asynchronous communication 🧩 Also, PKI management entities like certification authorities (CAs) usually aren't deployed on-site. They live in a highly protected data center environment, e.g., operated according to ETSI Policy and security requirements for Trust Service Providers issuing certificates [ETSI-EN.319411-1] 🏰 Certificate management has to be able to cope with network architectures like that 🌸 And here's the payoff: CMP offers the flexibility and functionality needed, namely authenticated self-contained messages, efficient polling, and support for asynchronous message transfer, all while keeping end-to-end authentication 🎀 iykyk, it's a whole vibe 💜
1.5. Existing CMP Profiles 📚
as already mentioned, [RFC4210] has profiles with mandatory and optional PKI management operations in Appendices D and E of [RFC4210] 📖 Those profiles focus on managing human user certificates, and they only partly address the specific needs of certificate management automation for unattended devices or machine-to-machine application scenarios 🤖
both Appendices D and E of [RFC4210] focus on PKI management operations between an EE and an RA or CA 👀 They don't cover further profiling of RA-to-CA communication, which is typically needed for full backend automation ⚙️ All requirements regarding algorithm support for Appendices D and E of [RFC4210] have been updated by Section 7.1 of CMP Algorithms [RFC9481] 🔄
3GPP uses 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, that document has specified a dedicated CMP profile for initial certificate enrollment and certificate update operations between EEs and RAs/CAs 🎉
then in 2015, UNISIG included a CMP profile for enrollment of TLS certificates in Subset-137, which specifies the ETRAM/ETCS online key management for train control systems 🚆 [UNISIG.Subset-137]
so both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI management operations for unattended devices and services 🫶🦋
1.6. Compatibility with Existing CMP Profiles 🔍
this profile is compatible with Appendices D and E of [RFC4210], with a few exceptions 🧐
- signature-based protection is the default protection; an initial PKI management operation may also use protection based on the message authentication code (MAC) 🔏
- certification of a second key pair within the same PKI management operation is not supported 🙅♀️
- proof-of-possession (POP) with the self-signature of the certReq containing the certTemplate (according to [RFC4211], Section 4.1, clause 3) is the recommended default POP method. Deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technically not capable to generate digital signatures 🔑
- confirmation of newly enrolled certificates may be omitted 🤷♀️
- all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model, a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE 🪶
this profile is also compatible with the CMP profile for 3G, LTE, and 5G network domain security and authentication framework [ETSI-3GPP.33.310], except that: 🤝
- protection of initial PKI management operations may be MAC-based 🔐
- the subject field is mandatory in certificate templates 📝
- confirmation of newly enrolled certificates may be omitted 🤷♀️
and the profile is compatible with the CMP profile for online key management in rail networks as specified in [UNISIG.Subset-137], except that: 🚄
- A certificate enrollment request message consists of only one certificate request (
CertReqMsg). 📨 - [RFC4210] requires that the
messageTimeis Greenwich Mean Time coded asgeneralizedTime. 🕰️
Note: As Table 5 of [UNISIG.Subset-137] explicitly states that themessageTimeis required to be"UTC time", it is not clear if this means a coding asUTCTimeorgeneralizedTime, and if time zones other than Greenwich Mean Time shall be allowed. Both time formats are described in Section 4.1.2.5 of [RFC5280]. 🤔
- The same type of protection is required to be used for all messages of one PKI management operation. This means, in case the request message protection is MAC-based, the response,
certConf, andpkiConfmessages must also have MAC-based protection. 🔁 - Use of
caPubsis not required but is typically allowed in combination with MAC-based protected PKI management operations. On the other hand, Table 12 of [UNISIG.Subset-137] requires usingcaPubs. 📜
Note: It remains unclear from UNISIG Subset-137 which certificate(s) for the caPubs field should be used. For security reasons, it cannot be used for delivering the root CA certificate needed to validate the signature-based protection of the given response message (as stated indirectly also in Section 6.3.1.5.2 b of [UNISIG.Subset-137]). 🛡️
- This profile requires that the
certConfmessage have oneCertStatuselement where thestatusInfofield is recommended. 📬
Note: In contrast, Table 18 of [UNISIG.Subset-137] requires that thecertConfmessage has oneCertStatuselement where thestatusInfofield must be absent. This precludes sending a negativecertConfmessage in case the EE rejects the newly enrolled certificate. This results in violating the general rule that a certificate request transaction must include acertConfmessage (moreover, since usingimplicitConfirmis not allowed there either). 🚫
1.7. Use of CMP in SZTP and BRSKI Environments 🧚
okay so in Secure Zero Touch Provisioning (SZTP) [RFC8572] and other environments that run on Network Configuration Protocol (NETCONF) / YANG modules, [SZTP-CSR] gives you a YANG module with several types of certificate requests. They let you get a public key certificate for a key pair you generated locally 🔑 These messages look like ietf-ztp-types:cmp-csr from the module ietf-ztp-csr, and they offer both proof-of-possession AND proof-of-identity 😭🫶 So if your PKI management entities use the ietf-ztp-csr module and also want to comply with this profile, the ir, cr, kur, or p10cr message MUST be formatted by the EE as described in Section 4.1, and it MAY be forwarded, as specified in Section 5.2 💅
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI" [BRSKI-AE] is the spec that generalizes which enrollment protocols you can use, so you're not stuck with Enrollment over Secure Transport (EST) [RFC7030] only 🦋 For CMP, though, it needs you to follow this profile. No cap, it's non-negotiable 💀
1.8. Scope of This Document 🌸
okay so this profile is trying to do two things at once 👀 On one hand, it cuts back on CMP's flexibility so it fits the generic needs of automated certificate management for machine end entities. On the other hand, it still offers a bunch of PKI management operations and options that matter for industrial use cases. So it's still a framework, and people working on a specific use case or scenario, like 3GPP/ETSI or UNISIG, can profile it further. There's room to tailor it even more, and that lets you go stricter to meet the real needs of different application areas 💖
To keep things unambiguous and avoid needless variety, this document gives exhaustive requirements for generating PKI management messages on the sender side. Receiver-side checks and how to handle error cases? Only minimal requirements there 🙈
Especially on the EE side, this profile is aiming for a lightweight implementation. The number of PKI management operations implementations has to support is trimmed down to a reasonable minimum, so typical certificate management use cases in industrial machine-to-machine environments stay covered ⚙️ EEs only have limited resources, while the PKI management entities are allowed to have higher requirements. That's the deal 🤝
For the sake of interoperability and robustness, implementations should, so long as security is not affected, adhere to Postel's law: "Be conservative in what you do, be liberal in what you accept from others" (often reworded as: "Be conservative in what you send, be liberal in what you receive") 🍓
Fields used in ASN.1 syntax in Sections 3, 4, or 5 are specified in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. When these sections don't explicitly discuss a field, the field SHOULD NOT be used by the sending entity. The receiving entity MUST NOT require the absence of such a field, and if the field is present, it MUST handle it gracefully 🫶✨
1.9. Structure of This Document 🗺️
Section 2 introduces the general PKI architecture and the approach to certificate management assumed in this document 🏛️
Section 3 profiles the generic aspects of the PKI management operations that are spelled out in detail in Sections 4 and 5. This keeps the description from repeating itself and makes it easier to implement. It covers the general structure and protection of messages, plus generic prerequisites, validation, and error handling 🧚
Section 4 profiles the exchange of CMP messages between an EE and the PKI management entity. There are various flavors of certificate enrollment requests, optionally with polling, central key generation, revocation, and general support PKI management operations 💜
Section 5 profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This can include delayed delivery of messages, which involves polling for responses, and nesting of messages 🌈
Section 6 outlines several mechanisms for CMP message transfer: HTTP-based transfer [RFC6712] optionally using TLS, CoAP-based transfer [RFC9482] optionally using DTLS, and offline file-based transport 📦
Section 7 defines which parts of the profile are mandatory, recommended, optional, or not relevant to implement for each type of entity 📋
2. Solution Architecture 🏗️
okay so to make secure automatic certificate enrollment happen, the device hosting an EE usually comes with a manufacturer-issued device certificate 🔐 That certificate is typically installed during production and is meant to identify the device for its entire lifetime 🎀 It can then protect the initial enrollment of operational certificates after the EE is installed in its operational environment. Operational certificates are different: the owner or operator of the device issues them 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 an Initial Device Identifier (IDevID) certificate, and an operational certificate is called a Locally Significant Device Identifier (LDevID) certificate ✨
Note: The owner or operator using the manufacturer-issued device certificate for authenticating the device during initial enrollment of operational certificates MUST trust the respective trust anchor provided by the manufacturer. 🙈
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, so they're 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 a PKI management entity. That entity may be a CA, but more typically it's an RA, which checks the request and either responds itself or forwards it upstream to the next PKI management entity 🦋 If an RA changes the CMP request message header or body, or wants to show that it verified or authorized the request successfully, it can apply a protection of its own 🛡️ The communication between an LRA and an RA can be synchronous or asynchronous. Asynchronous communication typically leads to delayed message delivery, as described in Section 4.4 ⏳
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous (a)synchronous
+----connection----+------connection------+----connection----+
operators service partner
+---------on site---------+---back-end services--+---trust center--+
<--- downstream <--- | ---> upstream --->
Figure 1: Certificate Management Architecture ExampleIn operational environments, the certificate management architecture can have multiple LRAs bundling requests from multiple EEs at dedicated locations, plus 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. That lets it protect the CMP messages it processes using its own credentials 🔒 The figure above shows an architectural example with one LRA, one RA, and one CA. It's also possible to have no RA or LRA, or no CA with a CMP interface 🤷♀️ Depending on the network infrastructure, message transfer between PKI management entities may be based on synchronous online connections, asynchronous connections, or even offline (e.g., file-based) transfer 📁
Note: In contrast to the pull model used in this document, other specifications could use the messages specified in this document to implement the push model. In this case, the EE is pushed (triggered) by the PKI management entity to provide the CMP request, so the EE acts as the receiver and doesn't initiate the interaction with the PKI 🧚 For example, when the device itself only acts (as a server, as described in BRSKI with Pledge in Responder Mode [BRSKI-PRM]), support for certificate enrollment in a push model is needed. While BRSKI-PRM currently uses its own format for the exchanges, CMP in general and the messages specified in this profile offer all required capabilities. Still, the message flow and state machine described in Section 4 must be adapted to implement a push model 💜
Note: Third-party CAs that don't conform to this document may implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management. In such cases, an RA needs to adapt the exchanged CMP messages to the flavor of certificate management interaction required by such a nonconformant CA 🌸
3. Generic Aspects of PKI Messages and PKI Management Operations ✨
okay bestie, this section is the foundation 🧱💖 It collects all the general rules that apply to the PKI management operations in Sections 4 and 5, so we don't have to repeat ourselves over and over. Less redundancy, easier to implement, iconic 💅
Every CMP message, no matter what it's doing, has the same basic shape (Section 5.1 of [RFC4210] defines this). Think of it like a little envelope with a few compartments 📦
+--------------------------------------------+
| PKIMessage |
| +----------------------------------------+ |
| | header | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | body | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | protection (OPTIONAL) | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | extraCerts (OPTIONAL) | |
| +----------------------------------------+ |
+--------------------------------------------+
Figure 2: CMP Message StructureThe header, protection, and extraCerts fields each get their own general rules in the three subsections below. If a specific PKI management operation needs something different in any of those fields, the differences are spelled out in the matching subsections of Sections 4 and 5, so keep an eye out there too 👀
The body is where the operation-specific stuff lives (the actual tea ☕), and that's described in Sections 4 and 5.
Heads up: some fields are marked as OPTIONAL or RECOMMENDED. The requirements written for those fields only kick in if the field is actually there. No field, no rule, simple as that 🫶
The generic prerequisites that PKI entities need before they can do any PKI management operations are in Section 3.4. The generic validation steps for when a PKI entity receives a CMP message are in Section 3.5. And the generic stuff about handling and reporting errors is in Section 3.6. It's giving organized 🗂️✨
3.1. General Description of the CMP Message Header
This part is all about the generic header fields that every CMP message carries 🎀 Anything that's specific to one PKI management operation gets covered in Sections 4 and 5.
header
pvno REQUIRED
-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- is supported and expected to be used in the current
-- PKI management operation
-- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation, see [RFC9480]
sender REQUIRED
-- Contains a name representing the originator, which also
-- protects the message
-- For signature-based protection, MUST be the subject field of
-- the CMP protection certificate
-- For MAC-based protection, MUST contain a name the PKI
-- management entity can use to identify the shared secret
-- information. This name MUST be placed in the commonName
-- field of the directoryName choice.
-- In a multihop scenario, the receiving entity cannot rely
-- on the correctness of the sender field.
recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used
-- In the first message of a PKI management operation, SHOULD be
-- the subject DN of the CA the PKI management operation is
-- requested from
-- In all other messages, SHOULD contain the value of the sender
-- field of the previous message in the same PKI management
-- operation
-- The recipient field shall be handled gracefully by the
-- receiving entity, because in a multihop scenario, its
-- correctness cannot be guaranteed.
messageTime OPTIONAL
-- MUST be present if the confirmWaitTime field is present
-- MUST be the time at which the message was produced, if present
-- MAY be set by a PKI management entity to provide the current
-- time
-- MAY be used by the end entity for time synchronization if the
-- response was received within a short time frame
protectionAlg REQUIRED
-- MUST be an algorithm identifier indicating the algorithm
-- used for calculating the protection bits
-- If it is a signature algorithm, its type MUST be
-- MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
-- MUST be consistent with the subjectPublicKeyInfo field of
-- the CMP protection certificate
-- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
-- specified in [RFC9481], Section 6.1
senderKID RECOMMENDED
-- For signature-based protection, MUST be used and contain the
-- value of the SubjectKeyIdentifier if present in the CMP
-- protection certificate
-- For MAC-based protection, MUST be used and contain the same
-- name as in the commonName field of the sender field
transactionID REQUIRED
-- In the first message of a PKI management operation, MUST be
-- 128 bits of random data to minimize the probability of
-- having the transactionID already in use at the server
-- In all other messages, MUST be the value from the previous
-- message in the same PKI management operation
senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED
-- If this is the first message of a transaction, MUST be absent
-- If this is a delayed response message, MUST be present and
-- contain the value of the senderNonce of the respective
-- request message in the same transaction
-- In all other messages, MUST be present and contain the value
-- of the senderNonce of the previous message in the same
-- transaction
generalInfo OPTIONAL
implicitConfirm OPTIONAL
-- RECOMMENDED in ir/cr/kur/p10cr messages,
-- OPTIONAL in ip/cp/kup response messages, and
-- PROHIBITED in other types of messages
-- Added to request messages to request omission of the certConf
-- message
-- Added to response messages to grant omission of the certConf
-- message
-- See [RFC4210], Section 5.1.1.1.
ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue MUST be NULL
confirmWaitTime OPTIONAL
-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
-- not included
-- PROHIBITED if implicitConfirm is included
-- See [RFC4210], Section 5.1.1.2.
ConfirmWaitTimeValue REQUIRED
-- ConfirmWaitTimeValue MUST be a GeneralizedTime value
-- specifying the point in time up to which the PKI management
-- entity will wait for the certConf message. The accepted
-- length of the waiting period will vary by use case.
certProfile OPTIONAL
-- MAY be present in ir/cr/kur/p10cr and in genm messages of type
-- id-it-certReqTemplate
-- MUST be omitted in all other messages
-- See [RFC9480].
CertProfileValue REQUIRED
-- MUST contain a sequence of one UTF8String element
-- MUST contain the name of a certificate profileOkay, so the header has a bunch of fields with their own rules, and the big takeaway is that the version number (pvno) depends on what's going on 🔢 It's 3 when EnvelopedData is supported and expected in the current operation, and also 3 for certConf messages that use the hashAlg field. Everything else is 2. For how the two sides agree on a version, check [RFC9480] 🤝
For sender and recipient, the names are a whole vibe 🎭 Signature-based protection means sender has to match the subject of the CMP protection certificate. MAC-based protection means the name goes in the commonName of the directoryName choice. And since recipient can't be fully trusted in a multihop setup, the receiver has to handle it gracefully 🫶
For transactionID, the first message gets 128 bits of random data so it's very unlikely to clash with one already in use on the server. Every message after that just reuses the value from the previous message. Consistency is everything, periodt 💅
senderNonce is 128 fresh, cryptographically secure random bits, and recipNonce is where you echo back the right nonce. First message? It has to be absent. Delayed response? It echoes the senderNonce of the original request. Everything else echoes the senderNonce of the previous message 🌸
implicitConfirm and confirmWaitTime are kind of the "skip the extra step" option ⏩ implicitConfirm is RECOMMENDED in request messages and OPTIONAL in response messages, and it's PROHIBITED in everything else. confirmWaitTime is RECOMMENDED for ip/cp/kup messages if implicitConfirm isn't included, and it's PROHIBITED if implicitConfirm is. You can't have both, bestie 🙅♀️
certProfile is only allowed in ir/cr/kur/p10cr messages and in genm messages of type id-it-certReqTemplate. Everywhere else, it has to be left out 🧚
3.2. General Description of the CMP Message Protection
This section is about the generic protection field 🔐 For signature-based protection, which is the default for every CMP message in this profile, you use the CMP protection key and the CMP protection certificate. For MAC-based protection, you use shared secret information, which is covered in Section 4.1.5.
protection
-- If present, the same kind of protection MUST be used for all
-- messages of that PKI management operation.
-- MUST be present, except if protection is not possible for
-- error messages as described in Section 3.6.4
-- For signature-based protection, MUST contain the signature
-- calculated using the CMP protection key of the entity
-- protecting the message
-- For MAC-based protection, MUST contain a MAC calculated using
-- the shared secret information
-- The protection algorithm used MUST be given in the
-- protectionAlg field.The protection is all about origin authentication and integrity for the header and body, where it's available 🛡️ The extraCerts field is NOT covered by this protection, so don't count on it being locked down 👀
Note: the extended key usages from Section 2.2 of CMP Updates [RFC9480] can be used to authorize a sending PKI management entity. Main character authorization energy 👑
3.3. General Description of CMP Message ExtraCerts
This section covers the generic extraCerts field 🧳 If a specific PKI management operation has its own requirements for extraCerts, those are listed in that operation's section.
extraCerts
-- MUST be present for signature-based protection and contain the
-- CMP protection certificate together with its chain for the
-- first request and response message of a PKI management
-- operation. MAY be omitted in certConf, PKIConf, pollReq,
-- and pollRep messages. The first certificate in this field
-- MUST be the CMP protection certificate followed by its
-- chain, where each element should directly certify the one
-- immediately preceding it.
-- MUST be present in ip, cp, and kup messages and contain the
-- chain of a newly issued certificate.
-- Self-signed certificates should be omitted from extraCerts and
-- MUST NOT be trusted based on their inclusion in any caseSo for signature-based protection, the first request and response in an operation must carry the CMP protection certificate plus its chain 🔗 The very first certificate in the list has to be the protection cert, and each one should directly certify the one before it. ip, cp, and kup messages must also include the chain of the newly issued certificate. And self-signed certs? Leave them out if you can, and never trust one just because it showed up in the message 🙅♀️
Note: a self-signed cert might still get included, and there are a few good reasons for it. It could be the CMP protection cert, or a successor root CA self-signed cert flagged by the HashOfRootKey extension on the current root CA cert (see [RFC8649]). Or it could just be about storage limits 📦 A receiver might not have the full trust anchor info, only a unique identifier for it, so it needs the full self-signed cert to keep going (see Section 9).
For maximum interoperability, every implementation SHOULD be ready to handle extra certificates and any ordering of them 🌈 Being flexible is literally the secret to getting along with everyone 🫶
3.4. Generic PKI Management Operation Prerequisites ✨
okay so this part is basically the checklist of what every PKI entity needs in its bag before it even tries a PKI management operation 🎀 let's go bestie 💅
Identification of PKI entities:
- For signature-based protection, each EE knows who it is from its CMP protection certificate 🪪. For MAC-based protection, it MAY know its identity so it can fill in the
senderfield 🌸- Each EE MAY know who its requests are meant for, so it can fill in the
recipientfield, like the name of the CA it's addressing 🦋
- Each EE MAY know who its requests are meant for, so it can fill in the
Note: This name can come from an enrollment voucher (described in [RFC8366]), from the issuer field in a CertReqTemplate response message content, or from other configuration means 🧚
Routing of CMP messages:
- Each PKI entity sending messages upstream MUST know the address it needs for passing messages to the next PKI management entity, if online transfer is being used 🚀
Note: That address might depend on the recipient, the certificate profile, and the transfer mechanism being used 🗺️
Authentication of PKI entities:
- Each PKI entity MUST have credentials so it can authenticate itself 🔐. For signature-based protection, it MUST have a private key and the matching certificate, along with its chain 🫶
- Each PKI entity MUST be able to establish trust in the PKI whose responses it receives 💜. When signature-based protection is used, it MUST have the trust anchor(s) and any certificate status information it needs to do path validation on the CMP protection certificates used for signature-based protection ✨
Note: A trust anchor is usually the root certificate of the PKI that the requesting EE is addressing 👑. It can be set up through configuration or out-of-band. For an EE, it can be established using an enrollment voucher [RFC8366], or in-band in CMP through the caPubs field in a certificate response message 🌈
Authorization of PKI management operations:
- Each EE or RA MUST have enough information to authorize the PKI management entity to perform the upstream PKI management operation 🙈
Note: This can be done, for example, by using the cmcRA extended key usage in server certificates, by local configuration (like specific name patterns in the subject Distinguished Name (DN) or Subject Alternative Name (SAN) portions that can identify an RA), and/or by having a dedicated root CA that can only be used to authenticate PKI management entities 💅
- Each PKI management entity MUST have enough information to authorize the downstream PKI entity that's requesting the PKI management operation 👑
Note: For authorizing an RA, the same examples as above apply. Authorizing EEs can be super specific to the application domain, depending on local PKI policy 🎀
3.5. Generic Validation of a PKI Message 🔍
this section is the generic validation glow-up every PKI entity runs when it gets a PKI request or response message, before it does anything else with it or forwards it 💖. If a PKI management entity decides to end 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 listed below in parentheses MAY be used in the failInfo field of the PKIStatusInfo, as described in Section 3.6.4. Also see Appendix F of [RFC4210] 🧾
All PKI message header fields that aren't mentioned in this section, like the recipient and generalInfo fields, SHOULD be handled gracefully when they're received 🫶
Here's the basic set of input validation steps. Without these checks, the protocol becomes dysfunctional 💀
- The formal ASN.1 syntax of the whole message MUST be compliant with the definitions in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. (failInfo: badDataFormat)
- The
pvnoMUST be cmp2000(2) or cmp2021(3). (failInfo bit: unsupportedVersion) - The
transactionIDMUST be present. (failInfo bit: badDataFormat) - The PKI message body type MUST be one of the message types supported by the receiving PKI entity, and it MUST be allowed in the current state of the PKI management operation identified by the given
transactionID. (failInfo bit: badRequest)
Next up is the set of input validation steps needed to keep the protocol secure 🔐🔥:
- The
senderNonceMUST be present and MUST contain at least 128 bits of data. (failInfo bit: badSenderNonce) - Unless the PKI message is the first message of a PKI management operation:
- the
recipNonceMUST be present and MUST equal thesenderNonceof the previous message, or equal thesenderNonceof the most recent request message whose response was delayed, in case of delayed delivery as specified in Section 4.4. (failInfo bit: badRecipientNonce)
- the
- Messages without protection MUST be rejected, except for error messages as described in Section 3.6.4 🙅♀️
- The message protection MUST be validated when it's present, and messages with an invalid protection MUST be rejected 🚫
- The protection MUST be signature-based, except if MAC-based protection is used as described in Sections 4.1.5 and 4.1.6.3. (failInfo bit: wrongIntegrity)
- If present, the
senderKIDMUST identify the key material needed for verifying the message protection. (failInfo bit: badMessageCheck) - If signature-based protection is used, the CMP protection certificate MUST be successfully validated, including path validation using a trust anchor, and MUST be authorized according to local policies. If the keyUsage extension is present in the CMP protection certificate, the digitalSignature bit MUST be set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)
- The sender of a request message MUST be authorized to request the operation according to PKI policies. (failInfo bit: notAuthorized)
Note: The certificate-checking requirements given in [RFC5280] MUST be followed for signature-based CMP message protection. Unless the message is a positive ip/cp/kup, where the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking SHOULD be performed on the CMP protection certificates. If the response message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is REQUIRED. For other cases, it MAY be acceptable to skip certificate status checking when the respective information isn't available 🧐
Depending on local policies, one or more of the input validation checks described below need to be implemented 🎀
- If signature-based protection is used, the
senderfield MUST match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck) - If the
messageTimeis present and:- the receiving system has a reliable system time, the
messageTimeMUST be close to the current time of the receiving system, where the threshold will vary by use case. (failInfo bit: badTime) - the receiving system does not have a reliable system time, the
messageTimeMAY be used for time synchronization ⏰
- the receiving system has a reliable system time, the
3.6. Error Handling 🚨
this section is all about how a PKI entity handles error conditions on the messages it receives 🫣. Every error condition should be logged properly so root-cause analysis of failure cases is possible 📝
3.6.1. Reporting Error Conditions Upstream
An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in the upstream direction either 🤐
If 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, then await the pkiConf response as described in Section 4.1.1 🙅♀️
For 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:
- invalid response message header, body type, protection, or extraCerts, according to the checks described in Section 3.5,
- any issue detected with response message contents,
- receipt of an error message from upstream,
- timeout occurred while waiting for a response, and
- rejection of a newly issued certificate while implicit confirmation has been granted.
Upstream PKI management entities won't receive any CMP message telling them the PKI management operation was terminated 👻. If they expect a further message from the EE, a connection interruption or timeout will happen instead. The value set for such timeouts will vary by use case. Then they MUST also regard the current PKI management operation as terminated with failure, and they MUST NOT try to send an error message downstream 💀
3.6.2. Reporting Error Conditions Downstream
If the PKI management entity detects an error condition, like rejecting the request due to a policy decision, in the body of an ir, cr, p10cr, kur, or rr message received from downstream, it MUST report the error in the specific response message, meaning an ip, cp, kup, or rp with "rejection" status, as described in Sections 4.1.1 and 4.2. This can also happen when polling 🎯
If the PKI management entity detects any other error condition on requests (including pollReq, certConf, genm, and nested messages) received from downstream, or on responses received from upstream (such as an 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 🌷
3.6.3. Handling Error Conditions on Nested Messages Used for Batching 📦
Batching messages using nested messages, as described in Section 5.2.2.2, needs 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, but to the nested message itself 🙃
If a PKI management entity receives an error message in response to a nested message, it has to propagate the error by responding with an error message to each of the request messages contained in the nested message 🫠
If a PKI management entity detects an error condition on the downstream nested message received in response to a nested message it sent before, and the body of the received nested message still parses, it MAY ignore this error condition and handle the included responses 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 originally sent 💅
3.6.4. PKIStatusInfo and Error Messages ✨
okay so whenever a PKI entity sends ANY kind of negative response (yes, error messages too 😭), it MUST spell out the error condition inside the PKIStatusInfo structure of that message. then it MUST treat the whole PKI management operation as terminated with failure. no cap, that's a hard stop 🛑
PKIStatusInfo is the structure that reports errors. it can show up in a bunch of message types, mainly ip, cp, kup, certConf, and error. it has three fields:
status: here the PKIStatus valuerejectionMUST be used when an error was detected. when a PKI management entity tells the EE about delayed delivery of a CMP response message with an error message (see Section 4.4), the statuswaitingMUST be used there 🕰️statusString: any human-readable valid value for logging or for showing in a user interface should be added 📝failInfo: the PKIFailureInfo bits MAY be used the way Appendix F of [RFC4210] explains. the bits about validation (see Section 3.5) are referenced there. the bits for Sections 5.1 and 6 are described right here:badCertId: akur,certConf, orrrmessage references an unknown certificate 🔍badPOP: anir/cr/kur/p10crcontains an invalid proof-of-possession 🙅♀️certRevoked: revocation is requested for a certificate that is already revoked 💀badCertTemplate: the contents of a certificate request are not accepted, e.g., a field is missing or has an unacceptable value, or the given public key is already in use in some other certificate (depending on policy) 🧩transactionIdInUse: this is sent by a PKI management entity when the received request contains a transactionID that is currently in use for another transaction. an EE receiving this error message should resend the request in a new transaction using a different transactionID 🔁notAuthorized: the sender of a request message is not authorized for requesting the operation 🚫systemUnavail: this is sent by a PKI management entity when a back-end system is not available 😴systemFailure: this is sent by a PKI management entity when a back-end system is currently not functioning correctly 🛠️
an EE receiving a systemUnavail or systemFailure failInfo should resend the request in a new transaction after some time. patience is a whole vibe 🧘♀️
Detailed 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 OPTIONAL
-- This field should contain any human-readable text for
-- debugging, for logging, or to display in a GUI
failInfo OPTIONAL
-- MAY be present and contain the relevant PKIFailureInfo bits
protection RECOMMENDED
-- As described in Section 3.2
extraCerts RECOMMENDED
-- As described in Section 3.3protecting the error message might not be technically feasible if it's not clear which credential the recipient will be able to use to validate that protection, e.g., when the request message was fundamentally broken 💔. in these exceptional cases, the protection of the error message MAY be omitted 🫶
4. PKI Management Operations 💅
this section is all about how an EE talks to the PKI management entity it directly chats with. depending on the network and PKI solution, that could be an RA or straight up a CA 🏢. how a PKI management entity handles a message is covered in Section 5, so stay tuned 👀
the PKI management operations in this section cover:
- requesting a certificate, with variations like initial enrollment, certificate updates, central key generation, and MAC-based protection 🎀
- revoking a certificate 🗑️
- support messages 🛟
- polling for delayed response messages 🔄
these operations mainly spell out the message body of the CMP messages, and they lean on the header, protection, and extraCerts specs from Section 3. the messages are named after the matching field names in PKIBody, like ir, ip, cr, cp, etc.; see Section 5.1.2 of [RFC4210] 📛
the diagram below shows the EE state machine for every PKI management operation in this section. it also covers negative responses, the error messages from Section 3.6.4, ip/cp/kup/error messages with status waiting, and the pollReq and pollRep messages from Section 4.4 🌈
when messages come in from upstream, the EE MUST perform the general validation checks described in Section 3.5. if an error occurs, check Section 3.6 for what happens next 🚦
End Entity State Machine:
start
|
| send ir/cr/kur/p10cr/rr/genm
v
waiting for response
v
+--------------------------+--------------------------+
| | |
| 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 |
| | v |
| +------------+--------+ |
| | | |
| received ip/cp/kup | | received |
| with status "accepted" | | rp/genp or |
| or "grantedWithMods" | | ip/cp/kup/error |
| | | with status |
+---------->+<-------------+ | "rejection" |
v | |
+-----------+-----+ | |
| | | |
| implicitConfirm | implicitConfirm | |
| granted | not granted | |
| | | |
| | send certConf | |
| v | |
| waiting for pkiConf*) | |
| | | |
| | received | |
| v pkiConf v |
+---------------->+------->+<-------+<----------------+
|
v
end*) in case of a delayed delivery of pkiConf responses, the same polling mechanism is kicked off 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 uses it to identify the parts of the operation 🆔
this section lines up with CMP [RFC4210], CMP Updates [RFC9480], and CMP Algorithms [RFC9481] 🫶
guidelines and an algorithm use profile for this document are available in CMP Algorithms [RFC9481] 📚
4.1. Enrolling End Entities ✨
Okay so bestie, let's talk about how an end entity (EE) asks a PKI for a certificate, because there are a bunch of ways to do it 💅. The way the EE proves who it is to the PKI can change, and so can the form of the request and how the key pair being certified gets made. The authentication options are:
- using a certificate from an external PKI, e.g., a manufacturer-issued device certificate, and the corresponding private key
- using a private key and certificate issued from the same PKI that is addressed for requesting a certificate
- using the certificate to be updated and the corresponding private key
- using shared secret information known to the EE and the PKI management entity
An EE requests a certificate indirectly or directly from a CA 🌸. When the PKI management entity handles the request as described in Section 5.1.1 and responds with a message containing the requested certificate, the EE MUST reply with a confirmation message unless implicitConfirm was granted. Then the PKI management entity MUST handle it as described in Section 5.1.2 and respond with a confirmation, which closes the PKI management operation 🎀.
This section lets the EE request certification of a key pair it generated locally or one generated centrally 🔑. The public key and the subject name identifying the EE MUST be present in the certTemplate of the certificate request message.
Note: If the EE doesn't know which subject name to request the certificate for, it can use the subject name from the CMP protection certificate in case of signature-based protection, or the identifier of the shared secret in case of MAC-based protection.
Typically, the EE gives a signature-based proof-of-possession of the private key tied to the public key in the certificate request, as defined by [RFC4211], Section 4.1, clause 3 🦋. For this to work, it's assumed the private key can technically be used for signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA, regardless of any intended restrictions of the key usage.
Note: Section 4 of [RFC4211] allows providing proof-of-possession using any method that a key can be used for. In conformance with Section 8.1.5.1.1.2 of [NIST.SP.800-57p1r5], the newly generated private key may be used for self-signature, if technically possible, even if the keyUsage extension requested in the certificate request prohibits generation of digital signatures.
The requesting EE binds the proof-of-possession to its identity through signature-based or MAC-based protection of the CMP request message containing that POP 🔐. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions.
The proof-of-possession comes from signing the certReq containing the certTemplate with the subject name and public key. To tie this proof-of-possession to the proof-of-identity of the requesting EE, the subject name in the certTemplate needs to identify the same entity as the subject name in the CMP protection certificate, or match the identifier used with MAC-based protection 💖.
Note: This binding may be lost if a PKI management entity reprotects this request message.
The EE MAY indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message, as described in Section 3.1 ✨.
If the EE receives a CA certificate in the caPubs field to install as a new trust anchor, it MUST properly authenticate the message and authorize the sender as a trusted source of the new trust anchor 👑. This authorization is typically indicated using shared secret information for protecting an Initialization Response (ip) message. Authorization can also be signature-based, using a certificate issued by another PKI that is explicitly authorized for this purpose. A certificate received in caPubs MUST NOT be accepted as a trust anchor if it is the root CA certificate of the certificate used for protecting the message 🙈.
4.1.1. Enrolling an End Entity to a New PKI 🧚
Okay this one is so cute 🥹. 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 (like a manufacturer-issued IDevID certificate [IEEE.802.1AR_2018]) to prove itself to the new PKI 🌈.
Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI" [BRSKI-AE] describes a generalization regarding enrollment protocols alternative to EST [RFC7030]. As a replacement for the EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapping LDevID certificates 🍓.
These are the specific prerequisites, on top of the ones in Section 3.4:
- The certificate of the EE MUST have been enrolled by an external PKI, e.g., a manufacturer-issued device certificate.
- The PKI management entity MUST have the trust anchor of the external PKI.
- When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
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 pkiConfFor this PKI management operation, the EE MUST include a sequence of one CertReqMsg in the ir. If more certificates are required, further requests MUST be sent using separate PKI management operations 📬.
The EE MUST include the generalInfo field implicitConfirm in the header of the ir message as described in Section 3.1, unless it requires certificate confirmation. This leaves the PKI management entities the choice of whether or not the EE must send a certConf message upon receiving a new certificate. Depending on the PKI policy and requirements for managing EE certificates, it can matter a lot for PKI management entities to learn whether 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. If the EE included the generalInfo field implicitConfirm in the request message and the PKI management entity does not need any explicit confirmation from the EE, the PKI management entity MUST include the generalInfo field implicitConfirm in the response message. This prevents explicit certificate confirmation and saves the overhead of a further message round trip ⚡. Otherwise, the PKI management entity SHOULD include confirmWaitTime as described in Section 3.1.
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 can be 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 the certifiedKeyPair field SHALL be omitted. 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 a sequence of one CertReqMsg
-- If more certificates are required, further PKI management
-- operations needs to be initiated
certReq REQUIRED
certReqId REQUIRED
-- MUST be 0
certTemplate REQUIRED
version OPTIONAL
-- MUST be 2 if supplied
subject REQUIRED
-- The EE's identity MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
publicKey OPTIONAL
-- MUST be present if local key generation is used
-- MAY be absent if central key generation is requested
algorithm OPTIONAL
-- MUST be present if local key generation is used and MUST
-- include the subject public key algorithm identifier
-- MAY be present if central key generation is requested and,
-- if present, informs the KGA of algorithm and parameter
-- preferences regarding the to-be-generated key pair
subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of local
-- key generation
-- MUST be a zero-length BIT STRING if central key generation
-- is requested
extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate, like subject alternative name, key
-- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE subject
-- name includes a subject alternative name.
popo OPTIONAL
-- MUST be present if local key generation is used
-- MUST be absent if central key generation is requested
signature OPTIONAL
-- MUST be used by an EE if the key can be used for signing, and
-- if used, it MUST have the type POPOSigningKey
poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the publicKey
-- algorithm field of the certTemplate
signature REQUIRED
-- MUST contain the signature value computed over the DER-encoded
-- certReq
raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3Okay so the ir table is the EE's big "please give me a cert" moment 🎀 Its body holds the request, and the ir has to carry one CertReqMsg (if you need more certs, start another operation 💅). Your identity goes in the subject and/or subjectAltName, and if the subject only lives in the SAN, the subject field is NULL-DN 🦋
Initialization Response -- ip
Field Value
header
-- As described in Section 3.1
body
-- The response of the CA to the request as appropriate
ip REQUIRED
caPubs OPTIONAL
-- MAY be used if the certifiedKeyPair field is present
-- If used, it MUST contain only a trust anchor, e.g., root
-- certificate, of the certificate contained in certOrEncCert
response REQUIRED
-- MUST contain a sequence of one CertResponse
certReqId REQUIRED
-- MUST be 0
status REQUIRED
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection"
-- "waiting" only allowed with a polling use case as described
-- in Section 4.4
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods"
certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection"
certOrEncCert REQUIRED
-- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED
-- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL
-- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in Section 4.1.6 in case the
-- private key was generated centrally
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
-- MUST contain the chain of the certificate present in
-- certOrEncCert
-- Duplicate certificates MAY be omittedNow the ip, which is the CA's answer 👑 The status has to be a PKIStatusInfo, and the positive ones are "accepted" and "grantedWithMods" while "rejection" is the negative one ✨ "waiting" only shows up in the polling situation from Section 4.4 🧚 The certifiedKeyPair only shows up for the good statuses, and the privateKey is only there when the central key generation thing happened (and it's encrypted in an EnvelopedData 🔐)
Certificate Confirmation -- certConf
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE sends a confirmation to the PKI
-- management entity to accept or reject the issued
-- certificates
certConf REQUIRED
-- MUST contain a sequence of one CertStatus
CertStatus REQUIRED
certHash REQUIRED
-- The hash algorithm to use MUST be the hash algorithm indicated
-- in the below hashAlg field. If the hashAlg field is not
-- set, it MUST be the hash algorithm defined by the algorithm
-- identifier of the certificate signature or the dedicated
-- hash algorithm defined in [RFC9481] for the used certificate
-- signature algorithm.
certReqId REQUIRED
-- MUST be 0
statusInfo OPTIONAL
-- PKIStatusInfo structure should be present
-- Omission indicates acceptance of the indicated certificate
status REQUIRED
-- positive values allowed: "accepted"
-- negative values allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted"
hashAlg OPTIONAL
-- The hash algorithm to use for calculating the above certHash
-- If used, the pvno field in the header MUST be cmp2021 (3).
-- For backward compatibility, use of this field is
-- NOT RECOMMENDED if the hash algorithm to use can be
-- identified by other means; see above.
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of this PKI management operationThe certConf is the EE saying "yep, I accept (or nope 💀)" about the certs 🫶 Its certHash has to use the hash algorithm from hashAlg if that's set. If hashAlg isn't set, it's the one from the cert's signature algorithm identifier, or the dedicated one from [RFC9481] for that signature algorithm. The pvno has to be cmp2021 (3) if hashAlg shows up, and using it is NOT RECOMMENDED when the hash algorithm can be figured out some other way 🌸 Leaving out statusInfo means "accepted" 🎀
PKI Confirmation -- pkiConf
Field Value
header
-- As described in Section 3.1
body
pkiconf REQUIRED
-- The content of this field MUST be NULL
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of this PKI management operationAnd the pkiConf is the final "all good, bye" 🌈 Its content has to be NULL, and it's protected with the same credentials as the first response message 🍓
4.1.2. Enrolling an End Entity to a Known PKI
Okay this one is for when an EE already has certs from a PKI and wants one more 💅 It should be used when the EE is asking for an additional certificate from the same PKI it already has certs from. The EE uses one of its existing certs to prove who it is by signing its request messages with the matching private key 🔑
Specific prerequisites that add on to the ones in Section 3.4 are these:
- The certificate used by the EE MUST have been enrolled by the PKI it requests another certificate from.
- When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence here is the same as Section 4.1.1, with a few twists 🦋
- The body of the first request and response SHOULD be cr and cp. Otherwise, ir and ip MUST be used.
Note: Since the difference between ir/ip and cr/cp is syntactically not essential, an ir/ip may be used in this PKI management operation.
- The caPubs field in the certificate response message MUST be absent.
4.1.3. Updating a Valid Certificate
This is the glow-up era for certs ✨ It should be used when an EE wants to update one of its certs that's still valid. The EE uses the cert it wants to update as the CMP protection certificate. It signs the request messages with the matching private key, both to prove who it is and to prove it owns the cert being updated 🔐
Specific prerequisites that add on to the ones in Section 3.4 are these:
- The certificate the EE wishes to update MUST NOT be expired or revoked and MUST have been issued by the addressed CA.
- A new public-private key pair should be used.
- When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence is the same as Section 4.1.1, with these changes 🧚
- The body of the first request and response MUST be kur and kup, respectively.
- Protection of the kur MUST be performed using the certificate to be updated.
- The subject field and/or the subjectAltName extension of the certTemplate MUST contain the EE subject name of the existing certificate to be updated, without modifications.
- The certTemplate SHOULD contain the subject and/or subjectAltName extension and publicKey of the EE only.
- The oldCertId control MAY be used to make clear which certificate is to be updated.
- The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur, the oldCertId control gets 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 updated4.1.4. Enrolling an End Entity Using a PKCS #10 Request 📜✨
okay bestie, so this one is the EE's way of asking for a certificate using PKCS #10 [RFC2986] 💅 it's giving "I need to work with CAs that don't speak CRMF [RFC4211] yet" 🥺 and honestly it's just a variation of the stuff we did in Sections 4.1.1 to 4.1.3, so we're not starting from zero, periodt 🦋
the big rule here 👑: the public key and ALL the other certificate template data MUST be carried in the subjectPKInfo and other certificationRequestInfo fields of the PKCS #10 structure. no sneaking it somewhere else, bestie 🙈
the prerequisites are the same as in Section 4.1.2 🌸
the message sequence is identical to Sections 4.1.1 to 4.1.3, with two little tweaks 💖
- the body of the first request and response MUST be p10cr and cp, respectively 🎀
- the certReqId in the cp message MUST be -1 🧚
Detailed Message Description:
Certification Request -- p10cr 💌
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE for a new certificate using a PKCS #10
-- certificate request
p10cr REQUIRED
certificationRequestInfo REQUIRED
version REQUIRED
-- MUST be 0 to indicate PKCS #10 v1.7
subject REQUIRED
-- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
subjectPKInfo REQUIRED
algorithm REQUIRED
-- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED
-- MUST include the public key to be certified
attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name,
-- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the
-- subjectPKInfo field.
signature REQUIRED
-- MUST contain the self-signature for proof-of-possession
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described for the underlying PKI management operation4.1.5. Using MAC-Based Protection for Enrollment 🔐💜
okay so this is a variant of 4.1.1, 4.1.2, and 4.1.4 🦋 it SHOULD be used by an EE that wants a cert from a new PKI but doesn't have a cert to prove its identity to the target PKI, BUT it does have some secret info shared with the PKI management entity 🤫 so the request and response messages get MAC-protected with that shared secret. how the secret gets distributed is out of scope for this doc, not our problem bestie 🙅♀️
and the PKI management entity checking the MAC-based protection MUST replace that protection according to Section 5.2.3, because the next hop might not know the shared secret 🥹
note: the entropy of the shared secret is crucial for how protected this is 😭 more guidance is in the security considerations updated by CMP Updates [RFC9480], so go read that, it's giving serious security energy 💀
specific prerequisites (on top of Section 3.4) 🌈
- rather than private keys, certificates, and trust anchors, the EE and the PKI management entity MUST share secret information 🤝
- note: the shared secret MUST be established out of band, e.g., by a service technician during initial local configuration 🔧
- when using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile 🎀
the message sequence is identical to Sections 4.1.1, 4.1.2, and 4.1.4, with these changes:
- the protection of ALL messages MUST be MAC-based 💅 so the extraCerts fields of all messages do NOT contain CMP protection certificates and associated chains 🙅♀️
- the sender field MUST contain a name the PKI management entity can use to identify the shared secret information used for message protection 🪪 this name MUST be placed in the commonName field of the directoryName choice 🧚 and the senderKID MUST contain the same name as in the commonName field of the sender field 💖 if the sending entity doesn't yet know which name to request the cert for, it can use this commonName in the subject field of the certTemplate ✨
see Section 6 of CMP Algorithms [RFC9481] for details on the message authentication code algorithms (MSG_MAC_ALG) to use 📚 typically the parameters are part of the protectionAlg field, like a salt and an iteration count 🍓 and those parameters SHOULD stay constant for message protection throughout this PKI management operation, to reduce the computational overhead 🌸
4.1.6. Adding Central Key Pair Generation to Enrollment 🗝️🌈
this is a variant of Sections 4.1.1 to 4.1.4 AND the variant from Section 4.1.5 ✨ it needs to be used when an EE can't generate its new public-private key pair itself, or when central generation of the EE key material is preferred 🙏 which PKI management entity acts as the Key Generation Authority (KGA) and does the key generation is a matter of local implementation 🏠 this PKI management entity MUST use a certificate containing the additional extended key usage extension id-kp-cmKGA, otherwise the EE won't accept it as a legit key generation authority 👑
note: as described in Section 5.3.1, the KGA can use the PKI management operation described in Section 4.1.2 to request the certificate for this key pair on behalf of the EE 💖
when an EE requests central key generation for a certificate update using a kur message, the KGA CANNOT use a kur message to request the certificate on the EE's behalf 😭 because the old EE credential isn't available to the KGA for protecting that message 💔 so if the EE uses the operation in Section 4.1.3, the KGA MUST act as described in Section 4.1.2 to request the certificate for the newly generated key pair on behalf of the EE from the CA 🫶
generally speaking, it is STRONGLY PREFERABLE to generate public-private key pairs locally at the EE 🔐 this is advisable so 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:
- lack of sufficient initial entropy 🥶
- note: good random numbers are needed for key generation but also for session keys and nonces in any security protocol 🎲 so a decent security architecture should anyways support good random number generation on the EE side, or provide enough initial entropy for the random number generator seed to guarantee good pseudorandom number generation 💅 yet maybe this isn't the case when 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 of 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, if it has a preference on the key type to be generated, it provides that preference in the algorithm sub-field and fills the subjectPublicKey sub-field with a zero-length BIT STRING 🧸 both variants tell the PKI management entity that a new key pair SHALL be generated centrally on behalf of the EE 🪄
note: the protection of centrally generated keys in the response message has been extended to EncryptedKey by Section 2.7 of CMP Updates [RFC9480], so EnvelopedData is the preferred alternative to EncryptedValue 💜 in CRMF [RFC4211], Section 2.1, point 9, the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure 😤 therefore this profile REQUIRES using EnvelopedData, as specified in Section 6 of CMS [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 Section 2.20 of CMP Updates [RFC9480] 🦋
+----------------------------------+
| EnvelopedData |
| [RFC5652], Section 6 |
| +------------------------------+ |
| | SignedData | |
| | [RFC5652], Section 5 | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | |
| | | +----------------------+ | | |
| | | | private key | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+
Figure 3: Encrypted Private Key Containerthe PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message, which also contains the newly issued certificate 🎁
the private key MUST be provided as an AsymmetricKeyPackage structure as defined in [RFC5958] 📦
this AsymmetricKeyPackage structure MUST be wrapped in a SignedData structure, as specified in Section 5 of CMS [RFC5652] and [RFC8933], and 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 Section 2.2 of CMP Updates [RFC9480], to demonstrate authorization to generate key pairs on behalf of an EE 👑 for response messages using signature-based protection, the EE MUST validate the signer certificate contained in the SignedData structure and SHOULD authorize the KGA considering any given id-kp-cmKGA extended key usage in the signer certificate 🔍 for response messages using MAC-based protection, the EE MAY omit the validation, as it may not be possible or meaningful to the EE 🤷♀️ in this case, the EE authorizes the KGA using the shard secret information 🗝️
the SignedData structure MUST be wrapped in an EnvelopedData structure, as specified in Section 6 of CMS [RFC5652], encrypting it using a newly generated symmetric content-encryption key 🔒✨
okay so this content-encryption key MUST be securely handed over inside the EnvelopedData structure to the EE 🔐, and there are three key management techniques that can do the job 🧚. Which one the PKI management entity picks depends on how the EE protected its request message, bestie 💖 Check Section 2.7 of CMP Updates [RFC9480] for the full deets ✨
- Signature-based protection of the request message 🖋️
- okay so here the choice depends on the type of public key in the CMP protection certificate that the EE used in its request 💅
- The content-encryption key SHALL be protected using the key transport key management technique (see Section 4.1.6.1) if the key type supports this.
- The content-encryption key SHALL be protected using the key agreement key management technique (see Section 4.1.6.2) if the key type supports this.
- MAC-based protection of the request message 🔑
- The content-encryption key SHALL be protected using the password-based key management technique (see Section 4.1.6.3) if and only if the EE used MAC-based protection for the request message. It's giving very strict vibes 🙈
Okay, these are the extra prerequisites on top of the ones for each certificate enrollment PKI management operation 🎀
- If signature-based protection is used, the EE MUST be able to authenticate and authorize the KGA using suitable information, which includes a trust anchor 🫶
- If MAC-based protection is used, the KGA MUST also know the shared secret information that protects the encrypted transport of the newly generated key pair 🔒 So the EE can also authorize the KGA, which is so iconic 👑
- The PKI management entity MUST have a certificate containing the additional extended key usage extension id-kp-cmKGA for signing the SignedData structure containing the private key package 🌸
- 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. Main character energy for security, no cap 💀
Detailed Description of the privateKey Field: ✨
privateKey REQUIRED
-- MUST be an EnvelopedData structure, as specified in
-- Section 6 of CMS [RFC5652]
version REQUIRED
-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- KeyTransRecipientInfo
-- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED
-- MUST contain a sequence of one RecipientInfo, which MUST be
-- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
-- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
-- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
encryptedContentInfo
REQUIRED
contentType REQUIRED
-- MUST be id-signedData
contentEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the algorithm used for
-- content encryption
-- The algorithm type MUST be PROT_SYM_ALG as specified in
-- [RFC9481], Section 5
encryptedContent REQUIRED
-- MUST be the SignedData structure, as specified in Section 5
-- of CMS [RFC5652] and [RFC8933], in encrypted form
version REQUIRED
-- MUST be 3
digestAlgorithms
REQUIRED
-- MUST contain a sequence of one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm; see [RFC8933]
encapContentInfo
REQUIRED
-- MUST contain the content that is to be signed
eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED
-- MUST be of type AsymmetricKeyPackage and
-- MUST contain a sequence of one OneAsymmetricKey element
version REQUIRED
-- MUST be 1 (indicating v2)
privateKeyAlgorithm
REQUIRED
-- The privateKeyAlgorithm field MUST contain the algorithm
-- identifier of the asymmetric key pair algorithm
privateKey REQUIRED
publicKey REQUIRED
-- MUST contain the public key corresponding to the private key
-- for simplicity and consistency with v2 of OneAsymmetricKey
certificates REQUIRED
-- MUST contain the certificate for the private key used to sign
-- the signedData content, together with its chain
-- The first certificate in this field MUST be the KGA
-- certificate used for protecting this content
-- Self-signed certificates should not be included and MUST NOT
-- be trusted based on their inclusion in any case
signerInfos REQUIRED
-- MUST contain a sequence of one SignerInfo element
version REQUIRED
-- MUST be 3
sid REQUIRED
subjectKeyIdentifier
REQUIRED
-- MUST be the subjectKeyIdentifier of the KGA certificate
digestAlgorithm
REQUIRED
-- MUST be the same as in the digestAlgorithms field of
-- encryptedContent
signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time
-- of a signature. It SHOULD be omitted if the transactionTime
-- field is not present in the PKIHeader.
-- For details on the signed attributes, see Sections 5.3 and
-- 11 of CMS [RFC5652] and [RFC8933]
signatureAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits
-- The signature algorithm type MUST be MSG_SIG_ALG, as
-- specified in [RFC9481], Section 3, and MUST be consistent
-- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED
-- MUST be the digital signature of the encapContentInfoAs stated in Section 1.8, all fields of the ASN.1 syntax that are defined in [RFC5652] but are not explicitly specified here SHOULD NOT be used. Basically, skip the extras, bestie 🙅♀️🍓
4.1.6.1. Using the Key Transport Key Management Technique 🦋
This variant can be applied with the PKI management operations specified in Sections 4.1.1 to 4.1.3, using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST contain a public key supporting key transport and allow for the key usage "keyEncipherment". 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 Section 6.2.1 of CMS [RFC5652] 📜
Detailed Description of the KeyTransRecipientInfo Structure: ✨
ktri REQUIRED
-- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
-- of CMS [RFC5652]
version REQUIRED
-- MUST be 2
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key transport
-- algorithm. The algorithm type MUST be KM_KT_ALG as
-- specified in [RFC9481], Section 4.2
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key4.1.6.2. Using the Key Agreement Key Management Technique 🌟
This variant can be applied with the PKI management operations specified in Sections 4.1.1 to 4.1.3, using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST contain a public key supporting key agreement and allow for the key usage "keyAgreement". 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 Section 6.2.2 of CMS [RFC5652] 📜
Detailed Description of the KeyAgreeRecipientInfo Structure: ✨
kari REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in Section
-- 6.2.2 of CMS [RFC5652]
version REQUIRED
-- MUST be 3
originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the subjectKeyIdentifier
-- choice, and the subjectKeyIdentifier MUST equal the
-- senderKID in the PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
ukm RECOMMENDED
-- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
-- (ECMQV) is used; see [RFC5753]
-- SHOULD be present to ensure uniqueness of the key
-- encryption key
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key agreement
-- algorithm
-- The algorithm type MUST be KM_KA_ALG as specified in
-- [RFC9481], Section 4.1
-- The parameters field of the key agreement algorithm MUST
-- contain the key wrap algorithm. The algorithm type
-- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
recipientEncryptedKeys
REQUIRED
-- MUST contain a sequence of one RecipientEncryptedKey
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used
encryptedKey
REQUIRED
-- MUST be the encrypted content-encryption key4.1.6.3. Using the Password-Based Key Management Technique 🔐✨
Okay bestie, this variant can be paired with the PKI management operation in Section 4.1.5 🎀, which means your CMP messages get MAC-based protection. The shared secret info used for that MAC-based protection MUST also be used to encrypt the content-encryption key 🔑, but with a different salt value 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 info is crucial for how protected you are when you use a password-based key management technique 🥺. For centrally generated key pairs, the entropy of the shared secret info SHALL NOT be less than the security strength of the centrally generated key pair. More guidance is in Section 9 📚.
The PasswordRecipientInfo structure that goes inside the EnvelopedData structure is specified in Section 6.2.4 of CMS [RFC5652] 🧚.
Here's the detailed breakdown of the PasswordRecipientInfo structure 👑:
pwri REQUIRED
-- MUST be PasswordRecipientInfo as specified in
-- Section 6.2.4 of CMS [RFC5652]
version REQUIRED
-- MUST be 0
keyDerivationAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key derivation
-- algorithm
-- The algorithm type MUST be KM_KD_ALG as specified in
-- [RFC9481], Section 4.4
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm type MUST be KM_KW_ALG as specified in
-- [RFC9481], Section 4.3
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key4.2. Revoking a Certificate 🥀
This is the PKI management operation you should reach for when an entity wants to request revocation of a certificate 🙈. Here, the revocation request is used by an EE to revoke one of its own certificates, so it's giving "I'm cleaning up my own mess" energy 🧹.
The revocation request message MUST be signed using the certificate that is to be revoked, which proves you're authorized to revoke it 🔏. The message is signature-protected with that certificate, so this only works if the EE still has the private key. If the EE lost the key, the revocation has to come through other means, e.g., revocation by the RA, as specified in Section 5.3.2 😭.
An EE asks the CA that issued the certificate to revoke a certificate of its own. The PKI management entity handles the request as described in Section 5.1.3 and responds with a message containing the status of the revocation from the CA ✨.
On top of the prerequisites in Section 3.4, there's one extra thing you need:
- The certificate the EE wishes to revoke is not yet expired or revoked.
Message Flow:
Step# EE PKI management entity
1 format rr
2 -> rr ->
3 handle or forward rr
4 format or receive rp
5 <- rp <-
6 handle rpFor this PKI management operation, the EE MUST include a sequence of one RevDetails structure in the rr message body 🎀. If no generic error occurred, the response to the rr MUST be an rp message containing a single status field 💖.
Detailed Message Description:
Revocation Request -- rr
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE to revoke its certificate
rr REQUIRED
-- MUST contain a sequence of one element of type RevDetails
-- If more revocations are desired, further PKI management
-- operations need to be initiated
certDetails REQUIRED
-- MUST be present and is of type CertTemplate
serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the
-- certificate to be revoked
issuer REQUIRED
-- MUST contain the issuer attribute of the certificate to be
-- revoked
crlEntryDetails REQUIRED
-- MUST contain a sequence of one reasonCode of type CRLReason
-- (see [RFC5280], Section 5.3.1)
-- If the reason for this revocation is not known or shall not
-- be published, the reasonCode MUST be 0 (unspecified)
protection REQUIRED
-- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked
extraCerts REQUIRED
-- As described in Section 3.3Revocation Response -- rp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity to the request as
-- appropriate
rp REQUIRED
status REQUIRED
-- MUST contain a sequence of one element of type PKIStatusInfo
status REQUIRED
-- positive value allowed: "accepted"
-- negative value allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if the status is "rejection"
-- MUST be absent if the status is "accepted"
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.34.3. Support Messages 🧁
These support messages are the on-demand, in-band delivery squad 🚀. They bring content relevant to the EE from a PKI management entity. CMP general messages and general response are used for this purpose, and depending on the environment, an RA or CA may be the one answering (see also Section 5.1.4) 💅.
The general messages and general response messages contain InfoTypeAndValue structures. Besides the infoType values defined in [RFC4210] and CMP Updates [RFC9480], further OIDs MAY be used to define new PKI management operations or new general-purpose support messages as needed in specific environments 🌈.
The following contents are specified in this document:
- Get CA certificates.
- Get root CA certificate update.
- Get certificate request template.
- Get new Certificate Revocation Lists (CRLs).
The following message flow and contents are shared by all general message (genm) and general response (genp) messages 🫶.
Message Flow:
Step# EE PKI management entity
1 format genm
2 -> genm ->
3 handle or forward genm
4 format or receive genp
5 <- genp <-
6 handle genpDetailed Message Description:
General Message -- genm
Field Value
header
-- As described in Section 3.1
body
-- A request by the EE for information
genm REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying one of the specific PKI
-- management operations described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3General Response -- genp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity providing
-- information
genp REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying the specific PKI management
-- operation described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.34.3.1. Get CA Certificates 🏛️
This PKI management operation is how an EE gets CA certificates from the PKI management entity 🗂️.
An EE requests CA certificates, e.g., for chain construction, by sending a general message with the OID id-it-caCerts, as specified in Section 2.14 of CMP Updates [RFC9480] 🔗. The PKI management entity responds with a general response with that same OID. The response either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates, or no content if no CA certificate is available 🎀.
No specific prerequisites apply beyond those in Section 3.4 🌸.
The message sequence for this operation is as given above, with this specific content:
- the infoType OID to use is
id-it-caCerts - the infoValue of the request MUST be absent
- if present, the infoValue of the response MUST contain a sequence of certificates
Detailed Description of the infoValue Field of genp:
infoValue OPTIONAL
-- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available
-- if present, MUST be a sequence of CMPCertificate4.3.2. Get Root CA Certificate Update ✨
okay bestie, so this is the op where an EE 🫶 asks the PKI management entity for an updated root CA certificate. The main idea is spelled out in Section 4.4 of [RFC4210]. 💅
To ask, the EE sends a general message with the OID id-it-rootCaCert. 🎀 If it's needed for unique identification, the EE MUST include the old root CA certificate in the message body, as described in Section 2.15 of CMP Updates [RFC9480]. 💖 The PKI management entity answers with a general response carrying the OID id-it-rootCaKeyUpdate. That response either has the update (up to three certificates) or no content at all, which just means no update is available. 🙈
Note: this same mechanism can also update trusted non-root certificates, like directly trusted intermediate or issuing CA certificates. 🌸
Now the certificate roles, which are a whole vibe. 🦋 The newWithNew certificate is the new root CA certificate, and it is REQUIRED to be present if one is available. ✨ The newWithOld certificate is REQUIRED in the response, because an entity that trusts the old root CA needs it to gain trust in the new one. 🔥 The oldWithNew certificate is OPTIONAL, since it's only needed in rare cases where other entities don't already trust the old root CA. 🌈
No extra prerequisites beyond the ones in Section 3.4. 💜
The message sequence is the same as given above, with these specific details:
- the infoType OID to use is id-it-rootCaCert in the request and id-it-rootCaKeyUpdate in the response 🧚
- the infoValue of the request SHOULD contain the root CA certificate the update is requested for 🍓
- if present, the infoValue of the response MUST be a RootCaKeyUpdateContent structure 👑
Detailed Description of the infoValue Field of genm:
infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated if needed
-- for unique identificationDetailed Description of the infoValue Field of genp:
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 key4.3.3. Get Certificate Request Template 🎀
okay so this op lets an EE ask for a template with parameters for future certificate requests. 🦋 It's giving "here's the blueprint, use it." 💅
The EE asks for those parameters by sending a general message with the OID id-it-certReqTemplate, as described in Section 2.16 of CMP Updates [RFC9480]. ✨ The EE MAY name the certificate profile it wants in the id-it-certProfile extension of the generalInfo field in the PKIHeader of that general message, as covered in Section 3.1. 🌸 The PKI management entity replies with a general response using the same OID. That response either has requirements on the certificate request template, or no content if the PKI doesn't impose any specific requirements. 🫶 The CertReqTemplateValue holds requirements on certificate fields and extensions in a certTemplate. It can optionally also include a keySpec field, which sets requirements on algorithms that are acceptable for key pair generation. 🔑
Now the rules for the EE, which are very main character. 👑
The EE SHOULD follow the requirements from the received CertTemplate. It should include all the fields requested, take over every field value provided, and fill in whatever's left. 💖 The EE SHOULD NOT add further fields, name components, and extensions or their (sub)components. 🙈 If the EE deviates from the template's recommendations, the certificate request might get rejected. 💀
Note: we deliberately don't use "MUST" or "MUST NOT" here. That leaves room for more flexibility in case these rules don't cover a specific scenario. 🌈 The EE can fill in the certificate request however it wants and ignore any of the requirements in the CertReqTemplateValue. On the flip side, the PKI management entity is free to ignore or replace any parts of the certificate request the EE provides. 🦋 The CertReqTemplate operation is there to help both sides agree on which fields and field values should be used. An example is in Appendix A. ✨
If a field of type Name (like subject) is in the CertTemplate but its value is NULL-DN (meaning an empty list of relative distinguished name (RDN) components), the field SHOULD be included in the certificate request and filled with content from the EE. 🍓 Same vibe for an X.509v3 extension whose extnValue is empty: it SHOULD be included and filled with content from the EE. 🧚 If a Name component (like a common name or serial number) is given but has an empty string value, the EE SHOULD fill in a value. 💜 And if an extension has subcomponents with empty values (like an IP address in a SubjectAltName field), the EE SHOULD fill in a value too. 🫶
The EE MUST ignore (meaning not include) empty fields, extensions, and subcomponents that it doesn't understand or doesn't know suitable values to fill in. 🙈
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue MUST be omitted. 🚫 If the PKI management entity wants to stipulate which algorithms the EE may use for key generation, it MUST specify that using the keySpec field, as described in Section 2.16 of CMP Updates [RFC9480]. 🔥
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 in Section 2.16 of CMP Updates [RFC9480], MUST be of type AlgorithmIdentifier and give an algorithm other than RSA. 💅 For Elliptic Curve (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 in Section 2.16 of CMP Updates [RFC9480], 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. 🙅
The specific prerequisites, which add to the ones in Section 3.4, are as follows:
- When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile. 🧚
The message sequence is the same as given above, with these specific details:
- the infoType OID to use is id-it-certReqTemplate 🍓
- the id-it-certProfile generalInfo field in the header of the request MAY contain the name of the requested certificate request template 🌸
- the infoValue of the request MUST be absent 💜
- if present, the infoValue of the response MUST be a CertReqTemplateValue containing a CertTemplate structure and an optional keySpec field 👑
Detailed Description of the infoValue Field of genp:
InfoValue OPTIONAL
-- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any
-- requirements on the contents of the certificate template
certTemplate REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the required CertTemplate structure elements
-- The SubjectPublicKeyInfo field MUST be absent
keySpec OPTIONAL
-- MUST be absent if no requirements on the public key are
-- available
-- MUST be present if the PKI management entity has any
-- requirements on the keys generated
-- MUST contain a sequence of one AttributeTypeAndValue per
-- supported algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen4.3.4. CRL Update Retrieval 📜✨
okay so this one is how an EE (end entity) asks for a fresh CRL 🦋, which is the list of certs that got revoked. If a CA offers ways to access a CRL, it may put CRL distribution points or authority information access extensions into the certs it issues, as specified in [RFC5280]. CMP also has CRL provisioning built right into the PKI management operation, and that's lowkey iconic 💅
An EE asks the PKI management entity for a CRL update by sending a general message with the OID id-it-crlStatusList. The EE MUST include the CRL source that identifies the requested CRL and, if it has one, the thisUpdate time of the most current CRL instance it already has, as specified in Section 2.17 of CMP Updates [RFC9480]. The PKI management entity MUST respond with a general response with the OID id-it-crls.
The EE MUST identify the requested CRL either by a CRL distribution point name or issuer name. 🎯
Note: CRL distribution point names can be obtained from a cRLDistributionPoints extension of a certificate to be validated or from an issuingDistributionPoint extension of the CRL to be updated. CRL issuer names can be obtained from the cRLDistributionPoints extension of a certificate, from the issuer field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL. 🗺️
If a thisUpdate value was given, the PKI management entity MUST return the latest CRL available from the referenced source if this CRL is more recent than the given thisUpdate time. If no thisUpdate value was given, it MUST return the latest CRL available from the referenced source. In all other cases, the infoValue in the response message MUST be absent. 🙅♀️
The PKI management entity should treat a CRL distribution point name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CRL from an external location, as this location may be unavailable to that PKI management entity. so no random internet fetching here, bestie 🙈
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 instead use a general message with OID id-it-currentCrl as specified in Section 5.3.19.6 of [RFC4210]. 💖
The message sequence for this PKI management operation is as given above, with the following specific content:
- the infoType OID to use is
id-it-crlStatusListin the request andid-it-crlsin the response - the infoValue of the request MUST be present and contain a sequence of one CRLStatus structure
- if present, the infoValue of the response MUST contain a sequence of one CRL
Detailed Description of the infoValue Field of genm:
infoValue REQUIRED
-- MUST contain a sequence of one CRLStatus element
source REQUIRED
-- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element.
thisUpdate OPTIONAL
-- MUST contain the thisUpdate field of the latest CRL the EE
-- has gotten from the issuer specified in the given dpn or
-- issuer field
-- MUST be omitted if the EE does not have any instance of the
-- requested CRLDetailed Description of the infoValue Field of genp:
infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available
-- MUST contain a sequence of one CRL update from the referenced
-- source if a thisUpdate value was not given or a more recent
-- CRL is available4.4. Handling Delayed Delivery ⏳💜
This is a variant of all PKI management operations described in this document. It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication or due to delays in handling the request. The polling mechanism has been specified in Section 5.3.22 of [RFC4210] and updated by [RFC9480]. so basically it's the "hold on, I'm still working on it" moment, but make it protocol 🫶
Depending on the PKI architecture, the entity initiating delayed delivery is not necessarily the PKI management entity directly addressed by the EE. 🏗️
When initiating delayed delivery of a message received from an EE, the PKI management entity MUST respond with a message including the status "waiting". In response to an ir/cr/kur/p10cr message, it must place the status "waiting" in an ip/cp/kup message and for responses to other request message types in an error message. On receiving this response, the EE MUST store in its transaction context the senderNonce of the preceding request message because this value will be needed for checking the recipNonce of the final response to be received after polling. It sends a poll request with certReqId 0 if referring to the CertResponse element contained in the ip/cp/kup message, else -1 to refer to the whole message. In case the final response is not yet available, the PKI management entity that initiated the delayed delivery MUST answer with a poll response with the same certReqId. The included checkAfter time value indicates the minimum number of seconds that should elapse before the EE sends a new pollReq message to the PKI management entity. Polling earlier than indicated by the checkAfter value may increase the number of message round trips. This is repeated until a final response is available or any party involved gives up on the current PKI management operation, i.e., a timeout occurs. 🔁✨
When the PKI management entity that initiated delayed delivery can provide the final response for the original request message of the EE, it MUST send this response to the EE. Using this response, the EE can continue the current PKI management operation as usual. 🎉
No specific prerequisites apply in addition to those of the respective PKI management operation. 📋
Message Flow:
Step# EE PKI management entity
1 format request
message
2 -> request ->
3 handle or forward
request
4 format ip/cp/kup/error
with status "waiting"
response in case no
immediate final response
is available
5 <- ip/cp/kup/error <-
6 handle
ip/cp/kup/error
with status
"waiting"
-------------------------- start polling --------------------------
7 format pollReq
8 -> pollReq ->
9 handle or forward pollReq
10 in case the final response
for the original request
is available, continue
with step 14
otherwise, format or
receive pollRep with
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse and
continue with
step 7
----------------- end polling, continue as usual ------------------
14 format or receive
final response on
the original request
15 <- response <-
16 handle final
responseDetailed Message Description:
Response with Status "waiting" -- ip/cp/kup/error
Field Value
header
-- As described in Section 3.1
body
-- As described for the respective PKI management operation, with
-- the following adaptations:
status REQUIRED -- in case of ip/cp/kup
pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be status "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo PROHIBITED
protection REQUIRED
-- As described in Section 3.2
extraCerts OPTIONAL
-- As described in Section 3.3Polling Request -- pollReq
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE asking for the final response or for a
-- time to check again
pollReq REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of the PKI management operationPolling Response -- pollRep
Field Value
header
-- As described in Section 3.1
body
-- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction
pollRep REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED
-- MUST be the time in seconds to elapse before a new pollReq
-- should be sent
reason OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of the PKI management operationFinal 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 operation5. PKI Management Entity Operations ✨
okay so this section is all about what a PKI management entity does when a request lands on its desk 💅 depending on how the network and PKI are designed, that entity can be an RA or a CA, and either one may include protocol conversion or central key generation (aka acting as a KGA) 🔥
a PKI management entity can directly answer request messages from downstream and report errors 🎀 if it's an RA, it typically checks the requests, forwards them upstream, and then passes the matching responses back downstream 🦋 besides answering or forwarding, a PKI management entity can also request or revoke certificates on behalf of EEs 💖 and it might need to look after its own certificates, which means it acts as an EE and uses the PKI management operations from Section 4 🫶
5.1. Responding to Requests
The PKI management entity terminating the PKI management operation at CMP level MUST respond to every received request, either with a related CMP response message or with an error 🍓 any intermediate PKI management entity MAY respond too, depending on the PKI configuration and policy 🌸
In addition to the checks described in Section 3.5, the responding PKI management entity MUST check that a request starting a new PKI management operation doesn't use a transactionID that's currently in use 😭 the failInfo bit to use here is transactionIdInUse, as described in Section 3.6.4. If any of these verification steps, or any of the essential checks described in Section 3.5 and in the subsections that follow it, fails, the PKI management entity MUST proceed as described in Section 3.6.
the responding PKI management entity MUST copy the sender field of the request into the recipient field of the response, MUST copy the senderNonce of the request into the recipNonce of the response, and MUST use the same transactionID for the response 💜
5.1.1. Responding to a Certificate Request
an ir/cr/kur/p10cr 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.5.
the PKI management entity MUST check the message body according to the applicable requirements from Section 4.1. possible failInfo bit values for error reporting when a check fails 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. if a signature-based proof-of-possession is present, the PKI management entity MUST verify, based on local PKI policy, that the subject name in the certTemplate identifies the same entity as the subject name in the CMP protection certificate, or matches the identifier used with MAC-based protection. if this verification fails, the message MUST have been protected by an authorized PKI management entity (failInfo bit: notAuthorized). if the special POP value "raVerified" is given, the PKI management entity 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 also perform 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 the private key in encrypted form in the response, as specified in Section 4.1.6. this part is important, bestie 🔐
the prerequisites of the respective PKI management operation specified in Section 4.1 apply 📋
if the EE requested omission of the certConf message, the PKI management entity MUST handle it as described in Section 4.1.1. so it MAY grant this by including the implicitConfirm generalInfo field, or by including the confirmWaitTime field in the response header 🦋
5.1.2. Responding to a Confirmation Message
a PKI management entity MUST handle a certConf message if it has responded before with a positive ip/cp/kup message that did not grant implicit confirmation 💖 it should check the message body according to the requirements in Section 4.1.1 (failInfo bit: badCertId), and MUST react as described there.
the prerequisites of the respective PKI management operation specified in Section 4.1 apply ✅
5.1.3. Responding to a Revocation Request
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 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 🫧
5.1.4. Responding to a Support Message
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. so it may be worth caching the body of the response message as long as the contained information is valid and current, so that further requests for the same contents can be answered immediately ⚡
no specific prerequisites apply in addition to those specified in Section 3.4 🌷
5.1.5. Initiating Delayed Delivery
this functional extension can be used by a PKI management entity when the response to a request takes longer than usual ⏳ in this case, the PKI management entity should completely validate the request as usual, and then start processing it itself or forward it 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 🫶
typically, as stated in Section 5.2.3, an intermediate PKI management entity should not change the sender and recipient nonces, even when 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 alternate use of the senderNonce of the original request 🧠
no specific prerequisites apply in addition to those of the respective PKI management operation 🌟
5.2. Forwarding Messages
in case the PKI solution consists of intermediate PKI management entities (i.e., LRA or RA), each CMP request message coming from an EE or any other downstream PKI management entity MUST either be forwarded to the next (upstream) PKI management entity as described in this section, or answered as described in Section 5.1 🔁 any received response message, or any locally generated error message, MUST be forwarded to the next (downstream) PKI entity 💌
in addition to the checks described in Section 3.5, the forwarding PKI management entity MAY verify the proof-of-possession for ir/cr/kur/p10cr messages. if one of these verification procedures fails, the RA proceeds as described in Section 3.6 🙅♀️
a PKI management entity SHOULD NOT change the received message unless its role in the PKI system requires it 🚫 this is because changes to the message header or body imply reprotection. changes to the protection break end-to-end authentication of the message source. changes to the certificate template in a certificate request break proof-of-possession. more details are in the following subsections. concrete PKI system specifications may define when to do so in more detail 📚
this is particularly relevant in the upstream communication of a request message 🎯
each forwarding PKI management entity has one or more functionalities. it may:
- verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,
- add or modify fields of certificate request messages,
- replace a MAC-based protection with a signature-based protection that can also be verified further upstream, and vice versa,
- double-check if the messages transferred back and forth are properly protected and well-formed,
- provide an authentic indication that it has performed all required checks,
- initiate a delayed delivery due to delays transferring messages or handling requests, or
- collect messages from multiple RAs and forward them jointly.
Note: PKI management entities forwarding messages may also store data from a message in a database for later usage or audit purposes. they may also support traversal of a network boundary 🗄️
the decision on whether a message should be forwarded is one of the following, depending on the PKI solution design and the associated security policy, e.g., as defined in the certificate policy (CP) / certification practice statement (CPS) documents [RFC3647] 🧾:
- unchanged with the original protection,
- unchanged with an additional protection, or
- changed with an additional protection.
A PKI management entity SHOULD add, or MAY replace, a protection of a message if it:
- needs to securely indicate to one of the next (upstream) PKI management entities that it has done checks or validations on the message, or
- needs to protect the message using a key and certificate from a different PKI.
if retaining end-to-end message authentication is required, an additional protection SHALL be added instead of replacing the original protection 🔐
A PKI management entity MUST replace a protection of a message if it:
- performs changes to the header or the body of the message, or
- needs to convert from or to a MAC-based protection.
this is particularly relevant in the upstream communication of certificate request messages 💫
Note that the message protection covers only the header and the body, and not the extraCerts. the PKI management entity MAY change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certificates to support subsequent PKI entities. this can be especially helpful for augmenting upstream messages with additional certificates, or for reducing the number of certificates in downstream messages when forwarding to constrained devices 🪷
5.2.1. Not Changing Protection 🎀
Okay so this variant is giving "just passing it along" 🦋. The PKI management entity forwards a CMP message without changing the header, body, or protection. It's basically acting like a proxy, like at a network boundary 🌸. It isn't doing any specific RA-like security stuff that needs an authentic indication to the PKI. Still, the PKI management entity might have checks that make it refuse to forward the request and respond instead as specified in Section 3.6 💅.
This variant, or the one in Section 5.2.2.1, MUST be used for kur messages and for central key generation 🔥. Like, no other option for these, periodt 💀.
No specific prerequisites apply on top of the ones in Section 3.4 ✨.
5.2.2. Adding Protection and Batching of Messages 🌈
This variant of forwarding means the PKI management entity adds another protection to PKI management messages before forwarding them 🫶.
The nested message is a PKI management message with a PKIMessages sequence as its body, and that sequence holds one or more CMP messages 💜.
As specified in the updated Section 5.1.3.4 of [RFC4210] (also see Section 2.6 of CMP Updates [RFC9480]), there are a bunch of use cases for adding another protection by a PKI management entity 🧚. The specific procedures get covered 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.35.2.2.1. Adding Protection to a Request Message 🍓
This variant means the PKI management entity forwards a CMP message while authentically indicating that it successfully validated and approved a request message, and the original message authentication stays untouched 💖.
By adding a protection with its own CMP protection key, the PKI management entity proves it verified and approved the message, as described above 👑. So the PKI management entity acts as an actual registration authority (RA), which handles important security functionality of the PKI 😭. Adding this extra protection is especially relevant when forwarding a message that requests a certificate update or central key generation, because the EE's original protection has to be preserved while the approval gets added on top 🙈.
The PKI management entity wrapping the original request message in a nested message structure MUST copy the values of the senderNonce and transactionID header fields of the original message to the matching header fields of the nested message, and apply signature-based protection. The extra signature works 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. Other fields in the header of the nested message can be ignored 🦋.
The PKI management entity responding to the request inside the nested message sends the response as described in Section 5.1, without wrapping it in a nested message 🌸.
Note: When responding to the inner request message, it must be considered that the verification and approval activity described in this section has already been performed by the PKI management entity that protected the nested message.
Note: This form of nesting 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.
The specific prerequisite, which adds to the ones in Section 3.4, is this one 💅:
- The PKI management entity MUST be able to validate the respective request and have the authorization to approve the request according to the PKI policies.
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 response5.2.2.2. Batching Messages 🎀
A PKI management entity MAY bundle any number of PKI management messages for batch processing, or to transfer a bunch of them, using the nested message structure 🫧. In this use case, nested messages get used both on the upstream interface for sending request messages toward the next PKI management entity, and on its downstream interface for responses 🌷.
This operation is typically used on the interface between an LRA and an RA, to bundle several messages for offline or asynchronous delivery 🧁. In this case the LRA needs to initiate delayed delivery, as described in Section 5.1.5 🕰️. If the RA needs different routing info per nested PKI management message provided upstream, a suitable mechanism may need to be implemented so the downstream response gets delivered to the right requester 🛤️. 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 endpoint, so 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 must store the sender, transactionID, and senderNonce fields of all bundled messages together with the transactionID of the upstream nested message 📝.
That upstream nested message gets 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 MUST return the senderNonce of the upstream nested message as the recipNonce of the downstream nested message 🔁. The downstream nested message MUST bundle all available individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp, genp, or error) for all original request messages of the upstream nested message 📦. While unbundling the downstream nested message, the former PKI management entity must figure out lost and unexpected responses based on the previously stored transactionIDs 🕵️♀️. When it forwards the unbundled responses, any extra messages MUST be dropped, and any missing response message MUST be answered with an error message (failInfo bit: systemUnavail), so the respective requester knows the certificate management operation failed 🥺.
Note: This form of nesting is characterized by the fact that the transactionID in the header of the nested message is different from those used in the included messages.
The protection of the nested messages MUST NOT be regarded as an indication of verification or approval of the bundled PKI request messages 🚫.
No specific prerequisites apply on top of the ones 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 nested5.2.3. Replacing Protection 🦄
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 👑.
If retaining end-to-end message authentication is required, an additional protection SHALL be added instead of replacing the original protection 🔒.
By replacing the existing protection with its own CMP protection key, the PKI management entity proves it verified and approved the message, as described above. So it acts as an actual registration authority (RA), handling important security functionality of the PKI, such as verifying the proof of requester identity and authorization 💫.
Note: By replacing the message protection, the binding of a signature-based proof-of-possession to the proof-of-identity given by the original message protection gets lost. To enable the CA to verify this binding, the original message can be provided in the origPKIMessage generalInfo field.
Before replacing the existing protection with a new protection, the PKI management entity:
- MUST validate the protection of the received message,
- should check the content of the message,
- may do any modifications that it wants to perform, and
- MUST check that the sender of the original message, as authenticated by the message protection, is authorized for the given operation.
- for certificate requests, MUST verify the binding of signature-based proof-of-possession to the proof-of-identity as described in Section 5.1.1.
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 🙅♀️.
These message adaptations MUST NOT be applied to certificate request messages described in Section 4.1.6 for central key generation, since their original protection needs to be preserved up to the KGA, 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 MUST NOT change the transactionID, the senderNonce, or the recipNonce, apart from the exception for the recipNonce given in Section 5.1.5 💖.
5.2.3.1. Not Changing Proof-of-Possession 🎀
okay so this variant of forwarding is when a PKI management entity passes a CMP message along 💅 with or without touching the message header or body, and it keeps any included proof-of-possession exactly as it was 🫶 that's the whole vibe.
This variant is typically used when an RA swaps out an existing MAC-based protection for its own signature-based protection 🦋. That's lowkey genius, because the upstream PKI management entity doesn't know the respective shared secret information, so replacing the protection is useful.
Note: a signature-based proof-of-possession of a certificate request will be broken if any field in the certTemplate structure is changed. 💀
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 🙈
The specific prerequisite augmenting the prerequisites in Section 3.4 is as follows:
- The PKI management entity MUST be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies. 👑
5.2.3.2. Using raVerified 🌸
this variant needs to be used if a PKI management entity breaks any included 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 main character moment here is the popo getting an upgrade ✨
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 are as follows:
- The PKI management entity MUST be authorized to replace the proof-of-possession (after verifying it) with
raVerified. - The PKI management entity MUST be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.
Detailed Description of the popo Field of the certReq Structure: 🍓
popo
raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message5.3. Acting on Behalf of Other PKI Entities 🫶
A PKI management entity may need to request a PKI management operation on behalf of another PKI entity. In this case, the PKI management entity initiates the respective PKI management operation as described in Section 4, acting in the role of the EE. it's giving "middle person who still gets things done" 💅
Note: the request message protection will not authenticate the EE, but it will authenticate the RA acting on behalf of the EE. 🔥
5.3.1. Requesting a Certificate 💖
A PKI management entity may use one 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 MUST verify the received proof-of-possession if this proof breaks, e.g., due to transformation from PKCS #10 [RFC2986] to CRMF [RFC4211]. It MUST also verify, based on local PKI policy, that the subject name in the certTemplate identifies the EE. ngl this is a lot of checking, but it's the responsible kind 🙈
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:
- The request messages MUST be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation.
- If inclusion of a proper proof-of-possession is not possible, the PKI management entity MUST verify the POP provided from downstream and use
raVerifiedin its upstream request. - The binding of the proof-of-possession to the proof-of-identity of the requesting EE cannot be provided when acting on behalf of the EE. 😭
5.3.2. Revoking a Certificate 🌈
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. bestie, the signing key is doing the heavy lifting here 🔐
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:
- The rr message MUST be signed using the CMP protection key of the PKI management entity acting on behalf of the EE in this operation.
6. CMP Message Transfer Mechanisms 🚀
CMP messages are designed to be self-contained, such that, in principle, any reliable transfer mechanism can be used. EEs will typically support only one transfer mechanism. PKI management entities SHOULD offer HTTP and MAY offer CoAP where required. Piggybacking of CMP messages on any other reliable transfer protocol MAY be used, and file-based transfer MAY be used in case offline transfer is required. so many options, all of them reliable-ish 💜
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 PKI entity that sends CMP requests should use a configurable per-request timeout, and each PKI management entity that handles CMP requests should use a configurable 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. no more waiting around forever, that's a whole mood 🥹
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 reestablishment and message retransmission. 🌸
Note: long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling. 🧚
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. ✨
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 3.4 of CMP over HTTP [RFC6712] and Section 2.3 of CMP over CoAP [RFC9482]. the media type is the ID badge for CMP, so don't forget it 🎀
6.1. HTTP Transfer 🌸
okay so this transfer mechanism lets a PKI entity send CMP messages over HTTP 💖 if you go the HTTP route, the rules in [RFC6712], as updated by the CMP Updates doc [RFC9480], MUST be followed. no skipping, bestie ✨
PKI management operations MUST use a URI path made of /.well-known/cmp or /.well-known/cmp/p/<name>, as laid out in Section 3.3 of CMP Updates [RFC9480]. It SHOULD be followed by an operation label that matches the type of PKI management operation 🎀
+============================+====================+=========+
| PKI Management Operation | URI Path Segment | Details |
+============================+====================+=========+
| Enrolling an End Entity to | initialization | Section |
| a New PKI | | 4.1.1 |
+----------------------------+--------------------+---------+
| Enrolling an End Entity to | certification | Section |
| a Known PKI | | 4.1.2 |
+----------------------------+--------------------+---------+
| Updating a Valid | keyupdate | Section |
| Certificate | | 4.1.3 |
+----------------------------+--------------------+---------+
| Enrolling an End Entity | pkcs10 | Section |
| Using a PKCS #10 Request | | 4.1.4 |
+----------------------------+--------------------+---------+
| Revoking a Certificate | revocation | Section |
| | | 4.2 |
+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get Certificate Request | getcertreqtemplate | Section |
| Template | | 4.3.3 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+
| Batching Messages | nested | Section |
| | | 5.2.2.2 |
| Note: This path element is | | |
| applicable only between | | |
| PKI management entities. | | |
+----------------------------+--------------------+---------+Table 1: HTTP URI Path Segment <operation>
If operation labels are used, here's the deal 👑
- Independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.
- Any certConf or pollReq messages SHALL be sent to the same endpoint as determined by the PKI management operation.
- When a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will find out, via the HTTP response status code, whether a configured URI is supported by the PKI management entity 🦋
In case a PKI management entity gets 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 that matches the status code, e.g., systemFailure 😭
For certificate management, the major security goals are integrity and data origin authentication. For delivery of centrally generated keys, confidentiality is also a must. CMP itself sufficiently achieves these goals, also in an end-to-end fashion 🔥
If a second line of defense is required or general privacy concerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer, as described in [RFC9110]. In addition, the recommendations in [RFC9325] should be followed. Protect your HTTP transfer, periodt 💀
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., when 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 shared secret information-based TLS authentication. A pre-shared key (PSK) mechanism may be used with shared secret information with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended 💜
Note: The provisioning of client certificates and PSKs is out of scope of this document 🍓
6.2. CoAP Transfer 🦋
This transfer mechanism lets a PKI entity send CMP messages over CoAP [RFC7252], e.g., in constrained environments 🧚 if CoAP transfer is used, the specifications in CMP over CoAP [RFC9482] MUST be followed. ✨
PKI management operations MUST use a URI path made of /.well-known/cmp or /.well-known/cmp/p/<name>, as specified in Section 2.1 of CMP over CoAP [RFC9482]. It SHOULD be followed by an operation label depending on the type of PKI management operation 💅
+=======================================+=========+=========+
| PKI Management Operation | URI | Details |
| | Path | |
| | Segment | |
+=======================================+=========+=========+
| Enrolling an End Entity to a New PKI | ir | Section |
| | | 4.1.1 |
+---------------------------------------+---------+---------+
| Enrolling an End Entity to a Known | cr | Section |
| PKI | | 4.1.2 |
+---------------------------------------+---------+---------+
| Updating a Valid Certificate | kur | Section |
| | | 4.1.3 |
+---------------------------------------+---------+---------+
| Enrolling an End Entity Using a PKCS | p10 | Section |
| #10 Request | | 4.1.4 |
+---------------------------------------+---------+---------+
| Revoking a 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 |
+---------------------------------------+---------+---------+
| CRL Update Retrieval | crls | Section |
| | | 4.3.4 |
+---------------------------------------+---------+---------+
| Batching Messages | nest | Section |
| | | 5.2.2.2 |
| Note: This path element is applicable | | |
| only between PKI management entities. | | |
+---------------------------------------+---------+---------+Table 2: CoAP URI Path Segment <operation>
If operation labels are used, the same rules apply 🌈
- Independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.
- Any certConf or pollReq messages SHALL be sent to the same endpoint, as determined by the PKI management operation.
- When a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.
By sending a request to its preferred endpoint, the PKI entity will find out, 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 gets 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 that matches the status code, e.g., systemFailure 😭
Like with HTTP transfer, if you want a second line of defense or hop-by-hop privacy protection, DTLS may be used as described in CMP over CoAP [RFC9482]. If DTLS is used, the same boundary conditions (peer authentication, etc.) as those stated for TLS protecting HTTP transfer in Section 6.1 apply to DTLS too 🫶
Note: The provisioning of client certificates and PSKs is out of scope of this document 🍓
6.3. Piggybacking on Other Reliable Transfer 🎀
CMP messages MAY also be transferred over some other reliable protocol, e.g., Extensible Authentication Protocol (EAP) or Message Queuing Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms similar to those specified for HTTP in [RFC6712] need to be implemented 💖
A more detailed specification is out of scope of this document. It would need to be given, for instance, in the scope of the transfer protocol being used ✨
6.4. Offline Transfer 🌙
For transferring CMP messages between PKI entities, any mechanism that can store and forward binary objects of sufficient length, with sufficient reliability, while preserving the order of messages for each transaction, can be used 📦
The transfer mechanism should be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases, the PKI entities MUST report an error as specified in Section 3.6, as far as possible 🚨
6.4.1. File-Based Transfer 📁
CMP messages MAY be transferred between PKI entities using file-based mechanisms, for instance, when an EE is offline or a PKI management entity does 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 filename extension ".pki" MUST be used 💅
6.4.2. Other Asynchronous Transfer Protocols
Other asynchronous transfer protocols, like email or website upload/download, MAY transfer CMP messages between PKI entities 💌 A MIME wrapping is defined for environments that are MIME-native 🎀 That MIME wrapping is specified in Section 3.1 of [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 Section 3.4 of CMP over HTTP [RFC6712] 🫶 A filename MUST be included in either a content-type or a content-disposition statement, and the filename extension .pki MUST be used 📎
7. Conformance Requirements ✨
This section defines which level of support for the various features specified in this profile is required for each type of PKI entity 👑
7.1. PKI Management Operations
The following table gives you the overview of the PKI management operations specified in Sections 4 and 5 and says 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, so they're included too 🦋
The PKI management operation specifications in Section 4 assume that either the RA or CA is the PKI management entity that terminates the Certificate Management Protocol. If the RA terminates CMP, it either responds directly as described in Section 5.1, or it forwards the certificate management operation towards the CA not using CMP. Section 5.2 describes different options of how an RA can forward a CMP message using CMP. Section 5.3 offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in Section 4 🧚
+==========+=============================+========+========+========+
| ID | PKI Management Operations | EE | RA | CA |
| | and Variants | | | |
+==========+=============================+========+========+========+
| Generic | Generic Aspects of PKI | MUST | MUST | MUST |
| | Messages and PKI | | | |
| | Management Operations, | | | |
| | Section 3 | | | |
+----------+-----------------------------+--------+--------+--------+
| IR | Enrolling an End Entity to | MUST | MAY | MUST |
| | a New PKI, Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| CR | Enrolling an End Entity to | MAY | MAY | MAY |
| | a Known PKI, Section 4.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| KUR | Updating a Valid | MUST | MAY | MUST |
| | Certificate, Section 4.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| P10CR | Enrolling an End Entity | MAY | MAY | MAY |
| | Using a PKCS #10 Request, | | | |
| | Section 4.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| MAC | Using MAC-Based Protection | MAY | SHOULD | MAY |
| | for Enrollment (IR, CR, | | 1) | |
| | and P10CR if supported), | | | |
| | Section 4.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| CKeyGen | Adding Central Key Pair | MAY | MAY | MAY |
| | Generation to Enrollment | | | |
| | (IR, CR, KUR, and P10CR if | | | |
| | supported), Section 4.1.6 | | | |
+----------+-----------------------------+--------+--------+--------+
| RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD |
| | Section 4.2 | | 2) | 3) |
+----------+-----------------------------+--------+--------+--------+
| CACerts | Get CA Certificates, | MAY | MAY | MAY |
| | Section 4.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RootUpd | Get Root CA Certificate | MAY | MAY | MAY |
| | Update, Section 4.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| ReqTempl | Get Certificate Request | MAY | MAY | MAY |
| | Template, Section 4.3.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| CRLUpd | CRL Update Retrieval, | MAY | MAY | MAY |
| | Section 4.3.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| Polling | Handling Delayed Delivery, | MAY | MAY | MAY |
| | Section 4.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertResp | Responding to a | N/A | MAY | MUST |
| | Certificate Request (IR, | | | |
| | CR, KUR, and P10CR if | | | |
| | supported), Section 5.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertConf | Responding to a | N/A | MAY | MUST |
| | Confirmation Message, | | | |
| | Section 5.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevResp | Responding to a Revocation | N/A | MAY | SHOULD |
| | Request, Section 5.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| GenResp | Responding to a Support | N/A | MAY | MAY |
| | Message (CACerts, RootUpd, | | | |
| | ReqTempl, CRLUpd if | | | |
| | supported), Section 5.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| InitPoll | Initiating Delayed | N/A | MAY | MAY |
| | Delivery, Section 5.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdKeep | Forwarding Messages - Not | N/A | MUST | N/A |
| | Changing Protection, | | | |
| | Section 5.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddS | Forwarding Messages - | N/A | MUST | MUST |
| | Adding Protection to a | | | |
| | Request Message, | | | |
| | Section 5.2.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddB | Forwarding Messages - | N/A | MAY | MAY |
| | Batching Messages, | | | |
| | Section 5.2.2.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdReqKP | Forwarding Messages - Not | N/A | SHOULD | N/A |
| | Changing Proof-of- | | 1) | |
| | Possession, | | | |
| | Section 5.2.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdReqBP | Forwarding Messages - | N/A | MAY | MAY |
| | Using raVerified, | | | |
| | Section 5.2.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertROnB | Acting on Behalf of Other | N/A | MAY | N/A |
| | PKI Entities - Requesting | | | |
| | a Certificate, | | | |
| | Section 5.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevROnB | Acting on Behalf of Other | N/A | SHOULD | SHOULD |
| | PKI Entities - Revoking a | | 2) | 3) |
| | Certificate, Section 5.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+Table 3: Level of Support for PKI Management Operations and Variants
- The RA should be able to change the CMP message protection from MAC-based to signature-based protection; see Section 5.2.3.1.
- The RA should be able to request certificate revocation on behalf of an EE (see Section 5.3.2), e.g., in order to handle incidents.
- An alternative would be to perform revocation at the CA without using CMP, for instance, using a local administration interface.
7.2. Message Transfer
CMP doesn't have specific needs when it comes to message transfer, except that, for each request message sent, a sequence of one response message should eventually be received 🌸 So virtually any reliable transfer mechanism can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this document doesn't require any specific transfer protocol to be supported by conforming implementations 🙈
On different links between PKI entities (e.g., EE-RA and RA-CA), different transfer mechanisms, as specified in Section 6, may be used 🔥
HTTP SHOULD be supported and CoAP MAY be supported at all PKI entities for maximizing general interoperability at transfer level 🌈 Yet full flexibility is retained to choose whatever transfer mechanism is suitable, for instance, for devices and system architectures with specific constraints ⭐
The following table lists the name and level of support specified for each transfer mechanism.
+=========+=======================+========+========+========+
| ID | Message Transfer Type | EE | RA | CA |
+=========+=======================+========+========+========+
| HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD |
| | Section 6.1 | | | |
+---------+-----------------------+--------+--------+--------+
| CoAP | CoAP Transfer, | MAY | MAY | MAY |
| | Section 6.2 | | | |
+---------+-----------------------+--------+--------+--------+
| Piggyb | Piggybacking on Other | MAY | MAY | MAY |
| | Reliable Transfer, | | | |
| | Section 6.3 | | | |
+---------+-----------------------+--------+--------+--------+
| Offline | Offline Transfer, | MAY | MAY | MAY |
| | Section 6.4 | | | |
+---------+-----------------------+--------+--------+--------+Table 4: Level of Support for Message Transfer Types
8. IANA Considerations ✨
okay so IANA has added a bunch of new entries to the "CMP Well-Known URI Path Segments" registry 🗂️💖 (you can find it at <https://www.iana.org/assignments/cmp>), following the rules in [RFC8615]. the table below shows every path segment, what it's for, and where it's explained. it's giving organized 🎀
+====================+==========================+===============+
| Path Segment | Description | Reference |
+====================+==========================+===============+
| initialization | Enrolling an End Entity | RFC 9483, |
| | to a New PKI over HTTP | Section 4.1.1 |
+--------------------+--------------------------+---------------+
| certification | Enrolling an End Entity | RFC 9483, |
| | to a Known PKI over HTTP | Section 4.1.2 |
+--------------------+--------------------------+---------------+
| keyupdate | Updating a Valid | RFC 9483, |
| | Certificate over HTTP | Section 4.1.3 |
+--------------------+--------------------------+---------------+
| pkcs10 | Enrolling an End Entity | RFC 9483, |
| | Using a PKCS #10 Request | Section 4.1.4 |
| | over HTTP | |
+--------------------+--------------------------+---------------+
| revocation | Revoking a Certificate | RFC 9483, |
| | over HTTP | Section 4.2 |
+--------------------+--------------------------+---------------+
| getcacerts | Get CA Certificates over | RFC 9483, |
| | HTTP | Section 4.3.1 |
+--------------------+--------------------------+---------------+
| getrootupdate | Get Root CA Certificate | RFC 9483, |
| | Update over HTTP | Section 4.3.2 |
+--------------------+--------------------------+---------------+
| getcertreqtemplate | Get Certificate Request | RFC 9483, |
| | Template over HTTP | Section 4.3.3 |
+--------------------+--------------------------+---------------+
| getcrls | CRL Update Retrieval | RFC 9483, |
| | over HTTP | Section 4.3.4 |
+--------------------+--------------------------+---------------+
| nested | Batching Messages over | RFC 9483, |
| | HTTP | Section |
| | | 5.2.2.2 |
+--------------------+--------------------------+---------------+
| ir | Enrolling an End Entity | RFC 9483, |
| | to a New PKI over CoAP | Section 4.1.1 |
+--------------------+--------------------------+---------------+
| cr | Enrolling an End Entity | RFC 9483, |
| | to a Known PKI over CoAP | Section 4.1.2 |
+--------------------+--------------------------+---------------+
| kur | Updating a Valid | RFC 9483, |
| | Certificate over CoAP | Section 4.1.3 |
+--------------------+--------------------------+---------------+
| p10 | Enrolling an End Entity | RFC 9483, |
| | Using a PKCS #10 Request | Section 4.1.4 |
| | over CoAP | |
+--------------------+--------------------------+---------------+
| rr | Revoking a Certificate | RFC 9483, |
| | over CoAP | Section 4.2 |
+--------------------+--------------------------+---------------+
| crts | Get CA Certificates over | RFC 9483, |
| | CoAP | Section 4.3.1 |
+--------------------+--------------------------+---------------+
| rcu | Get Root CA Certificate | RFC 9483, |
| | Update over CoAP | Section 4.3.2 |
+--------------------+--------------------------+---------------+
| att | Get Certificate Request | RFC 9483, |
| | Template over CoAP | Section 4.3.3 |
+--------------------+--------------------------+---------------+
| crls | CRL Update Retrieval | RFC 9483, |
| | over CoAP | Section 4.3.4 |
+--------------------+--------------------------+---------------+
| nest | Batching Messages over | RFC 9483, |
| | CoAP | Section |
| | | 5.2.2.2 |
+--------------------+--------------------------+---------------+Table 5: New "CMP Well-Known URI Path Segments" Registry Entries
9. Security Considerations 🔐
okay this section is serious bestie, so listen up 💀 the security stuff from CMP [RFC4210] still applies, and so does everything updated by CMP Updates [RFC9480], CMP Algorithms [RFC9481], CRMF [RFC4211], Algorithm Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over CoAP [RFC9482]. all of that is part of the deal ✨
trust anchors for chain validation are usually handed over as self-signed certificates 🫶 and every single trust anchor MUST be stored on the device with integrity protection. no skipping this one, periodt 😭 sometimes a PKI entity doesn't have enough storage for the full certificates. in that case, it might only keep something like a hash of each self-signed certificate and expect to get the certificate in the extraCerts field, as described in Section 3.3. and if those self-signed certificates come in-band inside the messages, they MUST be verified against the trust store of the PKI entity 🛡️
⚠️ tea time: the trust store is the source of truth for anything that arrives in-band. don't just trust a certificate because it showed up in a message 💅
now for TLS with shared secret information-based authentication 🧚 PSK and PAKE both give the same amount of protection against a real-time authentication attack, and that amount is basically the entropy in the shared secret. where they differ is long-term confidentiality of the TLS messages against brute-force decryption. a PSK-based cipher suite only gives you security as strong as the entropy of the shared secret, while a PAKE-based cipher suite gives you full security no matter how much entropy the shared secret has 🌈 that's the main character difference, fr fr ✨
10. References 📚
10.1. Normative References
Here are the normative references, every single one, copied exactly as they should be 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, November 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9481] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms",
RFC 9481, DOI 10.17487/RFC9481, November 2023,
<https://www.rfc-editor.org/info/rfc9481>.
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
November 2023, <https://www.rfc-editor.org/info/rfc9482>.10.2. Informative References 📚
[BRSKI-AE]von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", Work in Progress, Internet-Draft, draft-ietf-anima-brski-ae-05, 28 June 2023,https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-05.[BRSKI-PRM]Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in Progress, Internet-Draft, draft-ietf-anima-brski-prm-10, 23 October 2023,https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-10.[ETSI-3GPP.33.310]3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 16.6.0, December 2020,http://www.3gpp.org/ftp/Specs/html-info/33310.htm.[ETSI-EN.319411-1]ETSI, "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements", V1.3.1, ETSI EN 319 411-1, May 2021,https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.03.01_60/en_31941101v010301p.pdf.[HTTP-CMP]Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", Work in Progress, Internet-Draft, draft-ietf-lamps-rfc6712bis-03, 10 February 2023,https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6712bis-03.[IEC.62443-3-3]IEC, "Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels", IEC 62443-3-3:2013, August 2013,https://webstore.iec.ch/publication/7033.[IEEE.802.1AR_2018]IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802.1AR-2018, DOI 10.1109/IEEESTD.2018.8423794, August 2018,https://ieeexplore.ieee.org/document/8423794.[NIST.CSWP.04162018]National Institute of Standards and Technology (NIST), "Framework for Improving Critical Infrastructure Cybersecurity", Version 1.1, DOI 10.6028/NIST.CSWP.04162018, April 2018,http://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf.[NIST.SP.800-57p1r5]Barker, E., "Recommendation for Key Management: Part 1 - General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,https://doi.org/10.6028/NIST.SP.800-57pt1r5.[PKIX-CMP]Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, "Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)", Work in Progress, Internet-Draft, draft-ietf-lamps-rfc4210bis-07, 19 June 2023,https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-07.[RFC3647]Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003,https://www.rfc-editor.org/info/rfc3647.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,https://www.rfc-editor.org/info/rfc5246.[RFC5753]Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010,https://www.rfc-editor.org/info/rfc5753.[RFC7030]Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013,https://www.rfc-editor.org/info/rfc7030.[RFC7252]Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,https://www.rfc-editor.org/info/rfc7252.[RFC8366]Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018,https://www.rfc-editor.org/info/rfc8366.[RFC8446]Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,https://www.rfc-editor.org/info/rfc8446.[RFC8551]Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019,https://www.rfc-editor.org/info/rfc8551.[RFC8572]Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019,https://www.rfc-editor.org/info/rfc8572.[RFC8649]Housley, R., "Hash Of Root Key Certificate Extension", RFC 8649, DOI 10.17487/RFC8649, August 2019,https://www.rfc-editor.org/info/rfc8649.[RFC8995]Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021,https://www.rfc-editor.org/info/rfc8995.[SZTP-CSR]Watsen, K., Housley, R., and S. Turner, "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Work in Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 2 March 2022,https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-14.[UNISIG.Subset-137]UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-137, V1.0.0, December 2015,https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf.
Appendix A. Example CertReqTemplate 🎀
Okay, bestie, picture this: the server wants the certTemplate to look like this 💅
- the issuer field gets a value that the EE fills in 🫶
- the subject field gets a common name that the EE fills in, plus two organizational unit fields with the values "myDept" and "myGroup" 🌸
- the publicKey field holds either an Elliptic Curve Cryptography (ECC) key on curve secp256r1 or an RSA public key of length 2048 🔑
- the subjectAltName extension has the DNS name "www.myServer.com" and an IP address that the EE fills in 🦋
- the keyUsage extension is marked critical, with the values digitalSignature and keyAgreement ✨
- the extKeyUsage extension has values that the EE fills in 🧚
So then, the infoValue with certTemplate and keySpec fields that gets sent back to the EE is encoded like this:
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
}
}
}Acknowledgements 🫶
Huge thanks to the various reviewers of this document, you were literally iconic 👑
Authors' Addresses 🦋
The three authors, all from the same crew at Siemens:
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
David von Oheimb
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com
Steffen Fries
Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: steffen.fries@siemens.com
URI: https://www.siemens.comThat's the whole document, bestie! 🌈💖
📦 where this page comes from
- ietf: rfc9483 2023-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms