Summary

  • RFC 9999 gives Evidence, Endorsements, Reference Values, Attestation Results and Appraisal Policies a common, self-describing wrapper across CBOR, JSON, JWT, CWT and X.509 environments.
  • A Record, Tag or Collection CMW supplies structure and typing, not authenticity, integrity, confidentiality, composite-device identity or a final access decision.
  • When one Collection represents a composite device, its Evidence items must be cryptographically bound; the Verifier still appraises them, and the Relying Party still decides what the result permits.

Picture a confidential-computing server entering a restricted cluster. Its main processor emits Evidence about the boot chain. A SmartNIC reports its own firmware state. A GPU attesting environment reports a third state. A collection daemon puts all three objects under one label set and sends the bundle to a verifier.

Now replace only the SmartNIC item with valid Evidence copied from a healthy machine. Every individual signature may still verify. Every media type may still be recognized. The collection may still parse. Yet the bundle no longer describes one machine. A green parser and three green signatures can produce a false composite claim when nothing proves that the parts share a device, session and appraisal context.

That substitution attack is the authority seam inside RFC 9999, Remote ATtestation procedureS (RATS) Conceptual Message Wrapper. Published in July 2026 as an IETF Standards Track document, the RFC creates a common envelope for the conceptual messages defined by the RATS architecture. It improves transport and dispatch. It does not turn the envelope into the truth it carries.

Five messages, five different functions

RFC 9334 defines the roles before it defines the artifacts. An Attester produces Evidence. A Verifier combines Evidence with Endorsements, Reference Values and an Appraisal Policy for Evidence, then produces an Attestation Result. A Relying Party consumes that result under its own Appraisal Policy for Attestation Results and applies an application-specific action.

RFC 9999 preserves those distinctions in a five-bit indicator registry. Bit positions 0 through 4 identify Reference Values, Endorsements, Evidence, Attestation Results and Appraisal Policy. A Record CMW contains a media type or CoAP Content-Format, the serialized value and, when ambiguity requires it, an ind bitmap naming one or more conceptual-message functions.

The indicator helps a receiver answer “what kind of RATS artifact should handle these bytes?” It does not answer “is this artifact acceptable?” Reference Values may be stale. An Endorsement may come from an untrusted manufacturer key. Evidence may be genuine but outside the freshness window. An Attestation Result may be correct for one verifier policy and irrelevant to another Relying Party. An Appraisal Policy may itself have been modified by an attacker.

That distinction is operationally valuable because CMW is designed to keep a core processor agnostic. Explicit typing selects a plug-in or message handler; the inner object can remain opaque while it crosses the core. Demultiplexing is therefore routing authority, not appraisal authority. A component that can choose a decoder should not silently acquire the right to approve a device.

The wrapper is a tree, not a verdict

RFC 9999 defines Record and Tag CMWs as leaf forms. A Record names the serialized format directly. A CBOR Tag CMW derives its tag number from a CoAP Content-Format. A Collection CMW is an intermediate node that groups labeled CMW items and can contain further collections.

The collection form serves real hardware. A data-centre server may have separate attesting environments for the main CPU, a SmartNIC and a GPU. Their Evidence formats need not match. A collection lets a protocol preserve those differences without inventing a new outer grammar for every platform combination.

But Collection is broader than “one device”. The RFC permits mixed conceptual-message types and messages concerning multiple devices. The optional __cmwc_t URI or OID gives the overall collection a type and supplies a namespace in which labels can be interpreted. It may describe an allowed assembly. It is still metadata. Unless protected and validated, a collection type is a claim about structure, not proof of structure.

The tree is recursive, so implementations may limit nesting depth. That small sentence has a large operating consequence. Two conformant implementations can accept different depths. A gateway that unwraps one level while a verifier accepts four can create semantic gaps, resource-exhaustion exposure or policy paths that were never reviewed. A deployment needs one explicit maximum and a failure rule; “the library parsed it” is not a cross-system contract.

Binding is the missing sentence between three signatures

RFC 9999 states the security boundary without euphemism: Record, Tag and Collection CMWs alone do not provide authenticity, integrity or confidentiality. The document specifies ways to sign a CBOR CMW with COSE_Sign1 and a JSON CMW with JWS, and it allows CMW to travel as a cmw claim in CWT or JWT. These are available protection mechanisms, not automatic properties of the wrapper.

