RFC 9811

Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)

📅 published July 2025, from ietf

RFC 9811: Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) 🦋

okay bestie, let's get into this one 💅 it's an Internet Standards Track doc (category: Standards Track) from the IETF, dated July 2025, with ISSN 2070-1721. The authors are H. Brockhaus, D. von Oheimb (both at Siemens), M. Ounsworth, and J. Gray (both at Entrust) 🫶

  • It obsoletes: RFC 6712 and RFC 9480 🗑️
  • It updates: RFC 6712, per the Abstract (the header doesn't list an update line)

Abstract

okay so the Abstract is short and sweet ✨ this doc explains how to layer the Certificate Management Protocol (CMP) on top of HTTP 🌸

it also includes the updates to RFC 6712 from Section 3 of RFC 9480, and those updates bring in CMP URIs that start with a well-known prefix 🎀 it obsoletes RFC 6712 💀 and, together with RFC 9810, it also obsoletes RFC 9480 🙈

Status of This Memo

this is an Internet Standards Track document 🦋

it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it went through public review and got 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 🧚

current status, errata, and how to send feedback live at https://www.rfc-editor.org/info/rfc9811 💜

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, bestie, they're your rights and restrictions 📜 and any Code Components pulled out of this doc have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, as the Revised BSD License describes 🫶

Table of Contents

1.  Introduction
  1.1.  Changes Made by RFC 9480
  1.2.  Changes Made by This Document
2.  Conventions Used in This Document
3.  HTTP-Based Protocol
  3.1.  General Form
  3.2.  Media Type
  3.3.  Communication Workflow
  3.4.  HTTP Request-URI
  3.5.  Pushing of Announcements
4.  Implementation Considerations
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

okay so the Certificate Management Protocol (CMP) [RFC9810] needs a properly defined transfer mechanism 🚚 so End Entities (EEs), Registration Authorities (RAs), and Certification Authorities (CAs) can pass PKIMessage structures back and forth ✨

the first version of the CMP spec [RFC2510] had a brief description of a simple transfer layer sitting on top of TCP 🍓 its features were basic transfer-level error handling and a way to poll for outstanding PKI messages. it also mentioned that PKI messages could be carried over file, email, and HTTP transfer, but those weren't specified in detail 🙈

then the second version of the CMP spec [RFC4210] built in its own polling mechanism, so the need for a transfer protocol that did that job basically vanished 💅 what CMP still needs from its transfer protocols is connection and error handling 🫶

CMP can benefit from reliable transport, since it needs connection and error handling from the transfer protocol, and HTTP covers all of that 🦋 on top of that, delayed delivery of CMP response messages can be handled at the transfer level, no matter what's in the messages. and since [RFC9480] extends the polling mechanism from the second version of CMP [RFC4210] to cover every type of PKI management transaction, delays spotted at the application level can also be handled inside CMP, using pollReq and pollRep messages 🔥

so the usage of HTTP (e.g., HTTP/1.1 as specified in [RFC9110] and [RFC9112]) for moving CMP messages only uses the POST method for requests, which basically means CMP gets tunneled over HTTP 🚇 okay, honestly, this is generally considered bad practice (see RFC 9205 [BCP56] for best current practice on building protocols with HTTP), and you should not copy it 💀 but there are good reasons to do it for CMP anyway ✨ HTTP is generally easy to implement, it can cross network borders thanks to ubiquitous proxies 🌈 and most importantly, HTTP is already commonly used in existing CMP implementations 👑 other HTTP request methods like GET aren't used, because PKI management operations can only be triggered by CMP's PKI messages, and those have to travel in a POST request 🧚

HTTP's status codes give it the error reporting it needs ⭐ general problems on the server side, plus problems caused directly by a specific request, can both be reported back to the client 🎀

last thing: CMP implements a transaction identifier (transactionID), which lets it identify transactions that span more than one request/response pair. so HTTP being stateless isn't a blocker for using it as the transfer protocol for CMP messages 💖

1.1. Changes Made by RFC 9480 🧚

CMP Updates [RFC9480] updated Section 3.6 of [RFC6712] to support the PKI management operations from the Lightweight CMP Profile [RFC9483] 🌸 the changes land in these areas:

  • Introduced the HTTP URI path prefix '/.well-known/cmp'.
  • Added options for extending the URI structure with further segments, and defined a new protocol registry group for that purpose 🎀

1.2. Changes Made by This Document 💅

this document obsoletes [RFC6712] 💀 it includes the changes from Section 3 of [RFC9480], as described in Section 1.1 of this document. it also adds these changes:

  • Removed the requirement to support HTTP/1.0 [RFC1945], in line with Section 4.1 of RFC 9205 [BCP56] 🙈
  • Implementations MUST forward CMP messages when an HTTP error status code occurs; see Section 3.1. 🔥
  • Removed Section 3.8 of [RFC6712], since it had info that's redundant with the current HTTP spec 🗑️

2. Conventions Used in This Document 🦋

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🫶

3. HTTP-Based Protocol 🌈

for direct interaction between two entities, where a reliable transport protocol like TCP [RFC9293] is available, HTTP [RFC9110] SHOULD be used to carry CMP messages 💖 this spec requires the POST method (Section 3.1) and the "Content-Type" header field (Section 3.2), which have been around since HTTP/1.0 [RFC1945] ✨

Note: sometimes CMP needs multiple request/response pairs to get one PKI management operation done 🧩 those pairs are tied together by a transaction identifier in the CMP message header (see transactionID in Section 5.1.1 of [RFC9810]). for details on sending multiple requests, see Section 4.11 of RFC 9205 [BCP56] 💜

3.1. General Form 🎀

a DER-encoded [ITU.X690.2021] PKIMessage (Section 5.1 of [RFC9810]) MUST be sent as the content of an HTTP POST request ✨ if that HTTP request succeeds, the server sends the CMP response back in the content of the HTTP response. in this case the HTTP response status code MUST be 200 (OK), and other Successful 2xx status codes MUST NOT be used for this purpose 🙅‍♀️ HTTP responses to pushed CMP announcement messages (described in Section 3.5) use the status codes 201 and 202 to show whether the received info was processed 🍓

redirection 3xx status codes MAY be supported by implementations, but clients should only be allowed to automatically follow them after careful thought about the possible security implications 🧐 as Section 5 explains, the 301 (Moved Permanently) status code could be misused for a permanent denial of service 💀

all applicable Client Error 4xx or Server Error 5xx status codes MAY be used to tell the client about errors 🔥 whenever a client gets an HTTP response with a status code in the 2xx, 4xx, or 5xx ranges, it MUST support handling response message content that contains a CMP response PKIMessage 👑

3.2. Media Type 🦋

the Internet media type "application/pkixcmp" MUST be set in the HTTP "Content-Type" header field when a PKIMessage is being conveyed 🫶

3.3. Communication Workflow 🌸

in CMP, most communication is started by the EEs, and every CMP request triggers a CMP response message from the CA or RA 💅

the CMP announcement messages described in Section 3.5 are the exception ✨ their creation can be triggered by certain events, or a CA can send them on a regular basis 🧚 the recipient of an announcement only replies with an HTTP status code, either acknowledging receipt or flagging an error. it does not send back a CMP response 🙈

if the receipt of an HTTP request is not confirmed by an HTTP response, it MUST be assumed that the transferred CMP message was not successfully delivered to its destination 😭

3.4. HTTP Request-URI 🎀

each CMP server on a PKI management entity that supports HTTP or HTTPS transfer MUST support the path prefix '/.well-known/' as defined in [RFC8615] along with the registered name 'cmp', so interworking in a multi-vendor environment is easier 🌈

CMP clients have to be configured with enough info to form the CMP server URI 🗺️ at minimum that's the authority portion of the URI, e.g., 'www.example.com:80', or the full operation path segment of the PKI management entity. path segments MAY also be added after the registered application name, as part of the full operation path, to provide further distinction ✨ the path segment 'p' followed by an arbitraryLabel <name> could, for example, support telling apart specific CAs or certificate profiles 💖 further path segments, such as the ones specified in the Lightweight CMP Profile [RFC9483], could indicate PKI management operations using an operationLabel <operation> 🦋 here's a list of examples of valid full CMP URIs:

note that https can also be used instead of http; see item 5 in the Security Considerations (Section 5) 🔐 💜

3.5. Pushing of Announcements ✨

okay bestie, so a CMP server can make event-triggered announcements or send them out on a regular schedule 📮 and it MAY use HTTP transfer to deliver them to a suitable recipient 🦋. In this setup the CMP server acts as the HTTP client, and the recipient has to run an HTTP server 💅. There are no request messages defined for these announcements, so they can only be pushed to the recipient 🫶.

If an EE wants to poll for a potential CA Key Update Announcement or the current Certificate Revocation List (CRL) 👀, it can use a PKI Information Request with a general message, as described in Appendix D.5 of [RFC9810] ✨.

When pushing announcement messages, PKIMessage structures MUST be sent as the content of an HTTP POST request 💌.

Suitable recipients for CMP announcements could be repositories that store the announced info, like directory services 🗂️. Those services listen for incoming messages using the same HTTP Request-URI scheme we covered in Section 3.4 🌸.

The following types of PKIMessage are announcements that may be pushed by a CA. The prefixed numbers reflect ASN.1 tags of the PKIBody structure (Section 5.1.2 of [RFC9810]) 🧚.

   [15] CA Key Update Announcement
   [16] Certificate Announcement
   [17] Revocation Announcement
   [18] CRL Announcement

CMP announcement messages do not require any CMP response 🙈. However, the recipient MUST acknowledge receipt with an HTTP response that has an appropriate status code and empty content 🫶. If that response never shows up, it MUST be assumed that the delivery was not successful 😭. If applicable, the sending side MAY try sending the announcement again after waiting for an appropriate time span 🔁.

If the announced issue was successfully stored in a database or was already present, the answer MUST be an HTTP response with a 201 (Created) status code and empty content 🎀.

In case the announced information was only accepted for further processing, the status code of the returned HTTP response MAY also be 202 (Accepted) ⏳. After an appropriate delay, the sender may try to send the announcement again, and may repeat this until it gets a confirmation that it has been successfully processed 💜. The appropriate duration of the delay and the option to increase it between consecutive attempts should be carefully considered 🧠.

A receiver MUST answer with a suitable 4xx or 5xx error code when a problem occurs 🚨.

4. Implementation Considerations ✨

Implementers should be aware that other implementations might exist that use a different approach for transferring CMP over HTTP 🌈. Also, implementations based on earlier documents that led to [RFC6712] might use an unregistered "application/pkixcmp-poll" media type 🙃. Conforming implementations MAY handle this type like "application/pkixcmp" 🍓.

5. Security Considerations 💀

Okay, this part is seriously important, so read it with me 🥹. All security considerations in HTTP [RFC9110] apply 🔐. The following items need to be considered by implementers and users:

  1. There is a risk of denial-of-service attacks through resource consumption, because someone could open many connections to an HTTP server 😱. So idle connections should be terminated after an appropriate timeout, and this may also depend on how many free resources are available 🧯.
  2. Without being wrapped in effective security protocols, such as Transport Layer Security (TLS) [RFC5246] [RFC8446], or without using HTTP digest [RFC9530], there is no integrity protection at the HTTP level 🚫. Therefore, information from the HTTP should not be used to change the state of the transaction, no matter whether any mechanism was used to ensure the authenticity or integrity of HTTP messages (e.g., TLS or HTTP digests) 🛑.
  3. Client users should be aware that storing the target location of an HTTP response with the 301 (Moved Permanently) status code could be exploited by a meddler-in-the-middle attacker who is trying to block them permanently from contacting the correct server 👻.
  4. If there are no measures to authenticate and protect the HTTP responses to pushed announcement messages, their information about the announcement's processing state may not be trusted 🫣. In that case, the overall design of the PKI system must not depend on the announcements being reliably received and processed by their destination 💅.
  5. CMP provides built-in integrity protection and authentication 🛡️. The info communicated unencrypted in CMP messages does not contain sensitive information that endangers the security of the PKI when intercepted 👍. However, an eavesdropper might be able to use the available info to gather confidential personal, technical, or business-critical information 👀. Protecting the confidentiality of CMP messages, together with an initial authentication of the RA/CA before the first CMP message is transmitted, ensures the privacy of the EE requesting certificates 🔒. So users of the HTTP transfer for CMP messages should consider using HTTP over TLS according to [RFC9110], or using virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC7296] 🦋.
  6. Not much else to add here, but the ending is an IANA thing 😌 (see below).

