Summary

  • RFC 10002, edited collectively by Joseph Mandel and Sean Turner, treats Proof-of-Possession as evidence that an end entity holds and can use the private key corresponding to a public key. It does not turn that fact into proof of identity or permission to receive a certificate.
  • Identity evidence and key-possession evidence travel separately in CMC and must be bound to the same requester. Registration Authority changes remain outside the signed request, while a Certification Authority still applies its own policy and may modify, defer or reject the requested result.
  • A durable enrollment receipt must preserve every transition: original request, possession method, identity method, anti-substitution linkage, RA wrappers, CA decision, returned status, exact issued certificate and later installation and validation. No green state should overwrite the states before or after it.

Imagine an enrollment console with one reassuring line: POP verified. The requester signed a PKCS #10 message with the private key corresponding to the public key inside it. The signature checks. The cryptographic statement is valuable and exact.

It also leaves most of the consequential questions unanswered. Who is the requester? May that person or device claim the requested subject name? Who approved the Subject Alternative Name? Did an intermediary add or remove an extension? Which certification policy did the issuer apply? Was a certificate issued, delivered and installed? Would a relying service accept it now?

Certificate Management over CMS is useful precisely because it does not collapse those questions. RFC 10002, published on the IETF Standards Track in July 2026, defines the current CMC message structure. RFC 10003 defines transport choices. RFC 10004 sets compliance requirements for classes of CMC agents. Joseph Mandel and Sean Turner are the editors of all three documents; the work is collective, built on PKCS #10, CRMF, CMS and the wider X.509 public-key infrastructure.

Turner's long standards record provides context, not personal authority over an enrollment. The IETF Datatracker records participation since IETF 34, more than 50 authored or co-authored RFCs, service as Security Area Director from 2007 to 2014, and several past and current chair roles at the 1 September 2026 capture. Those facts explain why his name appears on security standards. They do not make him, the IETF or an RFC the Registration Authority or Certification Authority for a particular request.

A signature protects a request without approving it

PKCS #10 gives the requester a way to bind a public key, a subject and attributes into a signed certification request. Verifying that signature shows that the message was not casually altered and that the signer can produce a signature with the corresponding private key. It prevents an attacker from simply replacing the public key inside the signed object and retaining a valid request.

That is a strong result, but RFC 2986 describes the next steps separately. A Certification Authority authenticates the requesting entity, verifies the signature and, if the request is valid under the authority's rules, constructs a certificate. The conjunction matters. A correct signature does not command the CA to issue, choose every requested field or accept every claimed name.

RFC 10002 generalizes the key question as Proof-of-Possession, or POP. It recognizes signature-based proof, direct challenge-response, indirect proof, publication and attested forms, although not every form is used in every CMC exchange. The common purpose is deliberately narrow: show that the end entity possesses and can use the private key corresponding to the public key.

POP says nothing by itself about who the entity is. A stolen key can still generate a valid signature. A correctly controlled key can be presented with an unauthorized domain name. A hardware device can prove key use while its inventory identity is wrong. A person can control a key without being entitled to request a certificate for an employer, service or regulated role.

The operational mistake is to promote a true lower-level claim into a different higher-level claim. private key usable becomes requester identified; that becomes name authorized; that becomes certificate approved. CMC supplies no licence for those promotions.

Identity is another proof, and the join is a security event

RFC 10002 defines Proof-of-Identity separately. A Simple PKI Request must not be used when identity proof needs to be included. A Full PKI Request can carry a shared-secret identity witness or use an existing certificate as part of a bilaterally understood method.

Separate evidence creates a separate attack. If one party supplies a valid identity witness and another supplies a valid key proof, an intermediary must not combine the two into one apparently complete request. The RFC therefore requires the identity information and POP to be linked so that the same entity supplied both. Witness calculations, matching a shared secret to a subject name, and linkage to an existing certificate are mechanisms for that join.

The join deserves its own receipt. Record which identity evidence was accepted, who owned it, which key proof was verified, which bytes were bound, which substitution check ran and what identifier joined them. Writing only identity and POP passed makes it impossible to tell whether two individually correct proofs belonged together.

