Summary

  • RFC 10013 defines a compact measured-component object: a required component name and raw or digested value, with optional version, component-signing authorities and profile-specific flags. It can be carried in JSON or CBOR inside an EAT Measurement claim.
  • The object is evidence, not a verdict. Its component authorities do not identify the signer of the enclosing EAT; a digest match does not prove that the right state was sampled; and a successful appraisal does not establish that the device is owned, enrolled or entitled to a resource.
  • A defensible system preserves the full decision chain from measurement scope and freshness through Reference Values, Verifier policy, Attestation Results and the Relying Party’s authorization rule. A green badge that discards those boundaries becomes an unreviewed concentration of authority.

Every check was green

Consider a hypothetical network-admission service bringing a repaired edge appliance out of quarantine.

The appliance produces a fresh Entity Attestation Token. Its signature verifies against the expected attester key. The token contains a measured component named boot loader X, a Semantic Versioning value and a SHA-256 digest. Two entries in the authorities array correspond to approved component signers. The EAT profile is recognized. The digest matches the production Reference Value. The Verifier returns “compliant”.

The admission dashboard turns green.

That sequence establishes useful facts. It does not establish that the appliance should reach the control network.

Perhaps the sampler covered the signed boot loader but not the mutable policy file that tells it what to load next. Perhaps a late-loaded module lives outside the measured region. Perhaps the accepted reference set still includes a release whose vulnerability was disclosed yesterday. Perhaps the device is genuine and healthy but belongs to a contractor rather than the fleet. Perhaps it is enrolled for telemetry and not for administrative access. Perhaps the authorities array was interpreted under a profile different from the profile that created it.

None of those possibilities makes the measured-component object defective. They expose the boundary of what the object says.

RFC 10013, published in July 2026 on the IETF Standards Track, gives remote-attestation systems a reusable way to describe sampled component state. Its value lies in disciplined modesty. It makes evidence portable without pretending to decide which evidence should produce which consequence.

A component is a selected object, not the whole machine

The standard’s “measured component” can be firmware stored in flash, software loaded into memory at startup, a run-time integrity check, a file-system object, a configuration blob or a CPU register. That breadth is intentional. Earlier EAT work could carry a CoSWID evidence tag, but RFC 9393 is built around software identification and inventory. It does not naturally describe every early-boot, register or non-filesystem measurement.

RFC 10013 fills the representation gap. It does not choose the measurement boundary.

That distinction is the first authority decision. A platform designer decides what counts as one component. A collector decides where sampling starts and stops. A protected execution environment may make that collection harder to forge, but it still measures the object it was instructed to measure. A perfect digest of an incomplete object is perfect evidence about an incomplete object.

Operational records therefore need more than a value. They need the target environment, component boundary, collection mechanism, boot epoch or time, and the dependencies deliberately left outside the sample. If those choices disappear behind a label such as “secure boot passed”, the label has acquired authority the protocol did not grant it.

This is where Running-Code Primacy supplies a practical test. The standard defines the common claim. Running evidence must show which bytes were sampled, which code later executed and what access the system actually granted. The symbol cannot outrank the system it describes.

The small object carries several different assertions

At the information-model level, a measured component has a required name, an optional version, a required raw or digested value, a digest algorithm when the value is digested, and optional authorities. The concrete JSON and CBOR forms add an optional eight-byte flags field whose meaning belongs to an EAT profile.

Each field answers a different question.

The component name is a human-readable identifier. Its format and convention depend on the component type. RFC 10013 asks that it remain consistent across releases because stable naming helps a Verifier track the same item through updates. It does not create a global component namespace. Two vendors can use similar names; one vendor can change conventions; a path such as /boot/loader.bin can identify a location without proving that the same semantic object always occupies it.

The optional version can add release context and may reuse the version-scheme vocabulary from CoSWID. Semantic Versioning is recommended, not imposed on hardware registers, configuration objects or every firmware ecosystem. A version string becomes reliable only when the producer’s scheme, release process and mapping to measured bytes remain auditable.

