Summary

  • RFC 9999 gives RATS Evidence, Attestation Results, Endorsements, Reference Values and Appraisal Policies a self-describing wrapper that can cross CBOR, JSON, JWT, CWT, X.509, HTTP, MIME and CoAP environments.
  • A Record, Tag or Collection CMW provides structure and dispatch information, not authenticity, integrity, confidentiality, freshness, semantic appraisal or authorization.
  • When a collection represents one composite or layered device, its members require whole-collection protection or verifiable intra-item binding; otherwise valid Evidence from a healthy component can be substituted for a compromised one.

The access request looked unusually complete. A server presented a collection with three entries: one for the main CPU, one for a SmartNIC and one for a GPU. The media types were recognised. The decoder selected the expected handlers. The signatures inside the three payloads verified. An automation dashboard painted the bundle green.

There was still one unanswered question: what joined those three reports to this server, in this configuration, during this transaction?

If the CPU report came from the requesting server, the SmartNIC report came from a healthy spare, and the GPU report was replayed from yesterday, each item could remain well formed. Each signature could be genuine. The collection could still tell a false story about the machine as a whole.

That is the authority boundary inside RFC 9999, the IETF Standards Track specification for the Remote ATtestation procedureS Conceptual Message Wrapper, or CMW. Published in July 2026, it solves a real interoperability problem. The RATS architecture has several kinds of conceptual message, and each kind may appear in several claim encodings, serialisations and transport protocols. A common wrapper lets a protocol carry new attestation technologies without redesigning its core for every format.

The achievement is important precisely because it is narrow. CMW tells software what kind of object it has received and how to hand that object to the right processor. It does not decide whether the object deserves belief.

What the wrapper actually standardises

RFC 9334 defines the RATS roles and the meanings of the messages that move among them. An Attester produces Evidence. A Verifier combines that Evidence with Endorsements, Reference Values and an Appraisal Policy, then produces Attestation Results. A Relying Party applies its own policy to those results before it grants access, releases a key, accepts a command or takes another application-specific action.

RFC 9999 does not collapse those roles. It gives their messages a common outer structure.

A Record CMW contains a type, an opaque value and, when needed, an optional ind bitmap. The type is a media type or CoAP Content-Format. The indicator can say that the value contains Reference Values, Endorsements, Evidence, Attestation Results or an Appraisal Policy. This helps when the media type is not sufficiently specific or one payload carries more than one conceptual-message kind.

A Tag CMW uses a registered CBOR tag derived from a CoAP Content-Format through the mechanism in RFC 9277. A Collection CMW groups labelled CMW items and can contain other collections. The live IANA RATS registry coordinates the conceptual-message indicator bits, while related registries coordinate media types, claims and content formats.

These are dispatch controls. A type can select an EAT handler; it cannot prove that an EAT's claims are true. An indicator can say “Evidence”; it cannot prove that the producer was entitled to make the assertion. A registry entry can prevent identifier collision; it cannot guarantee that a verifier supports the profile or applies a current policy.

RFC 9711 defines the Entity Attestation Token, and RFC 9782 supplies EAT media-type conventions. Those standards make semantic and format negotiation more precise. They do not turn content-type recognition into device trust.

A container is not a security boundary

RFC 9999 says the point without euphemism: CMW is encapsulation, not a security format. Record, Tag and Collection CMWs alone provide no authenticity, integrity or confidentiality.

Protection can exist at several layers. The conceptual message may already be signed. A CBOR CMW can be protected with COSE structures from RFC 9052. A JSON CMW can be protected with JWS from RFC 7515. A secure channel can protect bytes in transit. The hosting protocol may add challenge-response and anti-replay controls.

Those scopes matter. A transport channel says who participated in one connection; it does not automatically preserve evidence after forwarding or storage. Three individually signed members say that three signers endorsed three byte strings; they do not necessarily say that the strings belong together. A signature over the collection protects the assembly, but only if the trusted signer is authorised to assert that assembly and the signed profile identifies what the assembly means.

The contrast is clearest with RFC 9781. An Unprotected CWT Claims Set is exactly that: unprotected. Putting a UCCS into a CMW makes it easier to identify and carry. It does not make the claims authentic. RFC 9999 therefore shows how protection can be added around such a record. The wrapper did not cure the missing security property; another layer supplied it.

This is the first operating rule: record protection by scope. For every accepted object, an operator should be able to say which bytes were protected, by which key, for which audience, under which profile, and whether that protection survives forwarding, caching and extraction.

The composite-device substitution problem

The collection feature addresses a practical reality. A data-centre server may have separate attesting environments for its CPU, SmartNIC and GPU. A carrier router may have a chassis and several independently attesting slots. A layered boot chain can produce Evidence at several stages. The formats need not be homogeneous.

A Collection CMW can carry them without pretending they share one encoding. But collection membership alone is not a proof of common origin. RFC 9999 requires all Evidence messages used for composite or layered attestation of a single device to be cryptographically bound together. Without that protection, an attacker could replace Evidence from a compromised part with Evidence from a healthy device and invite the Verifier to accept the composite.

The standard deliberately permits more than one binding design. An Attester can sign the entire collection. Members can share identifiers or a nonce. They can cross-sign or hash one another. A hosting protocol can define another construction that establishes the necessary relationship. The decisive question is not whether the bundle has a signature icon; it is whether the validated scope proves the claimed member-to-device and member-to-transaction relationship.