The shared-secret option also exposes a boundary that cryptography cannot repair after the fact. Distribution of that secret is outside RFC 10002. If it reached the wrong device, was reused too broadly or remained active through retries, a correct witness only proves knowledge of a poorly governed secret. The verifier should retain the method and its limits, not rename the result as universal identity assurance.

The RA may add a layer; it may not rewrite history

CMC distinguishes the End Entity, Registration Authority and Certification Authority. An End Entity owns the key pair and seeks a certificate. An RA may perform local proofing, batching, routing, key generation, archival or extension processing. A CA issues certificates. The same system can act as a CMC server toward the end entity and a client toward the CA, and multiple RAs can create nested wrapping layers.

Protocol direction is not authority. Receiving a request does not let an RA silently become the requester. Forwarding one does not make the RA the issuer. A hop can be technically valid while the actor lacks permission under local policy.

The signed inner request is the crucial boundary. An RA must not edit a signed PKCS #10 or CRMF request because doing so would invalidate its signature and POP. If the RA asks the CA to change fields or add extensions, CMC places that action in an outer control. The record can then show what the end entity requested and what the intermediary separately proposed.

That distinction becomes especially important for extensions. A requester may ask for key usage, name, policy or other X.509 extensions. RFC 10002 does not require the server to reproduce every requested extension in the certificate. The server may modify requests, but must not reverse their original intent. The final certificate is therefore neither a photocopy of the request nor evidence that the requester consented to every intermediary decision.

Retaining only the issued certificate loses the negotiation. Retaining only the original request loses the authority that changed it. The minimum defensible history includes the signed request, every nested RA wrapper, each modification and its policy basis, the signers, the template evaluated by the CA and the exact result returned.

HTTP success and CMC success are different clocks

RFC 10003 permits CMC exchanges over HTTP, file, mail and TCP. Over HTTP, the client uses POST and defined MIME types. HTTPS can protect the channel, but the transport document does not require every CMC client to implement HTTP authentication. Channel encryption, HTTP authentication, CMC identity proof and key-possession proof answer different questions.

So do their status codes. A 2xx HTTP response says that the HTTP exchange was handled successfully. The enclosed CMC response can still say that processing is pending, identity is bad, POP is required, POP failed or an extension is unsupported. Transport success cannot be used as a certification verdict.

Even a successful CMC response needs a concrete object. Which certificate was returned? Does its public key match the request? Which subject, names, usages, policies and validity period were actually issued? Was the response delivered to the intended end entity? A status label without the final bytes is not an issuance receipt.

RFC 10004 adds another useful limit. An implementation can satisfy a stated class of CMC compliance without proving that a particular organization has deployed it correctly or that a particular request met policy. Standards conformance is not transaction evidence.

Issuance begins another chain of evidence

An issued certificate is still not an operational authorization. RFC 5280 path validation considers trust anchors, certification paths, names, policies, constraints and validity. Revocation checking adds status and freshness. Installation adds an asset, configuration and custody state. A service then applies its own authorization rules.

These stages can diverge. A CA may issue a correct certificate that never reaches the device. A device may install it beside the wrong private key. A relying party may reject the path. A valid path may authenticate an identity that the application is not willing to authorize. Later revocation may end a previously valid state.

Heng Lu's Running-Code Primacy offers the appropriate discipline: preserve the evidence needed to reproduce the claim at the layer where it was made. For enrollment, that means request bytes, proof methods, identity binding, RA actions, CA policy and response. For deployment, it means certificate bytes, key match, installation target, path result, status source and service decision. One dashboard field cannot carry all of them without destroying accountability.

A useful receipt has at least eleven lines: requester and time; requested key and fields; POP method and result; identity method and limit; linkage method; RA wrappers and changes; CA and policy version; CMC status; exact certificate; installation and validation; revocation, replacement and correction. Each line can fail independently. Each line can be corrected without pretending the others never happened.

This is the value of Turner's collective CMC work. It does not promise that a valid key proof will become a certificate. It supplies enough structure to show why it should not.

Sources