The value is either raw bytes or a digest. Raw form avoids reducing the sample to a fingerprint, but its size can vary from one register to an entire configuration blob. RFC 10013 allows a decoder to cap memory for this field. A consumer that accepts an unbounded raw value has turned evidence parsing into a resource-exhaustion surface.

A digested value carries an algorithm identifier and digest bytes. The identifier maps to the IANA Named Information Hash Algorithm registry, and the RFC requires a strong hash. That requirement protects the comparison from weak cryptographic construction. It cannot prove the sampler read the intended bytes, the Reference Value represents acceptable software, or the evidence describes the present boot.

Two kinds of signer must not become one

The authorities array creates the article’s most important naming trap.

In RFC 10013, a component authority is an entity capable of authoritatively identifying the installed component by digitally signing it. Its identifier can be an X.509 certificate, raw public key, key thumbprint or another value uniquely associated with the signing entity. Component signatures may be checked during installation, as in the update architecture described by RFC 9019, or by boot firmware, an operating system or an application launcher.

That signature is explicitly not the attester’s signature on the enclosing EAT evidence.

One key may say who approved a firmware artifact. Another key says which Attester produced this token. The first is provenance for the installed component. The second protects the claim set and connects it to an attesting environment. Treating the component signer as the EAT signer erases an entire trust boundary.

The array can also contain several authorities: perhaps an update system, a fleet owner and an auditor. Entry order may carry meaning. The base standard does not assign those meanings. The applicable EAT profile must state whether the field is used, what every entry represents and how its bytes are interpreted.

The same rule governs flags. The field is exactly 64 bits, but the base standard does not define a single bit. If authorities or flags appear and the consumer does not know the profile, it must reject the EAT. Retaining the payload while guessing a familiar bit layout is not tolerant interoperability; it is silent policy invention.

JSON and CBOR solve transport, not judgement

RFC 10013 deliberately coordinates JSON and CBOR data models. A CBOR EAT can carry a CBOR measured component in a homogeneous form or tunnel JSON. A JSON EAT can carry JSON directly or tunnel base64url-encoded CBOR. IANA registers application/measured-component+cbor and application/measured-component+json, and the CoRE Content-Formats registry assigns values 295 and 296.

Those registrations let a consumer identify the representation. They do not certify the producer or standardize a verdict.

The separation reflects the constructive rule in Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption. The common layer can specify the smallest semantics required for exchange: identity, value, authorities, flags and their encodings. Future profiles and deployments decide what a signer means, which references are acceptable and what consequences follow. Interoperability improves when those local decisions are explicit, not when the base object is made to impersonate them.

The official RFC 10013 errata search returned no matching errata on 30 August 2026. That is a dated registry observation. It is not proof that every implementation has interpreted the model correctly.

EAT protects claims without assigning their security level

RFC 9711 defines the Entity Attestation Token as a claims message. It is unusually clear about the limit: the specification defines semantics for claims, but it does not require a particular security level in the claim implementation or even in the Attester.

A receiver understands claim trustworthiness by understanding how the vendor implemented the Attester and/or what checks the Verifier performed. An EAT can originate in highly defended hardware. It can also originate in a lower-security application. The shared format does not flatten that difference.

Freshness is mandatory in every EAT use. A nonce, timestamp or other architecture-appropriate mechanism prevents a valid old statement from masquerading as current state. Yet freshness of the token is not automatically freshness of every measurement. A measurement may have been collected at boot and included later. A production record should retain when the state was sampled, when the token was issued and which boot epoch connects them.

EAT also distinguishes a measurements claim from measres, its measurement-results claim. measres can report that a comparison with expected values succeeded, failed, was not run or was absent. RFC 9711 says it is not the overall result of a Verifier. A user interface that renders measres=success as “device trusted” has compressed comparison, appraisal and authorization into a field that was not designed to carry them.

The predecessor PSA Attestation Token in RFC 9783 illustrates why policy matters. A Verifier might require an exact measurement value, accept one of several releases, or rely more generally on a recognized signer. Those policies answer different risk questions. The token cannot choose among them on behalf of the operator.

