Summary

  • RFC 10003 standardizes HTTP, file, mail and TCP carriers for CMC. A transport outcome says what happened to an envelope on one carrier; the CMC response says whether the requested operation succeeded, failed, remains pending or is only partial.
  • HTTP 2XX, accepted mail, a present file or completed TCP write must not be promoted into evidence that a CA or RA granted the request, issued the intended certificate, or that a system installed and used it.
  • Daniel Kade proposes a CMC transport-to-decision receipt that correlates bounded carrier evidence with the parsed PKI response, transaction state, issued-certificate fingerprint and deployment confirmation without retaining enrollment secrets or message bodies.

The courier is not the decision-maker

Imagine an enrollment client sends a Full PKI Request over HTTPS. The server returns HTTP 200 and a correctly typed body. The transport monitor turns green. A workflow then marks the certificate request “issued,” because the exchange completed without a network error.

That conclusion skips the most important document in the exchange: the CMC response itself.

RFC 10003 defines how CMC messages move. It standardizes four transport methods—HTTP, file, mail and TCP—and specifies their wrappers, media types and sequencing rules. RFC 10004 makes HTTP mandatory to implement for CMC entities, while the other transports remain optional. Those choices establish interoperable carriers. They do not merge the carrier's outcome with the certification authority's decision.

RFC 10002 defines that second layer. A Full PKI Response can report success, failure, pending work, lack of support, a requirement for certificate confirmation, a further proof-of-possession operation, or a partial result. Delayed issuance can require more than one round trip. The response is therefore not decorative content attached to a successful delivery; it is where the application protocol states what happened.

The practical lesson is narrow and consequential: a courier can deliver a sealed envelope without deciding what the institution inside will do with it.

HTTP success has a deliberately limited meaning

RFC 10003 requires HTTP clients to use POST and servers to use 2XX response codes for successful responses. It also defines the body and Content-Type values. A Full PKI Request uses application/pkcs7-mime with smime-type=CMC-Request; the Full PKI Response uses smime-type=CMC-Response. Simple requests and responses have their own identifiers.

These requirements make an HTTP exchange testable. An operator can observe the destination URI, method, timestamp, status code, media type and a hash of the returned bytes. That is valuable evidence. It can show that a particular endpoint accepted a request and produced a response under the HTTP protocol.

It cannot, on its own, show that the contained certification operation was granted. A 2XX response may carry a Full PKI Response whose status is failed or pending. Conversely, a non-2XX result may mean that routing, authentication, media-type handling or an intermediary failed before the CMC server made any PKI decision. Treating every non-2XX as a CA rejection would be as misleading as treating every 2XX as issuance.

This is not an eccentric edge case. RFC 10002 explicitly reserves Full PKI Responses for successful enrollment with additional information, pending enrollment and failed enrollment. The protocol needs both layers because transport execution and PKI adjudication are different events.

Pending is a state, not a slow success

Automation tends to be impatient with intermediate states. A request is submitted; a response arrives; the workflow wants a binary answer. CMC refuses that simplification.

For pending or partial results, PendInfo carries a token and a suggested time for the client to query again. The requester is responsible for polling. A transaction identifier, when used, is retained until a Full PKI Response completes the transaction. These are not signs that issuance “basically succeeded.” They are instructions for continuing a still-open protocol state.

That distinction changes how evidence should be stored. A pending response must not overwrite the fact that no final certificate decision yet exists. A later poll must be linked to the same transaction without pretending it was the same transport exchange. If the client loses its pending token, misses the allowed window or receives only part of a batch, the record should expose the gap rather than infer completion from the earlier HTTP receipt.

Retries create another risk. POST is not idempotent, which is why RFC 10003 forbids 0-RTT early data for CMC implementations using TLS 1.3 or QUIC. A lost response can tempt a client to resubmit. Without transaction and nonce correlation, an operator may confuse two deliveries, one decision and one issued certificate—or count one replay as a new authorized action.

Every carrier creates a different false shortcut

HTTP makes the mistaken shortcut easy to see because it supplies an explicit status code. The same error appears in quieter forms elsewhere.

With file transport, RFC 10003 requires one binary request or response per file and recommends defined extensions. A file appearing in an outbound directory can prove that a process wrote bytes. A response file appearing later can prove that another set of bytes returned. Neither file name nor filesystem timestamp establishes that the body parsed, that a signature verified or that the requested certificate was granted.

With mail, the standard specifies MIME wrapping, media types, file names and base64 examples. A submission receipt, message identifier or mailbox arrival is evidence about the mail system. It is not the CMC status. The distinction is especially important because transport security can change hop by hop. RFC 10003 warns that TLS to the initial mail submission agent does not guarantee authenticated or encrypted SMTP on later relays. REQUIRETLS may request authenticated TLS across the chain when supported, but can cause non-delivery where a relay lacks the extension.

With raw TCP, messages travel in binary form without another wrapper. Port 5318 is registered as pkix-cmc, and a client must wait for the full response before sending another request on the same connection. A successful connection or completed socket write still proves less than a validated PKI Response.

The carriers differ, so their observations differ. The governing separation does not: delivery evidence, protocol decision and operational deployment remain distinct.

Message protection does not erase transport governance

