RFC 5273

Certificate Management over CMS (CMC): Transport Protocols 🎀

Okay bestie, here's the title block tea ☕

• RFC: 5273, from the Network Working Group
• Authors: J. Schaad of Soaring Hawk Consulting, and M. Myers of TraceRoute Security, Inc.
• Category: Standards Track
• Date: June 2008
• Obsoletes and updates: none listed in the title block

---

Abstract ✨

So this doc is all about the transport mechanisms that actually move CMC messages around. CMC stands for Certificate Management over CMS (Cryptographic Message Syntax) 💅 There are four flavours: HTTP, file, mail, and TCP.

Status of This Memo 📜

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) doc. Distribution of this memo is unlimited 🌈

1. Overview 🦋

Okay so this section says there are a bunch of transport methods for moving CMC messages (defined in [CMC-STRUCT]). Same four as before: HTTP, file, mail, and TCP.

Now the important bit 👑 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 [MUST].

2. File-Based Protocol 📁

Enrollment messages and responses can be moved between clients and servers using file-system mechanisms. This is useful when enrollment is happening for an off-line client 🌸 When files are carrying binary Full PKI Request or Full PKI Response messages, there MUST be only one instance of a request or response message in a single file. The following file type extensions SHOULD be used:

                 +---------------------+----------------+
                 | Message Type        | File Extension |
                 +---------------------+----------------+
                 | Simple PKI Request  | .p10           |
                 | Full PKI Request    | .crq           |
                 | Simple PKI Response | .p7c           |
                 | Full PKI Response   | .crp           |
                 +---------------------+----------------+

                 File PKI Request/Response Identification

3. Mail-Based Protocol 💌

MIME wrapping is defined for environments that are MIME native 🪄 The basic MIME wrapping in this section comes from [SMIMEV3]. When you're using a mail-based protocol, MIME wrapping between the layers of CMS wrapping is optional. Note that this is different from the standard S/MIME (Secure MIME) message.

Simple enrollment requests are encoded using the "application/pkcs10" content type. A file name MUST be included either in a content-type or a content-disposition statement. The extension for the file MUST be ".p10".

Simple enrollment response messages MUST be encoded as content type "application/pkcs7-mime". An smime-type parameter MUST be on the content-type statement with a value of "certs-only". A file name with the ".p7c" extension MUST be specified as part of the content-type or content-disposition statement.

Full enrollment request messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-Request". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.

Full enrollment response messages MUST be encoded as content type "application/pkcs7-mime". The smime-type parameter MUST be included with a value of "CMC-response". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.

Here's the cheat sheet, Table 1 🍓

   +--------------+------------------------+------------+--------------+
   | Item         | MIME Type              | File       | SMIME Type   |
   |              |                        | Extension  |              |
   +--------------+------------------------+------------+--------------+
   | Simple PKI   | application/pkcs10     | .p10       | N/A          |
   | Request      |                        |            |              |
   | Full PKI     | application/pkcs7-mime | .p7m       | CMC-request  |
   | Request      |                        |            |              |
   | Simple PKI   | application/pkcs7-mime | .p7c       | certs-only   |
   | Response     |                        |            |              |
   | Full PKI     | application/pkcs7-mime | .p7m       | CMC-response |
   | Response     |                        |            |              |
   +--------------+------------------------+------------+--------------+

             Table 1: MIME PKI Request/Response Identification

4. HTTP/HTTPS-Based Protocol 🌐

This section is all about how HTTP [HTTP] works as a transport layer. In most circumstances, HTTP over TLS [TLS] gives you any content protection you need from eavesdroppers 🕵️‍♀️

For CMC clients and servers using HTTP to interoperate, these rules apply:

• Clients MUST use the POST method to submit their requests.
• Servers MUST use the 200 response code for successful responses.
• Clients MAY attempt to send HTTP requests using TLS 1.0 [TLS] or later, although servers are not required to support TLS.
• Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
• Clients and servers are expected to follow the other rules and restrictions in [HTTP]. Note that some of those rules are for HTTP methods other than POST. Clearly, only the rules that apply to POST are relevant for this specification.

4.1. PKI Request 📤

A PKI Request using the POST method is built like this:

• The Content-Type header MUST have the appropriate value from Table 1.
• The body of the message is the binary value of the encoding of the PKI Request.

4.2. PKI Response 📥

An HTTP-based PKI Response is made of the appropriate HTTP headers, followed by the binary value of the BER (Basic Encoding Rules) encoding of either a Simple or Full PKI Response.

The Content-Type header MUST have the appropriate value from Table 1.

5. TCP-Based Protocol 🔌

When CMC messages travel over a TCP-based connection, there's no wrapping needed around the message 💖 They're sent in their binary encoded form.

The client closes the connection after receiving a response, or it sends another request to the server over the same connection. Reusing one connection for multiple successive requests is RECOMMENDED for performance and resource conservation reasons. Opening a fresh connection for every single request is not the move 🙅‍♀️ A server MAY close a connection after it has been idle for some period of time, and that timeout would typically be several minutes long.

There isn't one specific port for TCP-based transport 🧚 Only the Private Ports 49152-65535 may be used in this manner (without registration). The ports in the range of 1-49151 SHOULD NOT be used. The port to be used is configured out of band.

6. Security Considerations 🔐

Bestie, this section is serious business. Read every word 😭

Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol, depending on the operational environment. In cases where the Certification Authority (CA) maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in Section 6.6 of [CMC-STRUCT]. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.

Starting a secure communications channel between an end-entity and a CA or Registration Authority (RA) (and, similarly, between an RA and another RA or CA) necessarily requires an out-of-band trust initiation mechanism 🫣 For example, a secure channel may be constructed between the end-entity and the CA via IPsec [IPsec] or TLS [TLS]. There are many such schemes, and choosing any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability into an overall security architecture.

In some instances, no prior out-of-band trust will have been initiated before this protocol is used. This can happen when the protocol itself is being used to download onto the system the set of trust anchors to be used for these protocols. In these instances, the Enveloped Data content type (Section 3.2.1.3.3 in [CMC-STRUCT]) must be used to provide the same shrouding that TLS would have provided. 🎀

Intellectual Property ✨

okay so bestie, this part is all about who owns what 💅 The IETF is basically saying "we are NOT picking a side on whether any patents or IP rights are valid or how far they reach 🙈" and it also isn't claiming it went digging to find every single right out there. So if someone says they own a piece of the tech in this doc, the IETF isn't vouching for them, and whether you can get a license is a whole separate question. If you want the rules on how all this works for RFC docs, you check out BCP 78 and BCP 79, iykyk 🎀

Next up, copies of IPR disclosures that get sent to the IETF Secretariat are a thing you can actually look up 🧚 Same goes for any promises to license the tech, or what happens when someone tries to get a general license or permission to use the proprietary stuff. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr ✨ Super convenient, no cap.

And last but NOT least, the IETF is literally begging anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard to speak up 📣 Send that info to the IETF at ietf-ipr@ietf.org 💖 The whole vibe is "tell us so we can handle it right," and honestly that's so iconic of them 👑