For a Collection used as Evidence for one composite or layered device, all Evidence messages must be cryptographically bound together. The rule exists to prevent the healthy-device substitution described above. Binding may be an object-security signature over the entire collection. It may also be internal: common identifiers, linked nonces, inter-item signatures or hashes. The Attester that creates the Collection is responsible for protecting its contents.

The method changes what can be concluded. An outer signature from a collection daemon proves that the daemon signed those bytes; it does not necessarily prove that the daemon is part of the device's attestation root. Matching serial-number claims prove little if any member can assert the serial number. A shared nonce can connect a session, but only if the nonce reached each attesting environment through an authenticated path and every response binds it. Hash links can protect ordering and membership while saying nothing about whether the signer represents the claimed component.

An audit record therefore needs to preserve protection scope, not merely signature_valid=true. It should identify the raw Collection hash, outer wrapper form, collection type, item labels, inner media types and indicators, signer and key identifier, freshness material, device-binding claim, nesting depth, binding mechanism and verification transcript. Otherwise later reviewers cannot tell whether the cryptography covered each leaf, the collection assembly or only a transport token around it.

A new carrier creates a new trust boundary

CMW is built to travel. RFC 9999 registers application/cmw+cbor, application/cmw+json, application/cmw+cose and application/cmw+jws, plus JWT and CWT cmw claims. It also defines an X.509 extension for carrying a CMW object in certificates, certificate requests and revocation lists.

Each carrier can protect a different surface. A JWS may sign the JSON collection but not an Evidence object that is later extracted and cached. A JWT may authenticate its issuer while the nested collection comes from another producer. TLS protects a channel between two endpoints, not necessarily the origin of a forwarded inner artifact. Re-encoding CBOR into JSON can preserve meaning while invalidating byte-level signatures or destroying the exact object needed for forensic replay.

The hosting protocol owns the integration contract. RFC 9999 requires it to explain which conceptual messages and combinations are allowed, what protection is required, how CMW interfaces with the host and how their security models interact. A protocol that merely says “the payload is CMW” has delegated syntax and omitted authority.

The X.509 rule makes the risk unusually visible. The CMW extension should normally not be critical. It may be marked critical when the wrapped message is essential to granting access and a legacy Relying Party might otherwise ignore the extension and bypass the control. Criticality is not a formatting preference here; it decides whether an unaware implementation fails closed or proceeds without the attestation condition.

Certificates also expand the disclosure domain. Evidence can contain personally identifiable information or operational details such as HSM model and patch level. A requester may disclose those facts to a Certification Authority without consenting to publish them in a widely distributed certificate. RFC 9999 calls for a clear certification-practice statement when a CA would broadcast third-party Evidence in that way. A durable credential can convert a momentary appraisal input into long-lived reconnaissance.

An Attestation Result is still not an authorization

The most tempting collapse happens at the end of the chain. A verifier emits a positive Attestation Result. A gateway has an access decision to make. Treating the result as the decision removes the Relying Party's policy, scope and accountability.

RFC 9334 keeps two policy owners separate for a reason. The Verifier Owner controls the policy used to appraise Evidence. The Relying Party Owner controls how Attestation Results affect an application action. The same valid result may permit a low-risk telemetry connection, require quarantine for a control-plane session and be insufficient for a key-signing operation. Time, network zone, requested capability and business exception all belong to the relying context.

A robust decision record therefore joins but does not merge the layers: Evidence set and binding transcript; Endorsement and Reference Value revisions; Verifier policy and Attestation Result; Relying-Party policy and requested action; final permit, deny, limit or quarantine outcome. If the system stores only the final Boolean, it loses causality. If it stores only the result token, it loses the authority that applied it.

This is the practical connection to Heng Lu's running-code principle. The formal envelope is necessary provenance, but execution reveals whether handlers, verifier policy and access enforcement respected the intended separation. Minimum Initial Specification supports the thin common grammar: type the message, carry it consistently, register extension points. Local decisions must still define binding, permitted combinations and consequences. Reality Layers prevents a type bit, signature, verdict and access action from being mistaken for the same fact.