Summary

  • On 2 September 2026, the IESG opened Last Call on revision 29 of Use of Remote Attestation with Certification Signing Requests, with comments due 16 September. It is an Internet-Draft intended for Proposed Standard, not an approved RFC or a record of deployment.
  • The draft can carry several attestations in one PKCS #10 or CRMF request, but the CA or RA remains responsible for proving that the HSM, platform ownership, platform state, freshness context and CSR public key describe one attributable enrollment transaction.

Imagine a certificate desk receiving three stamped folders. One says that a private key was generated inside an HSM. One says that a platform belongs to the applicant's company. One says that a platform passed a known-good-state check. Nothing in those three sentences says that the key is inside the HSM on the owned platform whose state was measured.

That is the compact but consequential example in revision 29 of draft-ietf-lamps-csr-attestation. The IESG opened Last Call on 2 September, with comments due 16 September. The document is a standards proposal. Its present value is that it gives the certification workflow a place to carry attestation evidence while refusing to pretend that carriage solves attribution.

The carrier is deliberately small. An AttestationStatement contains a type OID and a statement value. An AttestationBundle contains one or more such statements and may include certificates. One top-level bundle can travel as a PKCS #10 attribute or a CRMF extension under id-aa-attestation.

That structure answers a transport question: how can an enrollment request bring evidence with it? It does not answer four later questions: who made each claim, what object each claim describes, which Verifier and trust policy apply, and whether the combined result authorizes issuance.

The optional certificates illustrate the distinction. They may help a Verifier build a validation path. Their presence does not establish their order, select the correct trust anchor or prove that the policy attached to one chain is the policy the CA should use. A certificate is input to path construction; it is not a declaration of business authority.

The draft also does not define the enclosed statement formats or create a new registry for them. Other standards or vendors define the formats and OIDs. The type is therefore a dispatch label, not a truth label. Decoding a value is not validating its signature. Validating a signature is not deciding that its signer is trusted for this use. Trusting the signer is not proving that the statement concerns the public key in front of the CA.

Routing itself can fail quietly. If two Verifiers accept the same OID, the OID alone may not identify the right processing path. The draft points toward distinct OIDs or a format-defined wrapper hint. That hint must be protected by the relevant format. Otherwise an attacker or integration error could steer evidence toward a more permissive Verifier without changing the apparently valid bundle.

The decisive join begins at the CSR public key. Proof of possession shows that the request protocol can demonstrate control of the corresponding private key. It does not prove where the private key was generated, whether it can be exported, who owns the machine, whether the machine is healthy or whether the applicant is entitled to a certificate.

An HSM statement can narrow one of those uncertainties. Yet the CA still needs a stable relation from that HSM to the platform covered by the ownership statement. It then needs a relation from the same platform to the measurement and its epoch. Finally, it needs evidence that all of those observations belong to the same request rather than a convenient collection assembled from different machines or times.

Freshness helps, but within a smaller boundary. The companion freshness draft defines a nonce exchange for certification requests. CMP can retain transaction context. EST can keep the exchange in the same TLS session or preserve HTTP state. If the CA or RA cannot associate the later CSR with the earlier nonce, the companion says it must not treat them as associated.

The nonce is 8 to 64 octets when freshness is requested; a zero-length value signals that freshness is not being requested. A lead Attester may pass one challenge to subordinate Attesters, allowing several evidence items to answer the same nonce. That can tighten the time relation. It still cannot prove that every answer describes the same key, HSM or platform.

Nor does freshness freeze reality. RFC 9334 treats freshness as a way to reduce replay uncertainty, not as a guarantee that state remains unchanged after evidence is produced. A device can be patched, compromised, reassigned or disconnected after a successful measurement. The evidence has an epoch; the certificate will have a longer life.

The draft therefore leaves the consequential act where it belongs: with the CA or RA. That operator must decide which statement types, trust anchors, reference values and appraisal rules satisfy which issuance profile. The draft allows evidence to be tested against one of a suite of policies or discarded when it is irrelevant. It recommends putting requirements in the certification practice statement.

This is more than documentation hygiene. The policy version is part of the decision receipt. Without it, investigators may know that several Verifiers returned success but not why those results were considered sufficient on that day. The CA/RA must preserve the CSR hash and public key, statement bytes, signers, Verifier versions, reference values, nonce context, ownership record, appraisal result, selected policy and human or automated authorization.

The resulting certificate should not become a warehouse for that evidence. Platform ownership, hardware identifiers, firmware and patch state can reveal valuable operational detail. Revision 29 advises against copying the attestation information into the certificate. That reduces public exposure, but it does not erase privacy risk from enrollment logs, stored bundles or Verifier records.

Heng Lu's reality-layer discipline is useful here because every stage produces an official-looking receipt. A draft exists. A bundle parses. A signature validates. A claim passes appraisal. A CA issues. Software deploys. A relying party accepts. Each can be true while the next is false. Treating the receipts as one fact is how a carrier becomes symbolic authority.

The IETF proposal is strongest when read as a minimum coordination mechanism. It can standardize the envelope and require clearer binding without deciding every local issuance policy. Running code then supplies the discipline: the exact key, evidence, transaction and policy action must be reproducible by the operator who bears the consequence.

Sources