Summary

  • RFC 9810 gives accepted and grantedWithMods different meanings. The first says the requester received exactly what it asked for; the second says it received something similar and is responsible for discovering the differences.
  • An authenticated CMP response can prove the source and continuity of a transaction without proving that subject names, lifetime, Key Usage, Extended Key Usage, constraints, policy or publication state still match the requester’s authorized intent.
  • A local certificate-intent receipt can bind the request, issued certificate, field-level delta, authority for each material change and accept-or-reject decision without retaining private keys or building a public certificate dossier. This is Daniel Kade’s editorial proposal, not an RFC field.

The dangerous interface is often a green row. An enrollment client sent a protected request. A recognized CA returned a protected response. The certificate parses, its signature verifies and the workflow marks the transaction complete. If the interface compresses both positive CMP states into “success,” it discards the difference that RFC 9810 asks the requester to examine.

The standard is unusually direct. In its status definitions, accepted means that the requester got exactly what it asked for. grantedWithMods means that it got something like what it asked for, and that the requester is responsible for ascertaining the differences. Elsewhere, RFC 9810 says that even when an originator completely specifies the desired certificate, the CA is free to change fields in the certificate it actually issues. If the result is unacceptable, the requester must reject it through certificate confirmation.

None of this makes grantedWithMods an error. A CA may have sound reasons to normalize a distinguished name, cap a validity period, insert an issuer-selected serial number, apply a policy identifier, constrain Key Usage, refuse an extension or construct a subject alternative name under an approved profile. The governance problem appears when a technically valid modification becomes invisible between issuance and use.

The status is a fork, not a verdict

RFC 9810, published on the IETF Standards Track in July 2025, consolidates the Certificate Management Protocol for creating and managing X.509 certificates. It defines exchanges among end entities and PKI components such as Registration Authorities and Certification Authorities. It obsoletes RFC 4210 and, together with RFC 9811, also obsoletes RFC 9480. The document adds KEM-related support and moves encrypted material toward CMS EnvelopedData, but its governance value is older and more basic: it keeps request, issuance and confirmation as separate acts.

The requester expresses desired certificate content through a CertTemplate. The structure resembles the to-be-signed part of an X.509 certificate, with its fields optional or situational. The template can name a public key, subject, validity and extensions. A requester can even ask for a certificate-request blueprint before enrolling, so that it learns what the CA expects.

That template is not an order that binds the issuer. The CA remains responsible for what it signs. Its policy may require it to supply, remove or change fields. CMP therefore cannot promise that every successful issuance reproduces the request byte for byte. Instead it exposes two positive outcomes.

This design is honest. A binary success flag would force very different events into one category. Exact fulfillment and policy-shaped fulfillment are both successful protocol responses, but they are not the same decision. grantedWithMods is a fork: it hands control back to the requester for an acceptance judgment.

A management system that paints the fork green and immediately installs the certificate has quietly reassigned that judgment to interface code. It has not eliminated governance. It has let a default make the decision without preserving who authorized the changed scope.

The differences can change authority

The comparison is not a cosmetic diff between two forms. RFC 5280 defines the signed certificate body: version, serial number, signature algorithm, issuer, validity, subject, subject public key information and extensions. Some fields are issuer machinery. Others describe who or what the certificate names, when it operates and what its key may do.

Key Usage can distinguish digital signatures, key encipherment, key agreement, certificate signing and CRL signing. Extended Key Usage can attach one or more purposes. Basic Constraints can distinguish an end entity from a certification authority and limit a certification path. Subject alternative names can determine which service identities are represented. Certificate policies can point to a ruleset under which relying parties evaluate use.

Not every delta carries equal weight. A CA-generated serial number is expected. Reformatting an equivalent name may be benign under the profile. Shortening validity can reduce exposure. Removing an unsupported non-critical extension may be acceptable. But adding a CA-signing capability, changing a service identity, broadening an EKU, replacing a public key, altering criticality or moving to an unexpected policy can change operational authority.

