摘要

  • Roughtime 第 19 版草案规定一种目标为 Experimental 的协议：客户端把多次签名交互串联起来后，可以证明至少一台服务器给出的时间不符合因果顺序，但未必能仅凭这条链认定具体责任方。
  • 草案定义受信服务器名单与失当报告格式，却明确不规定名单如何维护和分发、报告如何受理、违规如何裁断以及服务器如何被排除；草案同时承认这些程序对安全至关重要。
  • 可建立一份可携式撤信回执，把报告哈希、归责边界、获授权审查、处置结果、前后签名名单、分发情况、客户端采纳与纠错通道连成一条记录。这是 Daniel Kade 的治理建议，不是 IETF 规范要求。

签名证明谁说过，不证明时间正确

一台长期断电的设备重新启动时，可能连当前年份都不确定。它需要合理时间才能验证证书，却又可能需要先验证时间服务的证书才能安全取时。Roughtime 针对的正是这个循环：给几乎没有时钟基础的客户端一个经过认证的粗略区间，并让相互矛盾的受信时间留下外部可验证证据。

当前文本是 draft-ietf-ntp-roughtime-19，于 2026 年 3 月 17 日发布，目标状态为 Experimental。IESG 当天批准该文档；Datatracker 目前显示它位于 RFC Editor 队列，RFC 制作状态在 9 月 4 日变为 In Progress (Second Edit)。这些是已经发生的流程事实，却不等于 RFC 已经出版。第 19 版仍是 Internet-Draft，本证据包也没有为它臆造 RFC 编号。

最基本的交互从一次随机请求开始。客户端发送 nonce，服务器返回时间中点与误差半径，用一个区间表示自己认为真实时间所在的位置。服务器签名覆盖与该 nonce 相连的 Merkle tree 承诺，因此验证者可以确认持有某把长期密钥的一方在见到请求后生成了这份响应。

认证对象是响应，不是宇宙时钟。一台服务器完全可能用有效密钥签下错误区间：配置出错、上游时间源失准、系统被攻陷或主体故意说谎，都可能产生相同表面。Roughtime 的关键设计在多服务器模式。前一份响应中的材料进入后一份请求，使签名区间受到交互先后顺序约束。

如果这些区间无法装进真实因果顺序，客户端就不只是“感觉时间不对”。它能保存请求、响应、公钥与随机材料，让其他验证者重做计算。结论很强，也很窄：至少有一份时间响应是错的。有些链条不能凭数学关系唯一确认是哪一份。

因此，三个判断不能合并：某把密钥签署了某份响应；多份响应不可能都正确；某把密钥应被移出信任名单。协议可直接支持前两项中的事实，第三项还需要制度性的归责与处置。

草案没有假装密码学会审案

第 19 版坦率地划出边界。它说，Roughtime 生态仍需积累维护、分发受信服务器名单和处理失当报告的运营经验。文档限定在网络协议以及名单、报告的数据格式，并不描述名单维护方式、分发机制或适用政策。

协议概览又指出，报告若要导致服务器被排除，还需要额外的审查和排除机制，而该机制不在草案范围。报告章节说明，接受或拒绝具体报告的运营规则不在范围。安全章节更直接：维护受信名单、裁断服务器违反规则的基础设施与程序对安全必不可少。

这不是多加一个布尔字段就能填平的缺口。签名与 nonce 链可以按照明确算法验证；责任归属还要检查共用上游、密钥保管、误差半径、闰秒处理和外部遥测。采取何种后果，则牵涉比例、期限、独立审查与服务连续性。

英文术语 malfeasance report 容易让读者先入为主地想到主观恶意。协议证据只显示时间矛盾。真正原因可能是失误、软件缺陷、密钥被盗或攻击。最准确的第一状态应是：矛盾已验证，归责待完成。它既不削弱加密证据，也不借文件名扩大结论。

草案还规定，签名验证失败或其他协议错误本身不能触发这种失当报告。报告针对的是一组可用响应的因果不一致，而不是通用错误箱。把不同告警混进同一路径，会使收件方无法区分网络噪声、实现问题与真正的时间矛盾。

服务器名单是一段信任程序

Roughtime 把服务器长期公钥视为信任根。客户端至少需要三台正常工作、且不由同一主体运营的服务器，并应定期更新自己对哪些服务器仍可信的认识。

草案定义一种通用 JSON 名单，可列出名称、地址、版本与公钥，还可附带其他名单来源以及 HTTPS 报告地址。但支持该格式并非强制，客户端可以采用自己的配置机制。

可选性防止“共同格式”悄悄变成“唯一管理者”。操作系统厂商可以维护名单，企业可以自建，研究机构也可以发布另一套。客户端能够采纳、延迟、分叉或拒绝某次更新，而不因此变成协议意义上的违规者。

不过，改名单绝非中性排版。加入一把密钥，让它的签名区间参与今后的判断；移除一把密钥，使采纳者不再选择该服务器。处置过慢会延长暴露，过快则可能破坏来源多样性，甚至让客户端剩不下三家独立运营者。静默恢复还会抹去此前处置的理由。

