Summary

  • The IESG opened Last Call on draft-ietf-lamps-csr-attestation-29 on 2 September 2026, seeking comments by 16 September; it is a proposed Proposed Standard, not an approved RFC.
  • The draft carries one or more Evidence, Endorsement or Attestation Result statements inside PKCS#10 or CRMF certificate requests. It standardizes a container, not a universal appraisal verdict.
  • A CA/RA may verify the extra statements against issuance policy or discard them. If it uses them, it remains responsible for key binding, platform joins and freshness.
  • Copying sensitive hardware, patch or ownership evidence into a public certificate is not recommended. A valid certificate therefore cannot reveal, by itself, what private appraisal occurred.
  • A protected issuance-evidence receipt could preserve the CSR-to-certificate decision path without turning device evidence into public metadata. That is Daniel Kade’s proposal, not an IETF requirement.

A public credential with a private prehistory

Suppose two code-signing certificates expose the same profile and both validate to trusted issuers. One subscriber generated its key in an approved hardware module and supplied fresh evidence that the CA appraised. The other followed a different policy path that required no CSR attestation. Nothing in the certificate comparison necessarily tells an outside reviewer which path applied.

That is not evidence that either certificate was mis-issued. It is the ordinary result of separating an issuance process from the credential it produces. The IESG’s 2 September Last Call puts this separation before the community in a concrete carrier specification. Comments on revision 29 are due on 16 September. The Datatracker record still says In Last Call, with IANA review needed. The history records an ARTART review assignment on 6 September. These are review events, not deployment or approval.

Revision 29 defines ASN.1 structures that carry remote-attestation statements in PKCS#10 and CRMF requests. Both standardized and proprietary statement formats can fit. A bundle may contain Evidence created by an Attester, Endorsements, or Attestation Results created by a Verifier, plus certificates useful for validating those statements.

The carrier is intentionally agnostic about the meaning of every enclosed format. PKCS #10 supplies one request envelope; CRMF supplies another. The new structures allow evidence to travel with either. They do not turn every request into an attested request, make every CA process the bundle, or cause every statement to assert the same property.

The official revision 28 text and 28-to-29 comparison also impose an important news discipline. The latest revision contains clarifications and reference maintenance, but the central evidence boundary predates it. The news is that this design is now in IETF-wide Last Call, not that revision 29 invented private appraisal.

The CA can process the bundle—or leave it untouched

The draft gives the CA/RA a choice that cannot be inferred from the presence of a certificate. It may verify the statements to decide whether an issuance policy is met, or which policy among several is satisfied. It is also free to discard the additional information without processing. A CA that accepts or requires attestations should document its requirements in its Certification Practice Statement.

Those sentences define three different records. The CSR records what the requester supplied. The CA’s internal workflow records what was appraised and which issuance policy consumed the result. The certificate records the credential the CA finally signed. One cannot be substituted for another.

This distinction follows the architecture behind the carrier. RFC 9334 separates a Verifier’s appraisal of Evidence from a Relying Party’s application-specific appraisal of Attestation Results. Trust is a choice; trustworthiness is a quality used in making that choice. A signed evidence object does not carry a universal instruction to issue.

The CA/Browser Forum Code Signing Baseline Requirements illustrate why a CA might want such evidence. They require protected handling of subscriber signing keys and identify ways a CA can verify suitable hardware protection. But the existence of a requirement page does not prove which method was used for one certificate. Nor does the IETF draft certify that a particular CA complied with those requirements.

Several true statements still need one valid join

An attestation bundle can contain statements from several sources. Revision 29 offers an example: one statement says a key pair was generated in an HSM, another says a platform is company-owned, and a third says the platform was in a known-good state.

All three statements can be independently correct and still fail to support the intended issuance claim. The HSM statement must apply to the public key in the CSR. The ownership statement must apply to the platform containing that HSM. The known-good-state statement must apply to that same platform. The CA/RA is ultimately responsible for confirming that the pieces apply in concert.

The draft also says at least one bundle element should contain an attestation cryptographically bound to the CSR’s subject public key. That is a floor for a meaningful connection, not proof that every other statement is joined to the correct device or that the CA exercised a particular policy. A dashboard that records only three attestations present would preserve supply while losing adjudication.

Freshness adds another decision. Revision 29 says a CA/RA may ignore evidence that is stale or whose freshness cannot be determined. The related freshness draft, revision 08, defines how an end entity can request a nonce through CMP, EST or CMC. It leaves several questions outside its scope, including whether one or more nonces are required, how a nonce reaches the Attester, who generates it, and other freshness methods.

Thus a nonce field is not a self-executing freshness verdict. An auditable issuance record needs the method, issuer, expiry or accepted interval, the evidence that consumed it and the policy that judged it.

Privacy explains why the certificate should not carry the file

The information can be sensitive. Hardware details, patch levels and device ownership can reveal operational architecture or create durable correlation. Revision 29 therefore says it is not recommended for a CA to copy attestations into the published certificate. A CA that does republish should inspect the content and delete sensitive information. The CRMF extension variant is likewise not recommended for use in X.509 certificates because publishing the hardware environment has privacy implications.

That limit is sound. Certificates are routinely distributed, cached and retained. Making the entire attestation bundle public would solve an audit problem by creating a disclosure problem. It could also freeze a time-bounded platform claim into a credential whose audience and retention exceed the original appraisal context.

But privacy does not require amnesia. A protected issuance-evidence receipt can bind the exact CSR digest to the issued certificate fingerprint or serial, list statement-format identifiers and privacy-safe evidence digests, identify the Attester, Verifier and accountable CA/RA roles, and record key binding, platform joins, freshness result, evidence-appraisal policy, issuance-policy version, statement disposition, decision, reviewer and time.

Its public projection can be much smaller: a receipt identifier, certificate reference, bounded claim, applicable policy pointer and correction route. Raw measurements, device inventory, ownership material and sensitive reference values remain protected. Authorized auditors can inspect them under retention and disclosure rules.

This is my proposed control, not text in the draft. It does not make hidden evidence correct, compel CAs to use attestation or add a new certificate extension. Its purpose is narrower: if a later reviewer asks why this certificate was issued, the answer should not have to be reconstructed from a certificate that was never designed to contain it.

The Policy Mirror directs attention to the switch that converts evidence into authority. Here the switch is the join among private appraisal, CA policy and signature. Running Code Primary sets the proof standard: a CPS describes intended practice; a certificate proves issuance; only an execution record can show what this workflow actually did.

Sources

  1. IESG Last Call
  2. CSR-attestation Datatracker record
  3. CSR-attestation history
  4. CSR-attestation revision 29
  5. CSR-attestation revision 28
  6. Official 28-to-29 comparison
  7. RATS architecture, RFC 9334
  8. PKCS #10, RFC 2986
  9. CRMF, RFC 4211
  10. Attestation freshness revision 08
  11. CA/Browser Forum Code Signing Baseline Requirements
  12. Lu Heng — The Policy Mirror
  13. Lu Heng — Running Code Primary