Summary

  • Revision 13 lets a Verifier subscribe to network-device attestation events and receive new Evidence after operational changes instead of waiting for the next poll.
  • Replay, nonces, epoch identifiers, signed TPM clocks and heartbeats improve continuity and freshness, but none of them alone proves an omission-free history.
  • Production, transport, sequence/replay, freshness, appraisal, Relying Party authorization and outcome should remain seven separately evidenced stages.

A network device can be compliant at breakfast and materially different by lunch. It may reboot, install software, fail over to another control unit, gain or lose a forwarding unit, detect an attack or approach a certificate boundary. Polling catches such changes only when the next question is asked. draft-ietf-rats-network-device-subscription-13 proposes a more useful rhythm: the Verifier subscribes to an <attestation> YANG Event Stream built on RFC 8639 and receives new Evidence as relevant events occur.

The opening exchange is substantial. A subscription carries a nonce, selected PCRs and, optionally, a filter. The device can replay matching PCR-extend events from the current boot, mark replay completion and deliver a TPM Quote bound to the nonce. Later, an extend notification precedes its corresponding quote; revision 13 requires that quote within seconds and no later than ten seconds. Quiet devices are not assumed healthy forever: heartbeat behavior gives the Verifier something to watch when no quote is otherwise due.

This is not a thin “push instead of pull” convenience. It creates a practical evidence lane between operational change and remote appraisal. Yet it also creates a tempting category error: because the messages arrive continuously and carry cryptographic material, an operator may treat the stream itself as a continuous verdict.

The first test is production. Did the device measure the event that matters and cause the relevant Evidence to be created? A valid TPM Quote can bind selected PCR values; it cannot prove that an event outside the selected measurement surface should have been measured. A subscription filter narrows traffic deliberately. Scope is a policy choice, not a property rescued by a signature.

The second test is transport. Did the Verifier receive the notification through the expected subscription and associate it with the correct device and session? Channel protection and notification validation matter, but successful receipt says nothing yet about what was never placed on that channel.

The third test is sequence and replay. The draft provides real controls: boot-bounded reconstruction, an identified replay boundary, ordering between an extend and its quote, reset/restart handling and a heartbeat. Operations should verify those controls rather than merely store the latest quote. A receiver needs to explain the subscription identifier, replay-completed marker, event order, filter, reconnect boundary and any gap. Evidence on both sides of a missing interval does not cryptographically fill the interval.

Freshness is the fourth test. A nonce creates a rough challenge epoch; a central epoch identifier or a separate RFC 9684 quote request can refresh it. TPM 2.0 signed clock, reset and restart counters let the Verifier test drift and lifecycle changes. But RFC 9334 is explicit about the residual race: freshness narrows when Evidence could have been created; it does not turn a measurement into an eternal statement of current state. Revision 13 also leaves important freshness policy out of band. A reused nonce may be acceptable locally and inadequate elsewhere.

The fifth test is appraisal. The Verifier still needs Reference Values, Endorsements and an appraisal policy. RFC 9683 warns that Reference Values can conflict, omit needed material or be ambiguous. A clean signature answers who protected the claims. It does not answer whether the claims satisfy the right baseline, or whether that baseline was the right one for this device at this time.

Authorization is the sixth test. Under the RATS architecture, the Verifier produces an Attestation Result; the Relying Party applies its own policy to a specific transaction. An acceptable result might permit inventory, deny network admission, trigger maintenance or require human review. Manufacturer confidence and cryptographic validity do not silently grant the Verifier business authority.

Outcome is the seventh test. Even a correct deny decision is not proof that the enforcement point applied it, that traffic moved, or that the risk disappeared. The final receipt belongs to the operational system that acted. Continuous Evidence becomes operationally valuable when these seven records can be joined without pretending that one substitutes for the next.

Revision 13 remains an active Internet-Draft. As checked on 9 September 2026, the IETF Datatracker showed it in AD Followup after submission to the IESG, with Proposed Standard as the intended status. That is process evidence, not RFC approval or deployment evidence. The draft deserves attention precisely because it improves the flow of facts. Its strongest use is to make decision latency visible—not to erase the boundary between seeing, judging and acting.

Sources