Summary

  • draft-ietf-rats-epoch-markers-05 lets an Epoch Bell emit reusable markers so attesters and relying parties can share a bounded freshness coordinate without requiring every attester to maintain trustworthy wall-clock time.
  • A valid Bell signature authenticates the marker and its signing context; it does not prove universal time, equal delivery, per-session uniqueness, correct Bell policy or the moment at which attestation evidence was measured.
  • A verifier needs a freshness-join receipt that records Bell identity, marker type, delivery path, local receipt time, nonce binding, acceptance window, replay state and the policy decision that connected the marker to the evidence.

Freshness is a relation, not a timestamp

Remote attestation has a deceptively simple question at its centre: is the evidence recent enough to support this decision? A nonce answers part of that question by linking evidence to a challenge. A trusted clock can answer another part by locating an event in time. Neither is free. Constrained attesters may not maintain reliable real-time clocks, and a verifier may need evidence to travel through several intermediaries before it reaches a relying party.

The current RATS proposal introduces an Epoch Bell that emits Epoch Markers. Distributed actors can treat those emissions much as they would treat ticks from a shared clock. An attester incorporates a marker, or a compact handle to it, into signed evidence. A verifier later compares that coordinate with the marker state it accepts. The design supports ad hoc challenge-response, unsolicited broadcast or multicast distribution, and solicited subscriptions.

This is useful precisely because it does not require the attester to know civil time. Yet the convenience creates a linguistic trap. A marker may contain a POSIX timestamp, an ordered counter, a compact keyed value or a signed timestamp token. Once it is signed, the byte string can look like portable truth about “now.” It is not. Freshness exists between an emission, a delivery path, an evidence-creation act, a verification act and a policy window. The marker is one coordinate in that relation.

What the Bell actually signs

Revision 05 describes several marker types. A deployment can use CBOR time tags, the classical RFC 3161 TSTInfo, a CBOR representation of that structure, an Epoch Tick, a list of ticks, a monotonic counter or an epoclet. Those forms make different claims and carry different operational costs.

Time-bearing variants depend on a trustworthy clock at the Bell. A counter establishes order only inside the context that defines and preserves that counter. A tick can be reused by many consumers, which is a major difference from a verifier nonce created for one exchange. A tick list lets a receiver recover several recent positions, but it also requires receiver state and a way to resynchronise. The draft's epoclet form is compact—roughly 44 to 64 bytes—and combines POSIX time, a deployment key identifier and an HMAC. That economy moves governance into shared-key storage, rotation and server clock synchronisation.

A signature or MAC therefore establishes a bounded proposition: the holder of a specified key produced or authenticated this marker under the marker's format. It does not independently establish that the Bell's clock was correct, that the counter state survived a restart, that every recipient received the same tick at the same moment or that the key remained uncompromised. The first signer is a role in a trust chain, not an oracle.

The standards around the proposal reinforce that boundary. RFC 9052 supplies COSE signing structures; RFC 8392 and RFC 8949 provide CWT and CBOR building blocks; RFC 9581 defines RATS conceptual messages and roles. Those mechanisms can protect statements and bind claims together. They cannot turn an operational assumption into a physical fact.

One emission arrives at many different times

The proposal explicitly treats marker emission and reception like Internet clock ticks. A near receiver and a distant receiver need not observe the same usable frontier. Queues, multicast replication, intermittent links and intermediary processing create differential latency and skew. A delayed but authentic marker remains authentic.

That distinction matters in both Passport and Background-Check deployment patterns from the RATS architecture. In a Passport flow, an attester may obtain or hear a marker, create evidence and carry the result toward a relying party. In a Background-Check flow, appraisal may occur elsewhere and the relying party receives an Attestation Result. The policy must account for the path used by the relying party, while the result remains bound to the marker or handle that supported its freshness determination.

Consider two verifiers subscribing to the same Bell. Verifier A receives tick 820 immediately. Verifier B is temporarily disconnected and still accepts tick 818 within a declared tolerance. Both policies can be legitimate. A database that stores only “latest tick: 820” silently converts A's network position into a universal rule and may reject honest evidence sent to B. Conversely, retaining 818 indefinitely because it once fell inside B's window makes replay cheap.

The right object is an acceptance interval attached to an observed route. It needs a local receipt time, the expected distribution channel, an allowance for transit and processing, and a reasoned expiry. A long window reduces false rejection for distant or sleepy attesters but extends the life of captured good evidence. A short window constrains replay but punishes legitimate delay. The standard can describe the mechanism; the relying party owns that trade-off.

Reusable is not one-use

An Epoch Tick is intentionally reusable. Many attesters can refer to the same Bell emission, and one attester may use it in more than one evidence production. That scalability is an advantage, but it means the marker cannot inherit the security meaning of a fresh challenge merely because it appears inside a signed token.

