Summary

  • draft-ietf-rats-endorsements-11 says a Verifier needs more than a trusted list of Endorsers: it must know which Endorser may add claims about which Target Environment.
  • A valid OS-vendor signature can authenticate its source while remaining outside the vendor’s authority if it makes claims about hardware, firmware or another layer.
  • The draft permits the scope binding to live in appraisal policy, in Evidence, or in both; operators therefore need a receipt that preserves the actual binding used for each verdict.

Imagine a device whose application, operating system, firmware and hardware come from four suppliers. Each supplier can add useful context that the device cannot safely assert for itself. The operating-system vendor can identify a release train. The firmware vendor can describe a boot component. The hardware maker can associate a verification key with a root of trust.

Now remove one line from the design: which supplier is allowed to speak about which layer?

Every signature can still verify. Every certificate can still chain to a stored trust anchor. The message can remain intact from producer to Verifier. Yet the Verifier can accept an OS vendor’s statement about the hardware simply because both the OS vendor and the hardware maker appear in one trusted set. Cryptography has authenticated an actor; the system has silently enlarged that actor’s mandate.

Revision 11 of RATS Endorsements makes this failure visible. Its multiple-Endorsement example divides an Attester into application, OS, firmware and hardware Target Environments. Different vendors can supply additional claims about their own environments. The draft then states the operational consequence directly: it is not enough to say that the Verifier trusts a set of Endorsers. The Verifier must distinguish which Endorser is allowed to provide an Endorsement about which Target Environment.

The example is deliberately mundane. An OS Endorser may be trusted for the OS and not for the hardware. Nothing in that sentence alleges a compromised key or dishonest vendor. The error is a missing authorization edge. It can occur while all source-authentication checks succeed.

That edge is also not fixed to one storage location. The draft allows the Endorser-to-environment binding to be part of Appraisal Policy for Evidence, to be carried in Evidence—for example, through a claim identifying an acceptable Endorser—or to be derived from both. An Endorsement format is expected to explain how it addresses the concern, but revision 11 does not manufacture one universal wire receipt.

This flexibility is useful and dangerous. It lets a deployment fit its trust model. It also means that two Verifiers can ingest the same signed Endorsement and reach different admissibility decisions because their layer map, policy version or Evidence-supplied binding differs. A later auditor cannot reconstruct the decision from the Endorsement alone.

The distinction follows the role separation in RFC 9334. An Endorser supplies claims. A Verifier Owner remains authoritative for Appraisal Policy for Evidence. A Relying Party Owner remains authoritative for the policy applied to Attestation Results. Source, appraisal and action are three control surfaces, not three names for one trust decision.

Revision 11 adds another distinction that must remain separate. A conditional Endorsement can contain a matching rule that determines whether an Endorser’s claim applies. That matching rule concerns admission of a claim into the appraisal input; it is not itself the trustworthiness verdict. The draft’s fixed-point description—add applicable claims, repeat until no more are added—does not give the Endorser authority over the final appraisal. Nor does it answer whether that Endorser was authorized for the Target Environment in the first place.

Verification-key lookup is not a shortcut around scope. The draft notes that Evidence may contain an identity claim such as the UEID defined by RFC 9711, allowing a Verifier to locate key material. But it leaves the granularity of the identifier and key applicability—per instance, class or other claims—to protocols and procedures. Finding the right key proves neither that every claim belongs to the named layer nor that the signer may describe every component below it.

The practical evidence chain therefore needs at least seven links: fresh Evidence; the Endorser’s identity and validation path; a Target Environment identifier and layer map; the policy edge authorizing that Endorser for that environment and claim class; the selected Endorsement version; the Verifier and policy identity attached to the Attestation Result; and the Relying Party’s later authorization and enforcement outcome.

The revision history now places version 11 in IESG Evaluation and on the 8 October 2026 telechat agenda. The difference from revision 09 is inspectable. Neither fact makes the draft an RFC. The plain revision-11 text remains work in progress and can change.

The nearby CoRIM revision 11 supplies one concrete data-model context for Endorsements and Reference Values. It does not erase local appraisal authority or prove that an implementation preserves the endorser-to-layer binding correctly.

Sources