Summary

  • CBOR tag 601 marks a CWT Claims Set with no object-level signature, MAC or encryption; the tag identifies a format, not a source.
  • In RATS use, assurance comes from a suitably authenticated, integrity-protected channel and lasts only inside its defined context. Replay handling and disclosure authorization remain explicit checks.
  • Once the receiver extracts, stores or forwards the UCCS, the old channel no longer protects the artifact. RFC 9781 treats onward claims as originating within the receiver, so lineage and new protection need their own receipts.

One hash, two very different assertions

Imagine a verifier that accepts a UCCS over a mutually authenticated channel, hashes the received bytes, decodes the map and stores both in a database. Hours later, a policy service reads the row. The hash still matches. The claims still carry issuer, subject and freshness fields. Tag 601 is still present.

What has disappeared is the channel.

The database reader did not observe the handshake, validate either endpoint credential or receive the protected records. A matching hash can connect its copy to a byte string captured earlier. It cannot, by itself, connect those bytes to the authenticated sender, the accepted session, the application role assigned to that endpoint or the policy that allowed disclosure. The first receiver may have preserved that chain. It may also have preserved only the payload.

RFC 9781 exists for a sensible economy. A normal CWT is wrapped in COSE, which can provide end-to-end origin authentication and integrity and may provide encryption. Some deployments already possess a secure association between the exact roles exchanging the claims. On a constrained device, applying another envelope can add code, bytes and key handling without changing the required trust path. UCCS allows the CWT Claims Set to travel without COSE when another mechanism supplies the necessary protection.

The format is deliberately modest. In CDDL, the tagged form is #6.601 around a Claims Set. The tag tells a decoder what the map represents. It does not name the session, identify the sender, prove that a nonce is fresh or state which receiver may act. IANA's registration makes the identifier stable. It does not make the data self-authenticating.

The assurance belongs to a context

For RATS conveyance, RFC 9781 requires the receiver to authenticate the sender during establishment of the secure channel, and the channel must protect integrity between the communicating roles. Where confidentiality is required, the receiving side must also be authenticated. That last condition is not decorative: a sender should not disclose device evidence merely because it has reached an encrypted endpoint. It needs confidence that the endpoint is the permitted receiver.

The word “channel” can hide material differences. TLS 1.3 is one example, but a useful receipt must say which protocol and version ran, whether the server alone or both peers authenticated, which credential and trust path succeeded, whether early data was used, which connection carried the UCCS and when that connection ended. A green handshake counter is not enough.

Replay deserves its own line. RFC 9781's working definition of a secure channel includes replay protection, yet the specification notes that a nonce claim can add it. TLS modes also do not all carry identical replay properties. An operator therefore has to record the nonce, challenge window or session binding actually used. “The peer was authenticated” and “these claims are fresh” are different results.

The channel cannot bootstrap trust from the same UCCS it is meant to authenticate. RFC 9781 warns that UCCS Evidence generally cannot justify the credentials used to establish that channel, because the reasoning would be circular. Endpoint credentials need an independent trust basis. Claims can then inform a later appraisal without reaching backward to create their own transport origin.

Nor does an authenticated endpoint prove a trustworthy Attesting Environment. A channel can faithfully deliver a false measurement. Assurance depends on the cryptographic channel and on how the claims were composed, protected from tampering and related to the measured system. The receiver's policy decides whether that combination is sufficient. The RFC does not write a universal acceptance policy.

Extraction is an authority event

Section 4 draws the operational line. When UCCS emerges from the secure channel into the receiver, the channel's properties no longer protect it. The object now has the same security properties as other unprotected data in that environment. If the receiver forwards it, the claims are treated as though they originated within the receiver.

That sentence reallocates accountability. The receiver is no longer a transparent pipe. It becomes the party choosing which bytes to retain, whether to re-encode them, how to describe their source, which audience may see them and what new protection will accompany them. A downstream verifier should not be told that it received the original sender's authenticated object. It received the receiver's onward assertion about an object once carried in an authenticated channel.

The distinction survives byte-for-byte copying. Suppose the receiver writes the exact CBOR bytes to immutable storage. The byte hash is valuable. It helps detect alteration. But an extraction receipt is still needed to bind that hash to the connection, authenticated endpoint, parser and time. Storage then needs a separate custody receipt: writer identity, access policy, encryption-at-rest key, retention rule and deletion result. Encryption at rest protects a repository; it does not restore the first channel as an object signature.

Forwarding creates another choice. The receiver might establish a new authenticated channel, sign or MAC a new object, build a fully formed CWT, or protect a digest that binds the extracted UCCS. Each construction says something different. The new sender must identify which input hash it used, what transformation occurred, which key or channel protects the output and which audience the assertion addresses.

RFC 9781's delegated-attestation example makes this transformation constructive. A sub-Attester without a signing key can send UCCS through a local secure channel to a lead Attester. The lead Attester hashes the UCCS and protects that digest with its Evidence-signing key, for example in a detached EAT structure. The lead Attester is not discovering an invisible signature. It is making a new, accountable claim about what it received.

A fully formed CWT is different. Its COSE envelope keeps its own origin and integrity evidence even when it crosses a secure channel. The channel authenticates its peer, not necessarily the signer or Attester represented inside the token. This is why the UCCS boundary must not be generalized into a claim that transport always endorses its contents.

The receipt chain after the boundary

A durable record separates nine observations: the tag and exact bytes; channel establishment; authenticated endpoint identity; replay or freshness state; extraction; storage and custody; onward forwarding and protection; Verifier appraisal; and Relying Party action.

No adjacent pair is interchangeable. Tag 601 does not prove a channel. A completed handshake does not prove the required peer authenticated. Identity does not prove freshness. Fresh delivery does not prove which bytes an application extracted. Extraction does not prove safe storage. Storage does not make a receiver an authorized source. Protected forwarding does not make the claims true. A Verifier's appraisal does not itself authorize enrollment, workload placement, key release or access.

This is the useful minimum in RFC 9781. The standard creates a compact, interoperable object and states the conditions under which external protection can replace COSE. It also states where that substitution stops. Running systems must produce the evidence that the conditions actually held.

Sources