The verifier should bind the expected Bell key, marker type, deployment domain and scope. When a session requires uniqueness, it should also contribute a verifier nonce. The draft calls for nonces with at least 64 bits of entropy, produced by a cryptographically secure random generator, and permits lengths up to 512 bits. The nonce and marker solve different problems: the nonce ties the result to one challenge; the marker places that result against a Bell coordinate.

Evidence should bind both, along with the attester identity or key and the evidence digest. Otherwise, an attacker may transplant a still-acceptable reusable marker between sessions or present old good evidence beside a newly received marker. A signed envelope is not enough if its internal claims are not joined.

This is also why marker type negotiation needs a downgrade rule. A verifier prepared to accept a signed time token, a monotonic tick and an epoclet should not let an untrusted peer select the weakest interpretation. Accepted types, algorithms and Bell keys belong to policy. A change among them is a governance event, not a harmless encoding choice.

State is where cheap comparisons become policy

Counter and tick deployments need remembered state. The cheapest design may keep one highest-seen value for the entire Bell domain. That limits storage, but it turns the fastest path into the frontier for every attester. Evidence delayed on another path can then be rejected even when it was created honestly. Per-attester state costs more, yet permits each attester's sequence and connectivity pattern to be evaluated independently.

Neither choice is universally correct. A tightly connected data-centre fleet may prefer a global frontier and narrow window. An intermittent industrial fleet may need per-attester history, explicit suspension states and careful recovery after Bell or verifier restarts. The significant point is that a numerical comparison does not eliminate policy. It hides policy if its state scope is undocumented.

Resynchronisation deserves the same attention. A tick list can help a receiver catch up, but accepting an older member of a list still needs rules. A counter reset after lost state can resemble rollback. A Bell key rotation can produce a new trust epoch even when a human-facing timestamp continues smoothly. Operations should preserve the last accepted marker, the key epoch, the reason for resync and the rule that admitted the new frontier.

The Bell can be wrong while the signature is right

A compromised or misconfigured Bell can issue perfectly verifiable markers. Its clock may jump, its counter may repeat, its key may be used from two locations or selected recipients may receive delayed views. Cryptographic verification then succeeds while the freshness premise fails.

The response is not to declare the Bell untrusted by default. It is to make Bell governance inspectable. Deployments need named operators, key custody, rotation and revocation procedures, clock or state-health monitoring, distribution measurements and an incident rule for markers issued during uncertainty. Multiple Bells can reduce dependence, but only if the policy says whether they are alternatives, a quorum or separate scopes. Combining unsigned assumptions from several Bells does not create consensus time.

Privacy is another boundary. Predictable ticks can correlate otherwise protected messages because observers can group traffic around a shared emission. Varying timing, increments or scope can reduce linkability, but it changes the verifier's window and state assumptions. Privacy mitigation therefore has to be evaluated with freshness policy, not added after the protocol is deployed.

Record the join, not just the marker

A durable freshness-join receipt should begin with Bell identity, verification key and key epoch; marker type, bytes or digest, declared domain and scope; emission claim if the format contains one; local receipt time; distribution channel; measured or budgeted transit and processing delay; and the acceptance-window rule.

It should then identify the attester, evidence digest and evidence-production context. If a verifier nonce was used, the receipt records that nonce and the session it names. It records whether state was global, per-attester or otherwise partitioned, the previous accepted frontier, replay or reordering result, clock assumptions, resynchronisation events and the exact policy version that produced the decision.

Finally, it needs outcome, expiry, revocation and review fields. A later Bell incident should be able to locate affected decisions without rewriting history. The receipt does not pretend these fields belong in the Epoch Marker specification. It keeps the interoperable mechanism narrow and makes local governance explicit beside it.

That follows a useful discipline: implement the minimum common object, localise future choices, and preserve evidence about reality rather than turning an architectural preference into protocol dogma. Epoch Markers can be excellent freshness coordinates. Their value increases when operators resist calling them universal time.

Process status is not deployment evidence

At the research cutoff, draft-ietf-rats-epoch-markers-05 was an active RATS working-group Internet-Draft, updated on 3 July 2026 and due to expire on 4 January 2027. Datatracker showed “WG Document Doc Shepherd Follow-up Underway” and an IESG state of “I-D Exists,” with no responsible area director or telechat date. The draft header described Standards Track, while Datatracker's intended RFC status field was blank. That discrepancy should be preserved rather than silently resolved.

None of those process facts demonstrates implementation or operational trust. Adoption evidence begins with deployed Bell software and keys, documented marker types, measured delivery, attester integration, verifier state and decisions that can be reproduced from receipts. A standards milestone can change expectations; it cannot retroactively supply a missing nonce or latency record.

Sources