RFC 6712

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

📅 published September 2012, from ietf

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

okay bestie, so this is the doc that says how to send CMP messages over HTTP 🦋 It's giving "the plumbing that makes the PKI management stuff actually travel." Here's the tea ☕

  • RFC number: 6712
  • Category: Standards Track (so it's an actual Internet standard, not just vibes) 👑
  • Date: September 2012
  • ISSN: 2070-1721
  • Authors: T. Kause (SSH) and M. Peylo (NSN)
  • Updates: RFC 4210 🌸 This one's the big one. It fixes the reference to "CMPtrans" that RFC 4210 points at.
  • Obsoletes: nothing listed in the header, so it doesn't replace anything 🙈

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's the "CMPtrans" document that RFC 4210 references, which means this doc updates that reference.

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🌈

the current status, any errata, and how to give feedback are all at http://www.rfc-editor.org/info/rfc6712

Copyright (c) 2012 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, which you can read at http://trustee.ietf.org/license-info (as in effect on the publication date). Please actually read those, bestie, because they explain your rights and restrictions. Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in that license 🫶

this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents 🗺️

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................3
   3. HTTP-Based Protocol .............................................3
      3.1. HTTP Versions ..............................................4
      3.2. Persistent Connections .....................................4
      3.3. General Form ...............................................4
      3.4. Media Type .................................................4
      3.5. Communication Workflow .....................................5
      3.6. HTTP Request-URI ...........................................5
      3.7. Pushing of Announcements ...................................5
      3.8. HTTP Considerations ........................................6
   4. Implementation Considerations ...................................7
   5. Security Considerations .........................................7
   6. IANA Considerations .............................................8
   7. Acknowledgments .................................................8
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References .....................................9

1. Introduction 🌸

okay so CMP ([RFC4210]) needs a well-defined transfer mechanism so End Entities (EEs), Registration Authorities (RAs), and Certification Authorities (CAs) can pass PKIMessage sequences between each other 🦋

the first CMP spec ([RFC2510]) had a brief description of a simple transfer protocol sitting on top of TCP. It had basic transfer-level error handling and a way to poll for outstanding PKI messages. It also said PKI messages could travel over file, E-mail, and HTTP transfer, but those weren't specified in detail 🙈

then the current CMP spec ([RFC4210]) built in its own polling mechanism, so the need for a transfer protocol just for polling vanished 💀 What CMP still needs from its transfer protocols is connection and error handling ✨

the draft went through some drastic changes before it became an RFC 😭 The so-called "Direct TCP-Based Management Protocol" from [RFC2510] got enhanced, and at one point it was sent over HTTP again. Both approaches turned out to be needless and cumbersome, so implementers just wanted plain HTTP transfer following [RFC1945] or [RFC2616]. This document reflects that by describing HTTP exclusively as the transfer protocol for CMP 👑

the way CMP uses HTTP is that it only uses the POST method for requests, which basically tunnels CMP over HTTP. Honestly, this is generally considered bad practice and shouldn't be copied, but there are good reasons to do it for CMP anyway 💅 HTTP is generally easy to implement, it can traverse network borders using ubiquitous proxies, and most importantly, it's already commonly used in existing CMP implementations. Other request methods like GET aren't used, because PKI management operations can only be triggered by CMP's PKI messages, and those have to be sent in a POST request 🎀

HTTP's status codes give it the error reporting CMP needs. General problems on the server side, and problems directly caused by a specific request, can both be reported back to the client 🫶

lastly, CMP has a transaction ID that identifies transactions spanning more than one request/response pair. So even though HTTP is stateless, that doesn't block it from being the transfer protocol for CMP messages 🧚

2. Conventions Used in This Document 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥

3. HTTP-Based Protocol 🌈

for direct interaction between two entities, where a reliable transport protocol like TCP is available, HTTP SHOULD be used for conveying CMP messages ✨

3.1. HTTP Versions 🍓

implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1 [RFC2616] 💜

3.2. Persistent Connections 🔁

HTTP persistent connections [RFC2616] let multiple interactions happen on the same HTTP connection. BUT, neither HTTP nor the protocol in this doc is designed to correlate messages on the same connection in any meaningful way. Persistent connections are only a performance optimization 🙈

intermediaries can do things like mix connections from different clients into one "upstream" connection, terminate persistent connections, and forward requests as non-persistent requests, etc. Because of this, implementations MUST NOT infer that requests on the same connection come from the same client (for example, when correlating PKI messages with ongoing transactions). Every message is to be evaluated in isolation 🚫

3.3. General Form 🎀

a DER-encoded [ITU.X690.1994] PKIMessage [RFC4210] is sent as the entity-body of an HTTP POST request. If that HTTP request succeeds, the server returns the CMP response in the body of the HTTP response 💌

the HTTP response status code in this case MUST be 200. Other "Successful 2xx" codes MUST NOT be used for this purpose 🚫

HTTP responses to pushed CMP Announcement messages (CA Certificate Announcement, Certificate Announcement, Revocation Announcement, and Certificate Revocation List (CRL) Announcement) use the status codes 201 and 202 to show whether the received information was processed 🧾

"Redirection 3xx" status codes MAY be supported by implementations, but clients should only be enabled to automatically follow them after careful consideration of possible security implications. As described in Section 5, "301 Moved Permanently" could be misused for permanent denial of service 😭

all applicable "Client Error 4xx" or "Server Error 5xx" status codes MAY be used to tell the client about errors 💀

3.4. Media Type 💫

the Internet Media Type "application/pkixcmp" MUST be set in the HTTP Content-Type header field when conveying a PKIMessage 🏷️

Content-Type: application/pkixcmp

3.5. 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.7 are the exception. Their creation may be triggered by certain events, or a CA may do it on a regular basis. The recipient of an Announcement only replies with an HTTP status code acknowledging receipt or indicating an error, NOT with a CMP response 🙅‍♀️

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

3.6. HTTP Request-URI 🌐

the Request-URI is formed as specified in [RFC3986] 🔗

a server implementation MUST handle Request-URI paths, with or without a trailing slash, as identical 🫶

here's an example of a Request-Line and a Host header field in an HTTP/1.1 header, sending a CMP request to a server at the "/cmp" path of the host "example.com":

   POST /cmp HTTP/1.1
   Host: example.com

or in the absoluteURI form:

   POST http://example.com/cmp/ HTTP/1.1
   Host: example.com

Part 1 of 2 ✨ Part 2 picks up at Section 3.7 (Pushing of Announcements) 💖

3.7. Pushing of Announcements 📣

A CMP server can make event-triggered announcements or generate them on a regular basis 🗓️. It MAY use HTTP transfer to deliver them to a suitable recipient 🦋. In this case the CMP server acts as the HTTP client, and the recipient needs an HTTP server running 🖥️. Since there are no request messages defined for these announcements, they can only be pushed to the recipient 💌.

If an EE wants to poll for a potential CA Key Update Announcement or the current CRL, it can send a PKI Information Request as a General Message, as described in Appendix E.5 of [RFC4210] 🔍.

When pushing Announcement messages, PKIMessage structures go in the entity-body 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 defined in Section 3.6 👂.

The following PKIMessages are announcements a CA may push. The prefixed numbers reflect the ASN.1 numbering of each element 🔢:

[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 an empty body 🫶. If that response never shows up, it MUST be assumed that the delivery was not successful 💀. If it makes sense, the sending side MAY try sending the Announcement again after waiting an appropriate amount of time 🔁.

If the announced issue was successfully stored in a database, or was already there, the answer MUST be an HTTP response with a "201 Created" status code and an empty message body ✅.

If 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 keep repeating that until it gets a confirmation that the announcement was processed successfully 🔄. The appropriate length of the delay, and whether to increase it between attempts, should be carefully considered 🧠.

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

3.8. HTTP Considerations 🎀

Every defined HTTP feature is available to implementations, but they SHOULD keep the protocol usage as simple as possible 🧼. For example, there is no benefit to using chunked Transfer-Encoding, because the length of an ASN.1 sequence is known before you start sending it 📏.

Clients don't need to send an "Expect" request-header field with the "100-continue" expectation and then wait for a "100 Continue" status, as described in Section 8.2.3 of [RFC2616] 🙈. The CMP payload a client sends is pretty small, so swapping extra messages back and forth is inefficient 😤. The server will only rarely reject a message without evaluating the body 💅.

4. Implementation Considerations ✨

Implementors should know that some implementations might transfer CMP over HTTP in a different way 🌍. This document has been in development for more than a decade, so that's kind of expected 🕰️. Also, implementations based on earlier drafts of this document might use an unregistered "application/pkixcmp-poll" MIME type 👀.

5. Security Considerations 🔐

The following aspects need to be considered by implementers and users 🫣:

  1. There's a risk of denial-of-service attacks through resource consumption, since someone can open lots of connections to an HTTP server 💀. So idle connections should be terminated after an appropriate timeout, which may also depend on how many free resources are available 🧹. After sending a CMP Error Message, the server should close the connection, even if the CMP transaction isn't fully completed yet 🚪.
  2. Without effective security protocols wrapping it, like Transport Layer Security (TLS) [RFC5246], there's no integrity protection at the HTTP protocol level 😩. So information from the HTTP protocol should not be used to change the state of the transaction 🙅‍♀️.
  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 man-in-the-middle attacker, who could try to block them permanently from reaching the correct server 👹. Big yikes 😭.
  4. If there are no measures in place 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 should not depend on Announcements being reliably received and processed by their destination 🏗️.
  5. CMP provides built-in integrity protection and authentication 🛡️. The information communicated unencrypted in CMP messages doesn't contain sensitive info that would endanger the PKI if intercepted 🙆‍♀️. However, an eavesdropper might use the available information to gather confidential technical or business-critical info 🕵️‍♀️. So users of HTTP transfer for CMP might want to consider HTTP over TLS according to [RFC2818], or virtual private networks created by, for example, Internet Protocol Security according to [RFC4301] 🔒. Compliant implementations MUST support TLS, with the option to authenticate both server and client 🫶.

6. IANA Considerations 📋

The IANA has already registered the MIME media type application/pkixcmp for identifying CMP sequences, due to an request made in connection with [RFC2510] 🎉.

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

7. Acknowledgments 💖

Amit Kapoor and Ronald Tschlaer were the original authors of this document 🥹. Their version focused on the so-called "TCP-Based Management Protocol", which has since been removed from this document 👋. Their contact data, as they originally stated it, is below 📇:

   Amit Kapoor
   Certicom
   25801 Industrial Blvd
   Hayward, CA
   US
   Email: amit@trustpoint.com

   Ronald Tschalaer
   Certicom
   25801 Industrial Blvd
   Hayward, CA
   US
   Email: ronald@trustpoint.com

The authors gratefully acknowledge the contributions of various members of the IETF PKIX working group and the ICSA CA-talk mailing list (a list solely devoted to discussing CMP interoperability efforts) 🙌.

The following people, listed alphabetically, have also made significant contributions to this document by sharing ideas, giving hints, and doing invaluable review work 🌟:

   Tomas Gustavsson, Primekey
   Peter Gutmann, University of Auckland
   Wolf-Dietrich Moeller, Nokia Siemens Networks

8. References 📚

8.1. Normative References

  • [ITU.X690.1994] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
  • [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.

8.2. Informative References

  • [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Authors' Addresses 🦋

   Tomi Kause
   SSH Communications Security
   Takomotie 8
   Helsinki  00380
   Finland

   EMail: toka@ssh.com


   Martin Peylo
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   EMail: martin.peylo@nsn.com
📦 where this page comes from