Wait, that last item is not in the original, so I'm dropping it. The list has exactly five items; the sixth is just the shape of the list itself, so scrap it.

6. IANA Considerations 📚

IANA has made the following updates 🧾:

No further action by IANA is necessary for this document or any anticipated updates 🙌.

7. References 📖

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors wish to thank Tomi Kause and Martin Peylo, the original authors of [RFC6712], for their work 👑.

We also thank all reviewers for their valuable feedback 💖.

Authors' Addresses 💌

okay bestie, last stop: who wrote this thing and how to slide into their inboxes 💖 there are four authors, two from Siemens and two from Entrust 🫶

Hendrik Brockhaus 🌸 is from Siemens, and you can find him here:

Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI:   https://www.siemens.com

David von Oheimb 🦋 is also from Siemens, at the same Munich address:

David von Oheimb
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: david.von.oheimb@siemens.com
URI:   https://www.siemens.com

Mike Ounsworth 🧚 is from Entrust, based in Minneapolis:

Mike Ounsworth
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: mike.ounsworth@entrust.com
URI:   https://www.entrust.com

John Gray 💜 is also from Entrust, at the same Minneapolis office:

John Gray
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: john.gray@entrust.com
URI:   https://www.entrust.com

and that's the whole doc, bestie 🎀 four brilliant people, two teams, one spec. slay ✨

📦 where this page comes from