The Verifier owns appraisal; the Relying Party owns consequence

RFC 9334 gives the authority chain names.

The Attester creates Evidence. A Reference Value Provider supplies expected values. An Endorser vouches for capabilities or trust foundations. The Verifier applies Appraisal Policy for Evidence and produces an Attestation Result. The Relying Party uses that result under its Appraisal Policy for Attestation Results to decide which data or operation the Attester may access.

Combining roles in one service is allowed. Eliminating their logical responsibilities is not.

A matching Reference Value means the evidence satisfied a comparison under a particular set. The set has an owner, version, effective time and withdrawal history. When a vulnerability is published, an unchanged digest can move from acceptable to forbidden without one bit changing on the device. The authority that updates the reference or appraisal policy therefore controls a security decision even though it never touches the device.

An Attestation Result can summarize heterogeneous, vendor-specific evidence into a form the Relying Party understands. That convenience concentrates trust in the Verifier. The Relying Party must know which Verifier, policy version, evidence strength and freshness produced the result.

Most importantly, health is not entitlement. RFC 9334 notes that an enterprise may accept a manufacturer’s healthy devices as a class for one purpose yet still need device-specific proof that it owns the laptop before granting network access. A genuine, correctly measured contractor device remains a contractor device.

The final decision belongs where the consequence lands. The Relying Party knows the resource, requested operation, account, ownership, enrollment, transaction value and current incident posture. The Verifier can say what it appraised. It cannot silently decide every business authorization downstream.

A complete audit follows the arrows

A mature system should be able to reconstruct:

measurement boundary → collector and collection time → raw or digested value → component naming convention → component-signing authority meaning → EAT signer and freshness → profile interpretation → Reference Value and provider → Verifier policy and result → Relying Party policy → granted operation → observed outcome.

That sequence should not be stored as one boolean.

When an incident occurs, the difference is decisive. If the wrong software was admitted, investigators need to know whether the collector omitted it, the reference set approved it, the Verifier misapplied policy or the Relying Party granted more than the result justified. Without the intermediate evidence, every team can point to the same green badge and no team owns the decision.

Heng Lu’s reality-layer analysis is useful here. The name, version, digest, signer identifier and result are symbolic representations of selected physical and operational state. Their authority grows when their boundaries are explicit. It becomes dangerous when a representation is treated as the reality itself.

Privacy follows the evidence beyond the token

Component names and versions can reveal the exact software, patch level or configuration of a device. RFC 10013 warns that this information can help an attacker and that stable component naming can enable tracking. Raw measurements can reveal still more.

Multiple consumers deepen the problem. One service may decrypt and validate an EAT, then send claim subsets to specialist consumers. RFC 9711 requires equivalent communication protection when the original token protection has been removed, and it recommends minimizing exposure to each consumer.

Formal ownership of the fleet does not answer who can read the evidence. The practical-data-sovereignty distinction requires an inventory of every receiver, log, trace, analytics store and downstream evaluator that can retain component identity or raw state. A device owner may control the hardware while a verification chain holds the more revealing operational map.

The correct default is selective disclosure tied to purpose. The network-admission Verifier may need a current appraisal result, not the full configuration blob. A remediation service may need the component version, not the device’s universal identity. Reuse should be justified claim by claim.

The standard’s narrowness is the security property

RFC 10013 succeeds by refusing to declare a device good.

It gives independent systems a shared object for component evidence. It makes JSON and CBOR implementations converge. It forces profile authors to define authority and flag semantics. It requires strong digests and rejection when profile-dependent fields cannot be understood. It warns that stable names and versions reveal information.

Everything after that is responsibility, not missing protocol.

The sampler owns the boundary. The Attester owns the evidence-generation claim. The component signer owns artifact provenance. The Reference Value Provider owns the expected state it publishes. The Verifier owns appraisal. The Relying Party owns authorization. Operators own the consequences of combining those decisions.

A measured component can identify itself. Only the full chain can justify what happens next.