RFC 9810 makes one such consequence explicit. When a CA issues a certificate containing certain Extended Key Usage values for PKI management roles, it delegates authorization that originally belongs to the CA certificate itself. The RFC calls this a sensitive action and requires special care so that only legitimate entities receive those EKUs. In that setting, “modified” is not typography. It can be a transfer of institutional power.

The correct comparison therefore needs semantics. A byte-level hash proves that two artifacts differ, but not whether the difference is expected or material. A field-level decoder can show that validity moved from one interval to another, that an EKU was added or that a SAN was normalized. Local policy must then say whether that change is allowed, needs a named approver, requires a new request or must be rejected.

Message authentication proves a narrower proposition

CMP protects messages and binds them into transactions with identifiers, nonces and response relationships. Depending on the profile, protection may use shared secrets or signatures. Proof of possession can show that the requester controls the private key associated with the public key being certified. An RA may validate and authorize a request, forward it under additional protection or modify it under defined mechanisms.

Those controls matter. Without them, the requester could be comparing an attacker’s object to its own request. But authenticity of the exchange does not make the request and certificate semantically identical. A signed parcel can come from the right sender and still contain an authorized substitution that the recipient must decide whether to accept.

This is also why the article begins after proof of possession. Possessing a private key does not establish identity or entitlement to every certificate field. The CA’s decision does not end the chain either. It creates a signed object whose relationship to the authorized request must still be assessed by the requester.

An RA introduces another boundary. It may forward an original protected request unchanged and add its own protection. It may also modify a request and optionally carry the original message so the CA can examine what changed. The useful evidence is not “the RA was involved.” It is which values originated with the end entity, which were introduced or normalized by the RA, which the CA signed and under what authority each material transformation occurred.

Certificate confirmation is a decision surface

RFC 9810’s certConf message lets a client accept or reject certificates supplied in the preceding response. Omitting statusInfo for a named certificate indicates acceptance. Omitting the corresponding CertStatus structure indicates rejection; an empty sequence can reject them all. A client may also name the certificate hash and provide an explicit rejection status.

That structure is easy to treat as protocol cleanup, but it carries the requester’s last reversible decision before a certificate is allowed to become ordinary operational state. The confirmation should correspond to the actual issued certificate, not merely to the request identifier or the fact that the CA answered.

The lightweight CMP profile makes the state machine clearer. A positive response can be accepted or grantedWithMods. If implicit confirmation was not requested and granted, the end entity sends certConf, the PKI management entity returns pkiConf, and the transaction closes. If the expected confirmation does not arrive, the profile says to handle that like rejection.

Explicit confirmation can be omitted through implicitConfirm. The end entity asks not to send a separate confirmation; the CA or RA echoes the extension if it grants the optimization. This saves a round trip. It does not say that a client may install an unchecked certificate. It changes how acceptance is communicated, not whether the issued object must be acceptable under local policy.

That distinction becomes important in automation. If a device fleet requests implicit confirmation, its enrollment component must complete the semantic comparison before it sends the request or before it treats the echoed response as deployable. Otherwise a latency optimization becomes a governance shortcut: the system has agreed in advance to accept modifications it has not classified.

Policy explains why a difference may be legitimate

RFC 3647 separates a certificate policy from a certification practice statement. A certificate policy states requirements for a community or class of applications. A CPS describes how a CA implements its practices and controls. The distinction is useful because the CMP status cannot carry the whole institutional reason for every issued field.

Suppose a request asks for a two-year lifetime and a server-authentication EKU. The CA’s policy permits one year and requires both server and client authentication for a managed device profile. The issued object can be technically valid and faithfully implement the CA’s published practice while differing materially from the requester’s local deployment design. The correct outcome depends on whether the requester authorized that profile, not on whether either side is malformed.

The requester therefore needs the profile and policy identities used for the issuance, including versions. “CA policy” is too broad if several profiles exist. A later reviewer should be able to distinguish an expected profile transformation from an operator exception, a stale client template or an unreviewed issuer change.

The comparison must also avoid pretending that the request supplies every field. Some fields are properly issuer-selected. A disciplined receipt labels them as issuer-owned rather than reporting them as suspicious differences. The purpose is not to demand byte identity. It is to make the allocation of decision rights explicit.

