Summary

  • RFC 10003 defines ways to carry a CMC request or response; it does not decide who is entitled to approve, alter or issue a certificate.
  • A file, a 2XX response or a reachable TCP service records a bounded transport event. Authority, policy and certificate outcome require separate evidence.

The seductive error in certificate operations is to read a successful journey as a successful decision. A request appears as a file, crosses a mail route, receives an HTTP success response, or comes back across a TCP connection. Each event is observable. None, by itself, says that the receiving system was the certificate authority, that an operator had authority to act, or that the request satisfied the applicable issuance policy.

RFC 10003 is valuable precisely because it makes the lower layer clear. It updates the CMC transport rules for file, mail, HTTP and TCP, replacing older transport specifications. A file carries one binary CMC request or one binary CMC response. HTTP uses a client POST and treats a 2XX status as successful transport handling. TCP carries the binary messages directly and requires a client to receive a complete response before it sends the next request on that connection. These are excellent facts for an incident record: which bytes were presented, through what carrier, and what the carrier returned.

They are not a certificate-decision record. The standard does not make a 2XX response an issuance verdict. It does not make possession of a CMC file evidence of an approved identity. It does not make a TCP endpoint the legal or organisational principal behind a certificate. The response can say much more, but the fact that a response arrived says only that the prescribed exchange reached that stage.

That distinction matters most when a control room wants to compress a chain of evidence. “The CMC service accepted it” can be a useful operational sentence if it means the HTTP exchange completed. It becomes misleading if it is used to skip the questions that remain local: which CA or registration authority was responsible, which controls permitted the transaction, whether the requested change was authorised, and whether a certificate was ultimately issued and delivered to the relying workflow.

The protocol also provides warnings against over-reading a transport boundary. It says HTTP authentication and cookies are not required by the CMC HTTP binding. In TLS 1.3 or QUIC deployments, it prohibits 0-RTT for CMC HTTP requests because POST is not idempotent. It notes that replay defences can be necessary for a particular environment. Those are transport and deployment facts. They do not supply a universal identity proof or a general-purpose authority model.

Mail makes the same point more sharply. RFC 10003 describes how a CMC object can be wrapped for transport, while cautioning that TLS protection at the first SMTP hop does not establish authentication or encryption for later hops. CMS or S/MIME protection can preserve confidential contents, but confidentiality of a payload is still different from the decision rights of the party that processes it. A protected envelope is evidence about protection; it is not a portable mandate.

The practical discipline is to keep two ledgers. The transport ledger records the object, carrier, time, response and integrity properties. The decision ledger records the local principal, policy path, approval or rejection, issuance result and the evidence required by the relevant institution. RFC 10003 strengthens the first ledger. It deliberately does not collapse the second into it.