名单维护者拥有的是用户委托的选择权，不是对服务器的普遍管辖权。它可以发布建议性的信任状态，真正效力取决于客户端收到、验证并本地安装哪一个版本。

报告拥塞不能成为证据消失机制

客户端检测到失当时，应在技术可行的情况下生成报告、提醒用户并再次测量。如果名单给出接收地址，报告通过 HTTPS POST 提交。

热门服务器一旦故障，许多客户端可能同时上报。草案要求指数退避，并给出重试间隔建议。这项要求保护接收服务，不代表客户端可以只记住下次重试时间、然后丢弃唯一证据。

可靠的接收方应先按内容计算报告标识，确认已经持久保管，再区分完全相同的副本与真正不同的链。重复重试不能被计算成新的“赞成票”；涉及同一公钥的不同观察也不应被粗暴合并，从而掩盖影响范围。接收回执只能表明“已保存”或“已有相同内容”，不能宣布“服务器已撤信”。

隐私也要按证据需要来限定。复核通常需要原始报文和公钥，不一定需要保存设备长期身份或完整网络地址。可携证据体系不该顺便建成客户端行为名册。

归责是一项有边界的推理

有些链能让两份互相吻合的响应夹住一个明显不可能的区间，从而对中间密钥形成强指向。另一些链只有两种互斥说法，无法判断谁错。多台服务器可能共享运营者、时钟上游或软件缺陷。密钥可能被窃取，服务器组织本身未必作恶。少数派也可能是唯一正确者，而多数来源恰好存在相关故障。

审查者必须重验每个签名、nonce 关联和区间，确认误差半径与闰秒处理，并排除截断或损坏的采集。然后公开使用准确的归责状态：已锁定单一密钥、仍有候选集合，或只能确认未归责矛盾。

运营遥测、密钥保管记录、独立时间参考可以补强判断，但必须单独注明来源。外部推论不能因为与加密报告放在同一附件里，就获得同样的确定性。

首份有效报告出现后立刻永久移除密钥，是用速度伪装确定性；永远等待绝对确定性，则会让证据没有运营价值。中间路径是有期限的降权或隔离，随后调查、公开理由，再决定移除、恢复或延长措施。

NTS、Khronos 与 Roughtime 各自守住不同边界

RFC 8915 的 Network Time Security 使用 TLS 建立密钥，并用认证加密保护 NTP 报文。它能让客户端验证同步报文来自选定服务器、未被篡改或重放，却不能保证经过认证的服务器时钟正确。

Roughtime 可以先为没有可靠时钟的设备提供足以验证 NTS-KE 证书的时间范围，还能在签名时间提供者互相矛盾时留下外部证据。因此两者互补，而非替代关系。

RFC 9523 的 Khronos 通过更坚固的选择与过滤抵抗时间偏移攻击，主要保护本地客户端。Roughtime 的重点是让第三方也能核验不一致。安全选择不自动产生归责档案，可携证据也不自动选择下一组可信服务器。

RFC 8633 建议使用多个时间源并持续监测；RFC 7384 列出恶意时间源及证书等安全服务对时间的依赖。这些规范说明问题重要，却没有从密码算法里生成一个全网裁决者。

可携式撤信回执

Daniel Kade 提议用一份可携式撤信回执连接协议止步后的各环节。它不是新的 Roughtime 报文，不是全球法庭，而是让每个本地决定可以被独立检查的记录。

第一部分固定证据：失当报告哈希、完整有序响应链、验证软件及版本、每个签名与 nonce 关联的结果，以及客户端当时使用的服务器名单哈希。采集环境只保留与验证直接相关的最少信息。

第二部分记录归责：单一密钥、候选集合或无法区分。它写明有权审查者、利益冲突、外部证据、理由代码、置信程度、有效期限与复审触发条件。

第三部分描述处置：隔离、降权、移除或恢复。前后名单的哈希、序列、签名者与生效时间必须同时存在。临时措施若没有基于新证据明确续期，就应自动到期。

第四部分证明发布但不冒充采纳。回执列出发布端点和透明档案；客户端群体以保护隐私的方式报告已安装哈希、更新延迟与拒绝原因。某企业可以依据本地名单做出不同决定，同时完整承担该决定的风险。

最后一部分保留纠错。服务器运营者可以证明密钥失窃、修复上游时钟、轮换密钥或挑战归责。审查者能够撤回错误处置，但不能删除原报告。恢复应成为另一条签名过渡，而不是无痕改写。

信任真正改变在客户端内部。名单发布不会自动更新缓存、绕过固定配置或满足本地策略。移除完成后还要验证独立服务器数量，避免用撤信修复了风险，却破坏安全启动所需的可用性。

Roughtime 的成就在于让一种具体矛盾难以否认。治理的任务不是把这种证据据为普遍权力，而是让后续判断、名单变化和本地采纳同样可见、可退出、可纠正。

来源