摘要

  • 一份有效的 Roughtime 响应只证明某个密钥在收到特定请求后，签署了一段有界时间主张；它不证明该时间正确。
  • 串联报告可以证明响应先后发生矛盾，并推出“至少一台服务器错误”，却不能单凭矛盾指出责任方，也不会自动完成受理、撤信或修复。

三台时钟依次留下签名。签名都能验证，请求也都嵌进 Merkle 树。后来一次请求还带着前一次响应的哈希痕迹。可当三段时间区间按证据顺序排在一起时，它们无法同时成立。

案情中已有矛盾，却还没有被告。

这正是 Roughtime 第 19 版最值得管理层理解的边界。该文档属于活跃的 IETF NTP 工作组，拟以 Experimental 身份发布，已进入 RFC Editor 流程，但当前仍是 Internet-Draft，不是 RFC。第 18 版到第 19 版主要是编辑调整，不能虚构成这一版才新增了归责机制。

有效签名不是正确时间

客户端先发出 nonce。服务器把请求映射为 Merkle 树叶节点，再签署包含根值、时间中点 MIDP 与不确定半径 RADI 的响应。临时 Ed25519 密钥签响应，长期密钥则签署写有临时公钥及 MINT、MAXT 有效区间的委托。

客户端检查长期签名、临时签名、请求包含证明，以及中点是否落在委托区间。全部通过，响应才叫有效。

规范随即提醒：有效并不证明时间值正确。它只证明服务器保证自己在 (MIDP-RADI, MIDP+RADI) 区间内计算并签署了这个时间。RADI 越小，主张越精确，但精确的签名主张仍可能建立在错误时钟上。密码学保护陈述的来源与完整性，无法凭空制造陈述背后的物理事实。

因果链能封住否认空间

多服务器模式需要一份预先配置的列表，其中至少三台服务器在线，而且不能由同一方运营。客户端按顺序查询，再以相同顺序重复一轮。第一次使用随机 nonce；此后每个 nonce 都由上一份完整响应加新随机量派生。于是，后一台服务器签名时，链条已经携带此前观察。

客户端逐对检查：先收到的时间区间能否在后收到的区间之前成立。若签名有效、延迟也在本地上限内，却违反因果顺序，规范把它定义为 malfeasance。报告保存随机量、预期公钥、请求、响应与接收顺序。

这份证据足以证明至少一台服务器给出了错误时间，也能阻止参与者事后否认原始声明。但“至少一台”是集合判断，不是姓名。两台诚实服务器可以暴露第三台；两台共享错误源甚至串通的服务器，也可能把诚实的少数派衬成异常。运营主体、上游时间源和列表治理的独立性，仍是判断的一部分。

证据格式之外还有权力

草案规定了服务器列表与 JSON 报告格式，却没有规定谁有资格上榜、谁受理报告、采用什么证明标准、如何认定责任、何时撤销长期密钥，以及被撤方如何申诉。文档只把“由人类观察者组成的法庭式论坛”当成一种简单设想，同时明确指出：列表维护与违规裁决虽不在协议内，却对安全至关重要。

生产系统不能用一个布尔字段掩盖这条边界。至少要分开保存：原始签名区间；签名、委托与包含证明；发生矛盾的具体响应对；列表身份与版本；报告的提交和审查状态；最终归责；密钥撤销；客户端列表刷新；下游修复。已提交不等于已受理，已受理不等于已归责，已撤信也不等于历史影响已经修复。

密钥的时间边界同样需要谨慎。临时私钥即使在 MAXT 之后才泄露，攻击者仍可能把伪造时间回填到旧的有效区间。过期阻止未来正常使用，却不会自动洗清历史证据风险。

Roughtime 可以为没有可信时钟的设备提供粗略时间，以启动证书验证，也可以为 NTP/PTP 观测划边界。但它不是法律时间戳，不是交易全序证明，不证明设备完整，更不证明现实任务已经完成。