CMC uses CMS structures that can provide integrity, authentication and confidentiality at the message layer. RFC 10003 also discusses TLS, IPsec, EnvelopedData and AuthEnvelopedData. It would be easy to conclude that a well-protected CMC object makes the path irrelevant.

It does not. Message protection can help a recipient verify who protected a body and whether it changed. Transport evidence still answers which endpoint was used, when the exchange happened, which wrapper was declared, whether a relay returned an error, and which request was paired with which response. The layers protect different claims.

The reverse is also true. HTTPS can protect a connection from eavesdroppers, but it does not prove that the CMC message is authorized under CA policy. RFC 10003 says clients are not required to support HTTP authentication or cookies, so servers cannot rely on those mechanisms being present. Trust initiation remains an architectural decision outside the transport specification.

Good governance therefore avoids the phrase “securely delivered” unless it names the layer. Was the connection confidential? Was the CMS object intact? Was the signer authorized for the requested action? Did the RA approve it? Did the CA issue a certificate with the intended names and key? Did the target system install that exact certificate? One adjective cannot safely cover all six questions.

A transport-to-decision receipt

I propose a CMC transport-to-decision receipt for automated enrollment. This is Daniel Kade's governance design, not a requirement added by RFC 10003 or the IETF.

The first section records the carrier event. For HTTP, it includes endpoint identity, method, time, status code, content type, TLS policy reference and bounded request and response hashes. For mail, it records the submitted message identifier, intended destination, observed hand-off state and any available authenticated-relay policy. For file or TCP, it stores the controlled channel identifier, direction, time and object hash. It does not retain message bodies, credentials or sensitive topology.

The second section records application parsing. It identifies Simple or Full PKI Request and Response, transaction identifier where present, relevant body-part references and the verified protection result. A transport receipt without a successfully parsed, authenticated response remains incomplete.

The third section records the decision. It keeps each CMC status separately: success, failed, pending, partial and the other defined control states. A pending entry includes the token identifier as a protected reference, the suggested query time and the later poll that resolves it. Failure information is bounded to what an operator needs; it should not spill identity evidence or enrollment secrets into a general dashboard.

The fourth section records the issued object only when one exists. It binds the certificate fingerprint, subject and name set in a controlled form, public-key reference, issuer, serial and validity period to the request and decision. It does not assume that certificates in a response are ordered, and it does not promote an included self-signed certificate to a trust anchor.

The final section is deployment. Installation, activation and relying-party acceptance are separate observations. A CA can issue correctly while a device installs the wrong chain, retains an old certificate or never activates the new one. The receipt closes only to the level actually observed.

Design the dashboard around verbs

The language of the operating interface should preserve these distinctions. “POST accepted,” “CMC response parsed,” “request pending,” “certificate issued,” “certificate installed” and “connection validated with new certificate” are different verbs with different owners and clocks.

The owners matter. A network or platform team may operate HTTP and TLS. A mail administrator may own relay policy. An RA may validate identity or entitlement. A CA applies issuance policy. A device team installs the credential, and a relying service decides whether to accept it. If one dashboard compresses their work into “enrollment succeeded,” failures become politically invisible as well as technically ambiguous.

Monitoring should look for broken joins: 2XX responses whose bodies do not parse; CMC failures represented as transport success; pending tokens with no later query; duplicate request hashes under different transaction identifiers; returned certificates that do not match the requested key or names; issuance with no installation receipt; and active services still presenting the previous certificate.

The most useful denominator is not the number of green HTTP requests. It is the number of initiated enrollment transactions for which the organization can state the last proven stage and the evidence that supports it.

Running code should not be allowed to invent certainty

RFC 10003's precision is operationally generous. It gives every carrier a recognizable shape. RFC 10002 gives the contained protocol explicit states. The ambiguity enters when automation discards one of those shapes and substitutes its own shortcut.

A workflow that declares issuance after HTTP 200 is not merely imprecise reporting. It can trigger certificate deployment, retire a still-valid credential, close a change ticket or satisfy a compliance control on evidence the CA never produced. The second-order effect is loss of retry discipline. The third-order effect is that a fleet-scale automation system reproduces the same unsupported conclusion across thousands of identities.

The repair is not to mistrust automation. It is to give automation narrower, composable facts. Transport succeeded. Response parsed. Operation remains pending. Certificate fingerprint X was issued. Endpoint Y installed it. Relying probe Z accepted it at time T. Each statement can be tested, expired and reassigned without rewriting the others.

RFC 10003 standardizes the road travelled by a CMC message. Governance must still preserve the border between arrival and judgment.

Sources

  1. Lu Heng — Data Sovereignty: Technical vs Practical Realities
  2. Lu Heng — Why BTW Media Exists
  3. Lu Heng — Running-Code Primacy
  4. RFC 10003 — Certificate Management over CMS: Transport Protocols
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — CMC Compliance Requirements
  7. RFC 5273 — Certificate Management over CMS: Transport Protocols
  8. RFC 5967 — The application/pkcs10 Media Type
  9. RFC 8551 — S/MIME 4.0 Message Specification
  10. RFC 9110 — HTTP Semantics
  11. RFC 9205 — Building Protocols with HTTP
  12. RFC 9325 — Recommendations for Secure Use of TLS and DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — SMTP Require TLS Option
  16. RFC 3207 — Secure SMTP over TLS