Publication is observation, not acceptance

Certificate Transparency can make issuance observable. RFC 9162 describes append-only logs that allow interested parties to audit CA activity and notice suspect certificates. It also states the limit: logs do not themselves prevent misissuance. A CT entry can prove that a certificate or precertificate was logged under the protocol’s rules. It cannot prove that the requester accepted the certificate, that the certificate matches local intent or that it was authorized for deployment.

RFC 9810 exposes a particularly sharp ordering rule for indirect proof of possession. A CA using that method must not publish the final certificate to CT before receiving the certConf that contains the certificate hash and completes the proof. Precertificates do not create the same risk. The sequence shows why “issued,” “confirmed” and “published” cannot be collapsed into one timestamp.

Even outside that POP case, publication should remain a distinct state. A certificate may appear in a log and later be rejected locally. It may be accepted but never installed. It may be deployed in one service while another service refuses it. It may need revocation and reissuance because a material difference was noticed after automation had already propagated it.

A governance record must therefore follow the object past the CA’s response without claiming that every later step belongs to the CA. The requester controls acceptance. The service owner controls deployment. Relying parties apply their own path validation and application policy. CT monitors observe issuance. These actors are connected, not interchangeable.

A certificate-intent receipt makes the delta reviewable

The proposed certificate-intent receipt begins with canonical identities for the protected request, the CertTemplate, the applicable profile and the returned certificate. It records the CMP transaction and response state without storing shared secrets, private keys, decrypted central key packages or unnecessary subject evidence.

It then presents a normalized comparison. Issuer-owned expected values are identified as such. Requester-owned values are compared field by field. Material fields include the public key, subject and subject alternative names, validity, Key Usage, Extended Key Usage, Basic Constraints, certificate policies, name constraints where relevant, criticality and any extension the application relies upon. Unknown critical extensions fail closed. An allowed normalization cites the rule that permits it.

Every material difference receives a disposition: expected by profile, accepted by an authorized role, rejected, or unresolved. The receipt records who exercised the decision, the authority they had for this service or device class, the software and policy versions used for evaluation, and whether confirmation was explicit or implicit. Acceptance of the certificate is kept separate from permission to publish or deploy it.

Finally, it records publication and deployment states, exception expiry, rollback target, revocation or reissuance if needed, and the correction history. A corrected receipt does not overwrite the earlier decision; it links the superseding state so a reviewer can understand what the system believed at each point.

The record should be access-controlled and minimized. It does not belong on a public page merely because some certificates are public. Internal subject names, device identifiers, profile exceptions and enrollment metadata can expose a sensitive inventory. For public TLS, CT already supplies a deliberately scoped public observation layer. The receipt supplies local decision lineage.

Running code must preserve the distinction the protocol already made

Heng Lu’s separation of specification, localized future decision, voluntary adoption, execution and observed outcome is especially useful here. RFC 9810 specifies a vocabulary that admits modification. A CA makes a local issuance decision. A requester decides whether to accept. An operator decides whether and where to deploy. Relying parties produce observed outcomes. No earlier layer can prove all the later ones.

Running-code primacy does not mean that whatever the enrollment client installed becomes legitimate. It means the actual transition must remain visible enough to test against the stated rule. If the client turns both accepted and grantedWithMods into one boolean, the implementation has thrown away governance information provided by the protocol.

The Policy Mirror offers the complementary warning: policy language can describe an intended control while operations do something else. A profile may require field review, but a fleet manager may auto-install every positive response. BTW’s reality layer should report the difference without inventing a failure. The question is inspectable: did the implemented workflow preserve the delta, apply the correct policy and record an authorized disposition before deployment?

The conclusion is not that CAs should stop modifying requests. Nor is it that explicit human approval must block every certificate. Safe automation can be faster and more consistent than manual review. It simply needs to automate the real decision: compare requested and issued authority, classify every material difference, and preserve who was entitled to accept it.

A green response can end a protocol exchange. It cannot by itself decide what the new credential is allowed to become.

Sources