Summary

  • RFC 10004 distributes CMC requirements across entities, clients, servers, end entities, registration authorities and certification authorities. One component may occupy several roles, and each role changes which obligations apply.
  • A useful compliance record must bind an implementation version to its role graph, conditional features, algorithm policy, configuration epoch, transaction path and result. A generic “CMC compliant” label proves none of those later facts.

The procurement workbook had one row for certificate enrolment and one reassuring answer: CMC compliant. The supplier had implemented Full PKI Requests, HTTP transport and the required cryptographic floor. The buyer wanted registration authorities to perform identity validation and delegated proof of possession before forwarding selected requests to a certification authority. Those were not the same proposition.

This is a constructed operating case, not a report about a named vendor or deployment. Its purpose is to expose the structure of RFC 10004. The document does not define a single badge. It divides compliance among six applicability classes: all entities, all clients, all servers, end entities, registration authorities and certification authorities.

The classes overlap. In the simplest chain, an end entity is the client and a certification authority is the server. Insert a registration authority and the RA becomes a server toward the requester and a client toward the issuer. Insert several RAs and the graph becomes longer. RFC 10004 says routing may depend on request content and that it is normal for not every RA to see every request.

That topology changes what a capability claim means. A component can correctly generate one CMC request form but never validate a control required of the server role. An RA can process one request family yet lack a feature needed when it performs delegated proof of possession. A CA designed for direct enrolment can meet a different set of conditions from one designed to operate behind RAs. “Supports CMC” omits the subject of the sentence.

RFC 10004 is the compliance companion to the structure and transport specifications. RFC 10002 defines CMC messages and controls. RFC 10003 defines transport. RFC 10004 says which pieces an entity must, should or may support in a particular role. The RFC Editor record and errata search identify the exact publication and correction surface.

All entities must support Full PKI Requests, Simple and Full PKI Responses, CRMF certification requests and HTTP transport. Servers should support Simple PKI Requests and PKCS #10. That is a common floor, not the whole building. The control table then varies obligations across EE, RA and CA columns and adds conditions in notes.

Those notes matter more than a marketing checkbox. A CA must implement certain RA-facing controls if it is designed to work with RAs. An end entity's Response Body obligation becomes stronger when RAs perform identity validation or key generation. Encrypted and Decrypted POP support depends on key-agreement use, hardware that cannot sign and delegated POP choices. The correct answer can change without replacing the binary, simply because the deployment turns on a different role or feature.

The algorithm profile is similarly layered. RFC 10004 requires RSA-SHA256 for SignedData generation and verification, AES for EnvelopedData, AES-GCM for AuthEnvelopedData with specified nonce and integrity-check lengths, and RSA key transport. Conditional paths add DH, PBKDF2, AES key wrap and HMAC-SHA256 requirements. The underlying CMS framework comes from RFC 5652; SHA-2 use is specified by RFC 5754, and authenticated encryption by RFC 5084.

An inventory can truthfully show every mandatory primitive and still fail to prove that a transaction selected the intended primitive, used the required parameters or reached the component expected to validate it. Capability is not configuration. Configuration is not execution. A successful exchange is not certificate authorization, and an issued certificate is not proof that an application later trusted or used it correctly.

Proof of possession makes the distinction concrete. RFC 10004 requires a CA to enforce POP before issuance, while allowing delegation to an RA in bounded cases. DH POP has its own mechanism in RFC 6955. The evidence question is therefore not only “does the product support POP?” It is which agent performed which POP method for which request, under which policy, and what evidence crossed the next boundary.

The compliance document also carries a time problem. It replaces RFC 5274 and incorporates the updates from RFC 6402. It moves the mandatory algorithm floor from older SHA-1 choices to SHA-256-era choices and permits older algorithms for backward compatibility while recommending transition where possible. A test report without the governing RFC revision and algorithm-policy epoch can become formally precise and operationally obsolete.

The certificate that emerges still enters a separate PKIX world. RFC 5280 governs certificate and path-validation semantics. Passing the CMC capability matrix does not prove that the requested identity was entitled to the certificate, that a relying party built an acceptable path, that application authorization followed or that a service outcome occurred.

Heng Lu's reality-layers note supplies the editorial discipline: standard, capability, configured role, executed transaction, issuance and reliance should not share one status field. Running-Code Primacy puts observed implementation behaviour ahead of the badge. Minimum Initial Specification argues for a narrow common contract while leaving future operational choices local and attributable.

The replacement for the checkbox is a role-bound receipt. It names the component and software revision; every role on each edge; the RFC and errata baseline; mandatory and conditional features; enabled algorithms and parameters; configuration and policy versions; the route taken by the request; controls actually processed; the POP decision; and the final response. Where an RA did not see the request, the record says so.

That receipt does not make every enrolment trustworthy. It makes the boundary reviewable. Leaders can then ask whether the capability purchased matches the topology deployed, whether the exercised path matched the policy approved and whether the result deserves reliance.

Sources