Nor does every collection claim to represent one device. RFC 9999 allows collections of Endorsements, Reference Values or Attestation Results and permits material concerning multiple devices. That flexibility prevents a dangerous shortcut: “same collection” cannot be a universal synonym for “same machine”. The optional collection type or assembly profile must give labels their namespace and explain the intended composition.

Labels are only unique within their collection, and entry order has no meaning. A label such as gpu is useful to an agreed profile; outside that profile it is a mnemonic, not a globally authoritative component identity. An inventory, device identifier, topology epoch and profile version must still connect the label to installed reality.

Recursion moves risk into the parser

Collections are recursive. This enables layered devices and composite assemblies to mirror real structure, but it also creates a resource-control problem. Implementations may limit nesting depth, and an API might advertise a maximum, yet RFC 9999 leaves the exact discovery and negotiation mechanism out of scope.

Production policy therefore needs explicit budgets: total bytes, member count, nesting depth, decompression or base64 cost, handler time, cryptographic operations and maximum fan-out to external endorsement or reference-value services. A byte that successfully selects a decoder is not permission to consume unbounded memory or initiate an unbounded validation graph.

Unknown types also need a decision. A storage or forwarding service may be able to preserve an opaque CMW safely. An authorization service cannot quietly ignore an unknown member and then claim that a composite device passed. “Unsupported”, “invalid” and “not required by this profile” are separate states. Collapsing them rewards the path that validates the least evidence.

The running inventory must therefore pair every accepted type with a handler version, supported profile, algorithm policy, resource budget and failure behaviour. The IANA registry supplies names. The operator supplies consequences.

Freshness is not printed on the envelope

Attestation asks about state at a relevant time. A perfectly valid report from last week may be useless after firmware changes, a component swap or a policy update.

RFC 9334 treats freshness as a separate problem and describes synchronized time, nonces and epoch identifiers. A CMW can carry material involved in any of those schemes, but successful parsing does not prove that the challenge was current, the nonce was bound to every required member or the epoch matches the requesting service.

For a composite machine, the operator needs a coherent freshness rule. If the CPU Evidence is bound to nonce A, the SmartNIC to nonce B and the GPU only to a timestamp, policy must explain whether those proofs belong to one transaction. The safe answer cannot be inferred from the outer collection. It belongs to the assembly profile and the Verifier's appraisal policy.

The evidence record should retain the challenge, its issuer, validity window, clock assumptions, epoch identifier and member coverage. “Signature valid” is not a freshness verdict.

Appraisal and authorization remain different powers

RFC 9334's most useful governance distinction is between trustworthiness and trust. The Verifier appraises Evidence. The Relying Party decides what to do with the Attestation Results.

A device can satisfy a firmware policy and still lack permission to read a particular customer dataset. It can be trustworthy enough to join a maintenance network but not to sign production releases. An Attestation Result can be authentic and current while the Relying Party's business context has changed.

CMW makes it easier to carry Evidence and results across those roles. That makes provenance more important, not less. Operators should record the Verifier identity, reference-value set, endorsements, appraisal-policy version, Attestation Result, Relying Party policy version and resulting action. Otherwise a portable result can be replayed into a decision context that never authorised it.

The closeout chain is therefore longer than “CMW accepted”. It is: expected members enumerated; bytes decoded; protection validated; members bound to the claimed device and transaction; freshness established; Evidence appraised under the intended policy; result delivered to the intended Relying Party; application decision recorded; effect observed.

Portability can widen disclosure

RFC 9999 permits CMWs in X.509 certificates, certificate requests and revocation lists. That is operationally attractive because existing PKIX channels can carry attestation material. It can also make private hardware facts durable and widely visible.

Evidence may reveal hardware model, patch level, stable device characteristics or other personally identifiable information. A certificate requestor might be willing to disclose those facts privately to a Certification Authority but not to every party that later receives a public certificate. RFC 5280 supplies the general certificate profile; it does not supply consent for this new disclosure. RFC 3647 supplies a framework for stating certificate policy and certification practices. RFC 9999 recommends that a practice statement define when a CA may include third-party Evidence.

The privacy control is not merely encryption in transit. It is audience minimisation, claim minimisation, retention, certificate-profile review and an explicit rule against moving private Evidence into a globally redistributed object without authority.

Portability changes the blast radius. An opaque item that once lived inside a short-lived attestation exchange can become a JWT claim, certificate extension, stored file or forwarded API object. Every new carrier inherits the duty to preserve protection and restrict disclosure.

The proof is in the executed chain

Heng Lu's running-code principle is useful here because a CMW can be formally perfect while the operational decision is wrong. The meaningful evidence is the code path that selected a handler, validated the exact bytes, checked the signer and binding, established freshness, ran a named policy and produced an observed effect.

His argument for a minimum shared specification and local future decisions also fits the division of labour. A common wrapper and registry lower integration cost. They need not centralise every device-health threshold or authorization rule. Those decisions can remain local, provided an accountable owner accepts the liability and records the policy.

Finally, the reality-layer distinction keeps four true statements apart: the object conforms to CMW syntax; a cryptographic mechanism protects a defined scope; a Verifier appraised the content; a Relying Party allowed an action that actually occurred. None is a decorative restatement of another.