Summary

  • RFC 10002 preserves certificate requests inside nested CMS protection while allowing Registration Authorities to add explicit proof witnesses and field modifications in outer PKIData layers.
  • A valid request signature, proof of private-key possession, proof of identity, an RA witness, a processed modification and a CA-issued certificate are separate verdicts. None should be reported as a universal “verified.”
  • Operators need the original request, every signed wrapper, the order and scope of each control, the CA policy decision and a field-level diff against the issued certificate before publication or activation becomes irreversible.

The enrolment incident begins with two objects that both validate.

The first is a signed request. Its subject public key and attributes are intact. The signature verifies against the key expected by the enrolment service. The second is the certificate eventually issued by the Certification Authority. Its public key is the same. One extension is absent and another value differs.

Nothing in that comparison alone proves forgery. The more difficult possibility is that the protocol worked as designed: a Registration Authority checked something, wrapped the signed request rather than rewriting it, asked the CA to change a field, and the CA applied its own certificate policy. The operator's problem is no longer “did the signature survive?” It is “which authorised layer changed the desired certificate, what did that actor actually prove, and what evidence made the final issue decision legitimate?”

That is the control surface exposed by RFC 10002, Certificate Management over CMS (CMC), an IETF Standards Track specification published in July 2026. The document replaces RFC 5272 and RFC 6402. Together with the transport rules in RFC 10003 and the conformance matrix in RFC 10004, it describes an enrolment system in which cryptographic integrity and institutional authority travel beside each other but do not become the same thing.

A signature fixes bytes, not the whole decision

A PKCS #10 request has a clean mental model. RFC 2986 defines request information containing a subject name, a public key and optional attributes. The requester signs that information with the subject private key, and the signature travels with the request.

The signature is valuable. It makes an undetected edit to the protected request visible and demonstrates use of the signing private key. It does not compel a CA to issue a certificate. It does not prove that the named subject is entitled to the name. It does not necessarily demonstrate possession of a separate encryption key that cannot sign. It does not grant an intermediary authority to alter the requested extensions.

CMC supplies richer machinery because those questions arise in real enrolment systems. A bare PKCS #10 object can be a Simple PKI Request. It cannot carry the advanced control surface. RFC 10002 says the simple form must not be used when proof of identity is included and cannot serve a private key that is unable to sign. Full PKI Requests instead carry PKIData inside CMS SignedData or AuthenticatedData. Controls, one or more request bodies and supporting content can travel together.

The CMS foundation matters. RFC 5652 permits signed, authenticated and encrypted content to be encapsulated in further layers. One actor can protect content that already has another actor's protection. CMC uses that property to preserve an end entity's inner request while allowing an RA to add a signed outer statement.

That design avoids a tempting but destructive shortcut. An RA must not simply rewrite the subject's signed PKCS #10 or CRMF request. Doing so would break the signature or proof of possession. It can instead retain the inner object and add a control in an outer PKIData layer. With multiple RAs, multiple layers can accumulate.

The resulting evidence is architectural. The inner signature answers what the end entity protected. The outer signature answers which intermediary added a control. Neither answer, by itself, explains whether the intermediary was authorised for that control or why the CA accepted it.

Possession and identity are different proofs

The phrase “the requester was verified” is unusually dangerous in certificate operations because it can hide several incompatible meanings.

Proof of possession asks whether an actor demonstrated control of the private key associated with a requested public key. For a signing key, a signature can provide that evidence. For a key used only for encryption or key establishment, the proof may require a challenge, a later message or another method. RFC 4211, the Certificate Request Message Format, describes those alternatives and includes an raVerified choice for cases where an RA performed the proof and needs to change the request before forwarding it.

Proof of identity asks a different question: who is being associated with the transaction under the deployment's authentication arrangement? RFC 10002's Identity Proof Version 2 can use a shared secret to compute a MAC over request material. The older identity-proof form remains for compatibility, but RFC 10004 makes Version 2 mandatory and moves the baseline away from fixed SHA-1 machinery.

Neither proof absorbs the other. An operator can possess a private key without being entitled to a corporate name. A help desk can validate an employee record without demonstrating that the device holds the requested non-exportable key. A request signature can be technically perfect while the identity source was stale. A strong identity check can coexist with a malformed or substituted public key.

CMC makes delegated proof explicit. RA POP Witness allows an RA to state that it performed proof of possession. RA Identity Proof Witness allows an RA to tell the CA or another downstream actor that identity proof occurred, including when the CA does not know the shared secret or when the check occurred out of band.

A witness is not the original proof. It is a new assertion by an intermediary. The CA may be entitled to rely on it under policy, but an auditor needs to know which RA made it, which method and subject it covered, what evidence the RA retained, how long that evidence remains available and whether the RA's authority was still valid. “Identity proof present” is not an adequate record.

Control Processed is broader still. It can show that a control was handled locally or will be handled by a later actor. Where the identity method matters, RFC 10002 points operators toward the more specific RA Identity Proof Witness. The distinction is a warning against compressing a rich proof chain into a single green state.

The request can change without the signature breaking

The Modify Certification Request control is the protocol's sharpest test of attribution. It permits an RA to ask that fields in a certification request be replaced or deleted. The inner request remains exactly what the end entity signed. The requested modification lives in an outer, attributable layer.

