摘要

  • draft-ietf-rats-epoch-markers-05 允许 Epoch Bell 发出可复用标记，让分布式参与者在 attester 没有可靠民用时间的情况下共享一个有限范围的新鲜度坐标。
  • 有效签名能认证标记及其签名密钥，不能证明所有接收者同时收到、Bell 时钟绝对正确、每次会话都唯一，或证据恰在标记发出时完成测量。
  • 验证者应保留“新鲜度连接凭证”，记录 Bell 身份与类型、传播路径、本地接收时间、nonce、接受窗口、重放状态和作出判断的政策版本。

新鲜度不是时间戳的别名

远程证明所问的不是“现在几点”，而是“这份设备状态对眼前的决定是否还足够新”。其中至少包含测量、生成证据、传输、鉴别和使用五个动作。可信时钟可以给动作定位，挑战随机数可以把回复锁定在一次请求上，但资源有限的 attester 未必能维护可靠时钟，复杂部署也未必允许 relying party 直接向每台设备发起挑战。

Epoch Bell 提供另一种协作方式。它连续发出 Epoch Marker，参与者将这些发射当作共同的节拍。attester 把标记或紧凑 handle 放进受保护的证明证据，验证者再将其与自己认可的边界比较。草案兼容临时 challenge-response、主动 broadcast 或 multicast，也允许订阅者请求持续分发。

共同节拍并不等于绝对时间。标记即使含有 POSIX 时间，也只能反映该 Bell 的时钟与管理域；若标记只是递增计数，它只能在保存这个计数状态的范围内说明先后。所谓新鲜，是发射、到达、取证和政策窗口之间的关系，不是一个字段天然携带的品质。

不同格式承担不同前提

第 05 版列出多种形式：CBOR 时间标签、RFC 3161 的传统 TSTInfo、其 CBOR 形式、Epoch Tick、Tick List、单调计数器和 epoclet。它们不是可以随意互换的包装。

带民用时间的形式依赖 Bell 一侧的可信时钟；计数器依赖连续而未回退的状态。Tick 可以让许多消费者同时复用，这正是它与单次验证 nonce 的核心区别。Tick List 帮助接收者追上若干近期位置，同时要求接收者保存状态并处理重新同步。epoclet 大约 44 至 64 字节，把 POSIX 时间、部署密钥标识与 HMAC 放在一起。体积变小并未让信任消失，只是把治理问题转移到共享密钥保管、轮换和多个服务器的时钟同步上。

因此，签名或 MAC 所能证明的命题应当保持窄小：预期密钥按既定格式认证了这些字节。它不能独立证明 Bell 时钟准确、计数器在故障后没有重复、所有接收者同时看到同一节拍，或密钥从未泄露。RFC 9052、RFC 8392、RFC 8949 与 RFC 9581 可以保护陈述并绑定字段，不能把运维假设变成物理事实。

同一次发射会有许多到达时间

队列、组播复制、间歇链路和中间处理都会制造迟延与偏斜。离 Bell 较近的验证者可能已经收到 tick 820，远端站点仍把 818 视为可接受。如果系统只存一个“全局最新值 820”，就会把最快路径的视角冒充为全网时间，诚实但较慢的 attester 可能被拒。反过来，若 818 永不失效，截获的旧证据就能长期重放。

Passport 与 Background-Check 两种流程都会遇到这个问题。前者通常由 attester 携带证据前往 relying party；后者可能由另一服务完成 appraisal，再把 Attestation Result 交给决策者。无论哪一种，结果都应继续绑定当时使用的 marker 或 handle，接受政策则必须计算 relying party 实际经历的路径。

接受窗口越宽，越能容忍远端、休眠设备和处理排队，却也延长了曾经良好证据的可利用期。窗口越窄，重放空间越小，网络造成的误拒越多。因此凭证要保留本地接收时间、预期分发信道、传输与处理预算以及明确的过期点。标准规定机制，最终风险取舍仍归 relying party。

可复用不等于单次使用

Epoch Tick 的复用是设计目标。许多 attester 可以引用同一次 Bell 发射，一个 attester 也可能在多份证据里使用它。这让分发更经济，却意味着 Tick 不能因为被签进 token 就自动获得一次性挑战的语义。

