Summary

  • RFC 10013 lets a measured component carry a stable name, optional version, raw value or algorithm-bound digest, and optional component-authority identifiers. That authority identifies who can sign or authoritatively identify the component; it does not identify the attester that signed the enclosing EAT.
  • The meaning of authority entries, their order and the 64 profile-defined flag bits comes from the applicable EAT profile. A consumer that does not know the profile must reject an EAT whose measured components contain authorities or flags.
  • A usable attestation receipt joins component identity, sampling boundary, measurement, component signer, profile, outer signer, freshness, reference values, verifier policy, attestation result and the relying party’s separate authorization decision.

One token can contain several truthful cryptographic statements and still invite one false sentence.

The component digest may be correct. The authority identifier may resolve to the public key of the firmware signer. The outer Entity Attestation Token may have a valid signature from the attester. A verifier may even compare the measurement with a reference value and return a favourable result.

None of those facts means that the component signer signed the token. None means that the attester authored the firmware. And none, without the relying party’s policy, means that the device may perform the requested operation.

This is the identity boundary made unusually explicit in RFC 10013, the July 2026 Standards Track specification for an EAT measured component. Its four authors are Simon Frost, Thomas Fossati, Hannes Tschofenig and Henk Birkholz. Tschofenig’s IETF profile lists the RFC among a long security and Internet-of-Things record; Universität der Bundeswehr München says he became Professor of Secure Networks in March 2026. Those dated records explain why his work matters. They do not turn collective IETF authorship into personal control over an attestation deployment.

A component is an evidence object, not a verdict

RFC 10013 starts below the policy decision. A measured component is an object inside a target environment whose state can be sampled. It might be firmware in flash, a boot loader in memory, a file, a configuration blob or a CPU register. The format gives that sample enough structure to travel.

The component has a required name. It may have a version. Its measurement is either raw bytes or a digest paired with the algorithm used to produce it. An optional authorities array can identify one or more entities able to identify the component authoritatively, and an optional eight-byte flags field can carry profile-specific meaning.

Each field answers a narrow question. The name says which item the producer claims to have sampled. The version helps distinguish releases. The algorithm and digest preserve a comparison input. An authority identifier points toward a component-signing relationship. Flags reserve compact local semantics.

The format does not say that the sampling code could not be deceived. It does not say the name was assigned honestly, that the digest is fresh, that the reference value is approved, or that the measured state is safe for a particular workload. RFC 9711 is equally direct: EAT defines message semantics, not a universal security level for the attester or its claim collection.

That is why “the hash matched” is an incomplete operating record. A digest needs a measured target, sampling moment, algorithm, reference-value source and appraisal rule. Repeating the same correct hash from an old boot state can still be replay. Measuring the wrong component perfectly can still answer the wrong question.

The authority key lives inside a different relationship

The sharpest paragraph in RFC 10013 concerns the optional authority identifier. An authority is an entity that can identify a component authoritatively by digitally signing it. The signature may be checked when the component is installed or when boot firmware, an operating system or a launcher executes it. The key identifier may be an X.509 certificate, a raw public key, a thumbprint or another value uniquely tied to the signing key.

Then the RFC closes the shortcut: that component signature is unrelated to the attester’s signature on the EAT-formatted evidence. The authority identifier does not, by itself, indicate the signer of the enclosing EAT.

The distinction reflects two different acts. A firmware author, fleet owner, update system, app-store controller or auditor may approve a component. An attesting environment later observes a target environment and signs evidence about what it saw. One principal speaks for the component’s provenance or approval; another speaks for the evidence collection. Their keys can belong to the same organisation, but the data model does not assume that. Their keys can also be different by design.

RFC 9019 reaches a similar conclusion from the update side. Authentication identifies a manifest or firmware signer, but authorization still asks whether that signer has permission for the requested action. A critical device may require an author and an operator to approve the same installation. One valid signature is not a transferable mandate.

An audit interface that labels both keys “authority” removes the very separation the protocols preserve. It should instead display at least component authority, EAT attester and, where applicable, verifier of attestation result as different roles.

A byte string acquires meaning from its profile

The authorities array can contain multiple entries. Their purpose may vary by deployment, and even their order may carry meaning. RFC 10013 therefore requires the applicable EAT profile to declare whether the field is used, what each position represents and how the key-linked value is interpreted.