That ability is operationally legitimate. An RA might canonicalise a directory name, remove an unauthorised extension, add an organisational constraint or translate an approved identity result into a CA-facing form. The important question is not whether modification exists. It is whether its target, old value, proposed value, authorising rule and responsible RA can be reconstructed.

Nested modifications have an order: inner layers are processed before outer layers. Multiple modification controls at the same layer do not receive a defined order from the standard. A deployment that relies on “the second array element wins” is relying on implementation behaviour, not a portable protocol guarantee. If order affects the result, the operator needs one unambiguous composite change or separately nested layers whose precedence is visible.

The CA then retains its own authority. RFC 10002 does not require the final server to include every extension requested by the end entity or an RA. It may omit or modify material under policy. It must not reverse the meaning of a client-requested extension—for example, converting a prohibition into permission—but the resulting certificate remains a CA decision, not a notarised copy of the request.

That makes field-level diffing part of issuance, not an optional audit exercise. The operator should be able to compare three states: the immutable end-entity request, the sequence of RA-requested changes and the certificate the CA signed. Each difference needs an owner. “The CA issued it” explains the final signer, not the provenance of every field.

A transaction is longer than a successful POST

CMC separates message delivery from enrolment state. RFC 10003 defines file, mail and HTTP transports. HTTP clients use POST, and HTTPS can protect content from eavesdroppers. A TLS session and an HTTP 2XX response prove neither that every CMC control was recognised nor that a certificate was finally issued.

Full exchanges can be pending or partially complete. Query Pending lets a client return for the result. Confirm Certificate Acceptance extends the transaction beyond receipt of a certificate. A final server that cannot recognise or process a required control must fail the whole PKIData; silently dropping the control would manufacture a success state with missing semantics.

Transaction identifiers associate messages across the operation. Once used, the same identifier continues through subsequent messages. Sender and recipient nonces support correlation and replay protection. The precise state burden varies by environment, but a state-capable system that discards nonce history gives up evidence it could have retained.

These are not bookkeeping niceties. A retry after a lost response can duplicate issuance, reuse stale identity evidence or detach a result from the request that authorised it. A pending result can be promoted to “certificate created” by a dashboard that counts transport success. A partially successful batch can be reported as complete while one body failed. The protocol supplies identifiers and status; the operating system must preserve their meaning.

Compliance is a capability floor, not a deployment verdict

RFC 10004 shows how deliberate the actor separation is. It requires all CMC entities to support Full PKI Requests and Full and Simple PKI Responses. It requires CRMF request syntax, HTTP transport and a modernised cryptographic baseline. Its control table assigns different duties to end entities, RAs and CAs.

RAs must implement Modify Certification Request, Control Processed and RA Identity Proof Witness. CAs designed to work with RAs must implement the corresponding receiving behaviour. RAs should implement RA POP Witness, and such CAs should understand it. Transaction identifiers and both nonce directions are mandatory across roles.

Those requirements establish what conforming roles need to be able to do. They do not demonstrate that a named deployment processed a particular wrapper correctly, that an RA was authorised, that evidence was retained, or that same-layer control order is deterministic. A compliance badge belongs to the symbolic layer until running components and retained artefacts make the path replayable.

The final certificate also has a life beyond CMC. RFC 5280 profiles the X.509 object that relying parties validate. It notes that specialised communities may add policy and assurance requirements and tells certificate users to review CA policy before relying on authentication or non-repudiation claims. Enrolment success is therefore upstream evidence, not universal relying-party trust.

CMC is not the only enrolment design. RFC 7030 defines Enrollment over Secure Transport over HTTPS. The comparison is useful because it prevents an organisation from converting a protocol choice into an inevitability. What matters here is the authority structure it actually runs and can explain.

The evidence chain that survives an incident

A useful record begins with the exact canonical request bytes and a hash. It identifies the request format, subject public key, protected attributes, signature result and signer key. For each POP and identity check, it records the method, target, original verifier, result, time, policy version and privacy-safe evidence reference.

For every RA layer, it preserves the signed wrapper, the RA identity and certificate, its authorised scope, the controls it added, any layer it removed and the downstream recipient. Every modification needs a body-part target, before-and-after value, nesting order and reason. Witnesses need the underlying proof category they represent. Raw shared secrets and private keys do not belong in the log.

The CA record then names the policy version and result for each requested or modified field. A generated diff connects the original request, RA chain and issued certificate. Transaction ID, nonces, status changes, retries, acceptance confirmation, publication and any activation event remain linked.

This evidence changes incident classification. If an RA is compromised, the inner request may still be authentic. Revocation can still be necessary because the attacker exercised a validly signed outer modification or witness path. Absence of request forgery is not absence of harm.

Running-Code Primacy supplies a demanding test: the authority of a CMC control comes from code that validates the protected layer, checks the actor's scope and produces an accountable decision. Minimum Initial Specification keeps common syntax, proof encoding and transaction safety precise without turning an intermediary into a universal certificate-policy sovereign. The reality-layer distinction keeps “signed,” “witnessed” and “issued” as descriptions of executable events instead of incantations.