当会话需要唯一绑定时，验证者还应提供自己的 nonce。草案要求 nonce 至少具有 64 位熵，由密码学安全随机生成器产生，并允许最长 512 位。nonce 回答“这是对我这次请求的回复吗”，marker 回答“它位于这座 Bell 的哪个坐标”。二者必须与 attester 身份或密钥、证据摘要一起被同一受保护结构绑定，否则攻击者可能把仍在窗口内的 marker 移植到旧证据或另一会话。

Bell 身份、预期密钥、部署域、标记类型和允许算法也要固定在政策里。如果不可信一方能把时间戳降为语义较弱的计数器，或把一种 Bell 换成另一种，格式协商就成为降级通道。编码改变了证明前提，不只是字节数变化。

状态的范围决定谁承担误拒

Tick 和计数器只有与记忆状态比较才有意义。成本最低的做法是为整个 Bell 域保存一个最高已见值。它节省存储，却让最快的路径替所有 attester 推进边界，慢路径上的诚实证据随之变旧。为每个 attester 保留状态成本较高，但能按各自连通性和历史判断。

稳定的数据中心集群也许适合全局边界和短窗口。断续上线的工业设备可能需要逐设备状态、显式暂停标识，以及 Bell 或验证者重启后的恢复程序。没有一种选择由签名自动推导出来；它们实质上决定由谁承担存储成本，由谁承担错误拒绝。

重新同步同样需要留痕。Tick List 可以帮助追赶，却不能自动决定旧成员仍应被接受多久。状态丢失后的计数器重置会像回滚，Bell 密钥轮换即使保持连续时间，也开启了新的信任时期。运维记录必须包括旧边界、密钥时期、同步原因和批准规则。

签名正确，Bell 仍可能出错

一座被入侵或配置错误的 Bell 可以发出密码学上完全有效的 marker。它的时钟可能跳变，计数器可能重复，同一密钥可能在两个位置被使用，不同接收者也可能被故意送入延迟视图。此时签名验证通过，新鲜度前提却失败。

Bell 的治理因而必须可观察：明确运营主体，记录密钥托管、轮换与吊销，监控时钟或状态健康，测量各条分发路径，并为不确定期间发出的 marker 制定事故规则。部署多座 Bell 可以降低单点依赖，但只有政策说明它们是备选、分域还是需要 quorum 时，多个来源才具有可解释性；并列几个未说明的假设并不会产生共识时间。

可预测 Tick 还有隐私代价。观察者即使看不到受保护内容，也可能按共同发射周期把消息关联起来。改变发射间隔、递增规律或范围能降低关联，却会同时改变窗口与状态假设。隐私和新鲜度必须在同一张设计表里计算。

保存连接过程，而不是只存 marker

一份可长期复核的新鲜度连接凭证，首先记录 Bell 身份、验证密钥与密钥时期，marker 类型、原始值或摘要、声明的域和范围。若格式含有发射时间，应将其标为 Bell 的声明；另存本地接收时间、分发信道、实测或预算迟延以及窗口规则。

凭证再连接 attester、证据摘要与证据生成语境。存在 verifier nonce 时，要保存 nonce 和它指向的会话。状态究竟是全局、逐 attester 还是其他分区，前一个可接受边界是什么，是否发生重放或乱序，怎样重新同步，以及采用哪一版政策，都需要明确。

最后保存决定、过期、吊销与复查字段。若 Bell 日后曝出事故，可以定位受影响的历史决定，而不必改写过去记录。这些内容不应硬塞进 Epoch Marker 标准本身。共同规范保持最小，本地未来选择保持本地，并把发生过的现实留下来，远比把某种架构偏好包装成普遍真理可靠。

截至本次研究，第 05 版是 RATS 工作组的活跃 Internet-Draft，2026 年 7 月 3 日更新，预计 2027 年 1 月 4 日到期。Datatracker 显示工作组状态为“WG Document Doc Shepherd Follow-up Underway”，IESG 状态为“I-D Exists”，没有负责的 area director 或 telechat 日期。草案页眉写有 Standards Track，而 Datatracker 的 intended RFC status 字段为空。应保留这项差异；这些是流程事实，不是部署证明。

来源