The same rule applies to the 64 bits of profile-specific flags. Fixed length does not create fixed meaning. Bit 4 cannot mean “fleet-approved” in one deployment and “debug enabled” in another unless the consumer knows which profile it is processing.

The failure rule is deliberately conservative. If the consumer does not know the EAT profile and a measured component includes authorities or profile flags, it must reject the EAT. It may not discard the unfamiliar fields, assume a common ordering or accept the token because the outer signature verifies.

This is Minimum Initial Specification in a useful form. The shared layer standardizes the envelope, core component fields and the point at which guessing becomes unsafe. Local profiles retain deployment-specific roles. Interoperability comes from an explicit semantic reference, not from forcing every fleet, manufacturer and verifier into one authority vocabulary.

It is also an operational migration constraint. A producer that begins sending a new profile before verifiers can identify it turns previously acceptable evidence into mandatory rejection. A verifier that silently accepts unknown semantics creates a wider, more dangerous split: it reports success while no one can reconstruct what its authority entries meant.

The outer signature begins, rather than ends, appraisal

RFC 9711 requires EAT authenticity and integrity protection. In the common model, an attester creates a claims set and signs the evidence with a key that authenticates the attester and its evidence. A nonce or another mechanism supplies freshness. These are necessary controls, but the RFC refuses to inflate them.

An authentic token establishes which attester key protected a particular claims set. The verifier still needs endorsement or other verification-key provenance, confidence in the attesting environment, reliable association with the target, freshness and a policy for the claims. Reference values must themselves have owners, versions and distribution history.

RFC 9334 then separates the next two decisions. The verifier appraises Evidence and produces an Attestation Result. The relying party consumes that result and applies an application-specific policy. A device can be compliant with a manufacturer baseline and still be unauthorized for an enterprise resource because it is not owned by that enterprise, is assigned to another tenant or is requesting the wrong operation.

This role chain gives the token an accountable shape:

  1. a component authority signs or identifies the component;
  2. an attesting environment samples a target and signs Evidence;
  3. a verifier applies reference values and an appraisal policy;
  4. the verifier signs or otherwise authenticates an Attestation Result;
  5. a relying party applies its own policy to a named action.

Compressing the chain into “attested device” hides who made each assertion and who can repair it.

Stable identifiers improve tracking and create tracking risk

RFC 10013 recommends keeping a component name consistent across releases because stable identity makes changes easier to follow and makes appraisal feedback more useful. That is sound operations. It is also observable continuity.

The privacy section warns that component names and versions can disclose software and configuration detail, and that stable names may enable tracking. A fleet therefore has two different correlation questions: can the verifier consistently recognize the same component across updates, and should every consumer be able to correlate that component across sessions, tenants or services?

An authority array can add further linkability if the same public-key identifier is exposed broadly. Minimization is not deletion of evidence; it is deliberate disclosure. The profile should state which party needs names, versions, authority identifiers and raw measurements, and whether a verifier can return a narrower result to the relying party.

Build the joined receipt

Start with the evidence bytes and profile. Preserve the exact EAT or its content-addressed object, media type, profile identifier and version, encoding, outer signature algorithm, attester key identifier, verification-key provenance, nonce or other freshness value, collection time and verifier receipt time.

For every measured component, record the name, version convention, target and sampling boundary. Record whether the value was raw or digested; if digested, preserve algorithm and value. Keep the component authority identifiers in their original order, the profile definition that assigns each role, the corresponding component-signature evidence and its verification result. Decode flags only against that profile and retain the raw eight bytes.

Next preserve appraisal. Identify the reference-value provider, reference set and version, every comparison result, omitted or unavailable measurement, verifier policy and policy version. Record the verifier identity and exact Attestation Result.

Finally record the relying-party act: principal or device, requested resource and operation, applicable policy, decision, restrictions, expiry and remediation route. A deny because the profile is unknown is different from a deny because the outer signature fails, a digest mismatches, Evidence is stale, the component authority is unacceptable or a compliant device lacks resource authorization.

Running code is the decisive observation surface, but only if it exposes these joins. A green badge without profile, keys, freshness and policy is not a receipt. It is a colour.

Sources