Summary

  • The RATS Call for Adoption for draft-poirier-rats-eat-da-10 ends on 11 September 2026. It asks whether the group should take on an individual draft; it is not an adoption outcome, an RFC or a deployment instruction.
  • A Device Assignment Token can make device evidence portable. It does not choose additional constraints, appraise evidence, set a relying party’s policy, authorize a device or own the loss from a wrong decision.

The call concerns a work item, not a trusted device

The public call is precise about its object: An EAT Profile for Trustworthy Device Assignment, revision 10. The Datatracker still labels it an active Internet-Draft and a candidate for RATS work, not an IETF-endorsed document with formal standards standing. The stated closing date, 11 September, makes the immediate question even narrower. Participants may support, oppose, qualify or ask for work on the draft. A later working-group disposition would answer a process question. Neither state turns any particular adapter, accelerator or virtual function into an accepted member of a trusted computing base.

That restraint matters because the draft is about a consequential setting. Device assignment can put a network adapter, GPU or other PCIe device under a Trusted Virtual Machine’s control, while software outside that machine may be untrusted. The draft says the machine needs evidence about the device’s identity, firmware and configuration before it can trust the device. It then defines an EAT profile—the Device Assignment Token, or DAT—to represent that evidence in an interoperable form.

Representation is a real contribution. Without a common format, different parties can label, nest, sign and transport similar observations in incompatible ways. A profile can make it easier to say what a device asserted, which submodule a claim concerns and which envelope a recipient received. But it does not make the observation complete, current, sufficient for a particular workload, or acceptable under a particular owner’s risk policy. Interoperability reduces ambiguity in the record; it does not erase the decision that follows the record.

The draft keeps constraints outside the format

The draft makes the separation unusually explicit. It is based on information supplied by SPDM and “does not impose additional security constraints.” Other entities must describe, select and enforce those constraints according to operational requirements. That sentence is not a gap that an enthusiastic reader may fill by assumption. It identifies the remaining control surface.

An owner must still decide which trust anchors are acceptable, which firmware or configuration states are permitted, how fresh evidence must be, what revocation information matters, which verifier is trusted, whether a result can be forwarded, and whether the decision is reversible. A hospital running a confidential workload, a cloud tenant handling a sensitive key and a platform operator sharing a GPU can rationally set different limits while using the same token syntax. Their losses, duties and tolerance for a false acceptance are not interchangeable.

The scope boundaries reinforce the point. The current text focuses on SPDM-compliant PCIe devices. It leaves on-chip SPDM-compliant devices for future consideration and says that live migration of a Trusted Virtual Machine is not covered. No format should be advertised as a universal security conclusion when its own text names architectures and lifecycle events beyond present coverage.

A verifier result is not the relying party’s authorization

RATS architecture supplies the needed division of labour. RFC 9334 assigns Evidence appraisal to a Verifier, which uses evidence, reference values, endorsements and an appraisal policy to produce Attestation Results. It separately assigns a Relying Party the task of applying its own appraisal policy to those results for an application-specific decision, including authorization. The two policies can be supplied or configured by different accountable owners.

RFC 9711 adds an important caution. An EAT may be used to describe an entity for a relying party’s trust decision, but the specification does not establish normative processing rules for verifiers. A verifier can forward, modify or supplement claims under its own policy; a relying party must understand those processing rules before interpreting a result. A valid token signature and a well-formed profile are therefore evidence about an artifact, not a portable instruction to permit a device.

The RATS charter is consistent with that architecture. It covers formats and procedures for evidence and attestation results and their conveyance. It explicitly leaves formats and protocols for appraisal policies out of scope. That is a practical division, not a failure of standardisation. It lets a common format travel without pretending that a working group can decide every organisation’s security appetite.

The receipt needs two layers

The public layer should stay thin and testable: the adoption call, its date, the exact draft revision, the profile’s stated coverage, the explicit no-additional-constraints sentence, the feedback and any later disposition. It should never be inflated into “RATS approved this device” or “the IETF authorized this workload.”

Beside it, the operator needs a local decision receipt. It should identify the device and assignment context, source of evidence, accepted trust anchor, verifier identity and processing rules, reference values, freshness requirement, accepted policy version, authorization scope, responsible owner, monitoring and rollback path. Those entries identify who made the judgment and who can revisit it when firmware, policy, revocation information or workload conditions change.

The next evidence worth watching is a recorded outcome of the adoption call, a later RATS revision and any explicit narrowing or extension of the profile. For a deployment claim, the decisive records are elsewhere: a relying party’s policy, a verifier’s appraisal basis, an authorization decision and observed operational evidence. Keeping those records distinct protects the value of the shared format instead of asking it to impersonate authority it cannot possess.

Sources

  1. RATS Call for Adoption: draft-poirier-rats-eat-da-10
  2. Datatracker record for An EAT Profile for Trustworthy Device Assignment
  3. draft-poirier-rats-eat-da-10
  4. RATS Working Group charter
  5. RFC 9334: Remote ATtestation procedureS Architecture
  6. RFC 9711: Entity Attestation Token