摘要

  • Wathīqa 首个公开草案提出用连续签名节点保存同一份数据；后续节点可以换用新算法，并承诺前一节点的规范哈希。
  • 草案把透明度日志收据定义为经过认证的“不晚于”证据；随机性信标锚点则承载“不早于”元数据，但第 00 版不校验信标证明。
  • 见证方校验取决于调用者是否提供可信公钥集合 W。没有 W 时，验证器仍会检查内容、签名和前序哈希，却不会要求日志收据或时间单调性。
  • 该文件是拟定为 Experimental 的个人 Internet-Draft，并非 IETF 标准或工作组决定。它声称已有三种语言的实现，却没有给出仓库或固定提交，并承认安全论证尚未接受独立密码学审查。
  • 因此，产品不应只显示一个“有效”状态，而应分别报告链条有效性、在特定见证策略下验证的时间上界、尚未验证的时间下界以及本地策略结论。

算法能续，错过的窗口不能倒流

长期证据的难点不只是保护静止的字节。今天可信的签名算法，几年后可能因新攻击、密钥泄露或安全参数变化而不再被依赖方接受。如果旧算法已经失去可信度，才给记录加上一个新签名，新签名无法倒推旧记录在失效前究竟是哪一个版本。

RFC 4998 的证据记录语法早已把“赶在变弱之前续期”写入设计：归档时间戳必须在相关算法变弱或证书失效之前更新。它同时指出，算法何时变弱、密钥是否面临泄露以及安全期限多长，需要依靠语法之外的信息。记录能保存一次判断，不能自行观察未来的密码分析。

Wathīqa 草案第 00 版把这种续期扩展到签名算法本身。数据先得到一个内容地址；每个链节点对同一内容地址签名，并由后续节点写入前一节点规范表示的哈希。草案列出 ML-DSA 和 SLH-DSA，它们分别来自 FIPS 204 与 FIPS 205。这两份标准定义了算法，并没有替 Wathīqa 证明互操作性，更不会替每家机构决定何时更换参数。

上界是收据，下界还是声明

草案用两类材料夹住每个节点的时间。第一类是透明度日志的包含性收据。节点签名作为一片叶子写入 Merkle 树，验证者用包含路径连接到带签名的树头。如果日志公钥在本地信任集合内，证明又能通过，那么这可以说明：最迟在该树头的时间点，日志中已经出现了这个签名。它借用了 RFC 6962 的包含证明和树头思路。

第二类材料想证明节点“不可能早于”某个时刻。公开信标在固定时间发布此前不可预知的输出；如果节点签名真实地绑定了一份经过认证的信标脉冲，就可以把生成时间压在脉冲发布之后。NIST Randomness Beacon 2.0 的页面说明，其脉冲带序号、时间戳、签名和前序哈希；该页面同时仍把 2.0 服务标为测试版和进行中的工作。

问题在于，Wathīqa 第 00 版不验证脉冲签名或其他信标证明。它会检查锚点记录与节点签名之间的哈希自绑定，但这只能证明“这个锚点记录跟着这个签名”，不能证明“NIST 确实发布过这里声称的脉冲”。草案安全章节甚至明确写道，攻击者可以填写任意“不早于”元数据，依赖方不得把该锚点当成经过认证的时间。

这不是外部研究推导出的漏洞，也不是对某个上线产品的攻击报告，而是作者主动标出的当前限制。最容易犯的错误，是在界面上把两个时间字段都画成绿色。现代签名只能保护声明不被后改，不能把未经校验的来源变成时间权威。

W 是否存在，改变了“通过”的含义

日志一侧也不是看到收据就自动成立。验证算法接收一个可选参数 W，其中包含验证者信任的见证方公钥。只有提供 W 时，流程才要求每个节点必须带有效包含性收据，树头签名必须能由 W 内的密钥验证，而且一系列树头时间不得倒退。

若调用者没有提供 W，验证器仍然重算内容地址、检查每个节点签名、比对前序链哈希，并可在这些检查均通过时接受记录。于是，同一份文件可能得到两个都叫“接受”的结果：一个只证明密码链结构成立，另一个还证明在某个见证名单下存在“不晚于”上界。

这种差异直接影响审计。如果接口只返回布尔值，审计人员看不出调用时是否省略了 W；两个机构即使持有同样的记录，也可能因见证名单不同而并未共享同一个时间结论。草案提出，用法定人数授权、只追加的方式延续见证密钥，并固定到一个长期锚点。这是一条设计方向，还不是完整的治理制度。谁组成法定人数、密钥被攻破时如何切换、日志分叉时信哪一条、运营主体消失后谁保管历史，都没有被记录格式自动解决。

这是第一版提案，不是已经落地的制度

IETF Datatracker 将该文件列为没有 RFC stream 的个人 Internet-Draft。文件日期是 2026 年 9 月 3 日，目标状态为 Experimental，失效日期为 2027 年 3 月 7 日；9 月 5 日的 I-D 公告只证明首版已经公开分发，不等于工作组采纳或 IETF 背书。

草案称，已有完整 Python 参考实现，以及能逐字节复现规范链哈希的 JavaScript、Rust 验证器和共享向量。它也直言，安全论证没有经过独立密码学审查。第 00 版没有提供代码仓库地址或固定提交，因此本文没有把这些实现声明当成已经独立复现的互操作证据。

规范内部还留下了一个可见的版本接缝。第 4.3 节把封装后的 ASN.1 DER 形式称为第 3 版，并把详细模块暂时交给一个“权威”的外部 Python 文件，未来才会写入草案；附录 B 却称当前 DER profile 是第 4 版，第 1 至 3 版仍可解码，而发送端只生成第 4 版。RFC 9169 提供了公开、现代化的 ERS ASN.1 模块，但不会替 Wathīqa 选择它自己的扩展版本。

这很可能只是首版编辑未清理干净，不能据此宣称实现不安全。不过，在版本号统一、模块进入自包含规范、代码与测试向量固定到同一发布点之前，“跨实现一致”没有一个可复现的稳定对象。草案提议的两个媒体类型也被作者标注为尚未提交 IANA 流程。

通过密码链，不等于通过完整时间线

把结果拆开后，现有能力很清楚。独立验证者可以重算内容地址，确认每个签名，验证各节点承诺的前序哈希；在明确给出 W 的前提下，还能验证一条“不晚于”的日志证据。第 00 版目前不能从所写流程中认证“不早于”一侧。

记录本身也不会决定算法的寿命、预警来源、可信见证名单、密钥轮换治理或紧急续期时间。这些属于依赖方的本地判断。问题不在于它们是本地的，而在于软件若不把它们连同结果一起记录，就会把一次有条件的判断包装成文件自身的永恒属性。

Wathīqa 的价值正在于它把时间不对称写了出来。下一步不是用更响亮的“量子安全”标签盖过去，而是让可移植的确定性证明与本地信任决策始终分栏显示。