摘要

  • 2026年9月5日更新的draft-dogru-cedulon-decision-profile-02仍是活跃的个人Internet-Draft，没有IETF背书或正式地位，也没有RFC流和负责的区域主任。
  • 该配置把签名的Decision Record与认证的Effect Extract进行核对：允许决定应当对应一个结果；拒绝或延后决定不应对应结果。
  • 第02版明确说，绑定规则不对两只时钟排序。结果行的时间只与所在审计窗口核对，不与它对应的决定时间比较。
  • 因此，effect-against-refusal证明的是同一引用下同时存在拒绝和结果，并不单独证明结果晚于拒绝，更不能定位控制链在哪一步失效。
  • 顺序应当用单独凭证表达：写明两只时钟的权威、允许偏差和辅助证据，并保留“之前、之后、偏差内、无法确定”四种状态。

这项核对真正回答了什么

Datatracker当前页面先限定了制度身份。这是Emek Can Doğru提交并于9月5日更新的个人Internet-Draft第02版。页面明确提醒，任何人都可以提交I-D；这份文件没有IETF背书，在标准流程中也没有正式地位。页面没有RFC流、Responsible AD或telechat日期，IESG状态只有“I-D Exists”。所以，本文讨论的是一份可供评审的个人提案，不是IETF已经作出的决定。

提案要处理的运行问题很具体。决定方签发Decision Record，说明是否允许代理执行某个动作。渠道运营者或代其取证的捕获程序提供Effect Extract，列出一个时间窗口内实际发生的结果。验证器在一个决定方、一个渠道和一个窗口的范围内，把两边按引用编号核对。

如果决定是允许，规则期待恰好一条引用、内容哈希和结果类别都匹配的行。允许但没有结果，记为decision-without-effect；有结果却没有决定，记为effect-without-decision；拒绝或延后决定不应产生结果，如果它的引用在结果行中出现，则记为effect-against-refusal。

这些名称把含混的“代理好像没有听话”变成了可重复的集合核对。不过，“拒绝对应了一个结果”与“拒绝之后发生了结果”是两句话。第02版存档承认当前算法只证明前一句。

日期更早的结果行仍会绑定

Decision Record与结果行都带有timestampMs，但验证器没有对这两个数做成对比较。结果行的时间必须落在Effect Extract声明的[windowStartMs, windowEndMs)内；它不需要晚于相应的决定时间。第02版甚至直接说明，一条日期早于决定记录的结果行，也会像晚于决定一样完成绑定。当前规则比较引用、内容和类别，不比较顺序。

举例说，结果记为10:00，拒绝记录为10:01，两者仍可能得到effect-against-refusal。这至少容许四种解释：结果确实先发生；其中一只时钟走快；决定更早作出但更晚签发；或者捕获程序事后补写了时间。集合冲突可能完全真实，时间先后却仍然没有答案。

草案对时间并非毫无约束。一条越出窗口的结果行会让整份extract被判为格式错误；靠近相邻窗口边缘的未匹配项，还可以按照继承规则延后或转入下一份extract，配套实现默认使用五分钟余量。这些规则决定某条数据是否属于本次审计，也减少切窗带来的假缺口。它们并没有证明决定方时钟和渠道时钟由谁维护、是否同步、误差有多大。

签名也不能补上这一步。签名能证明某把密钥认可了包含某个时间值的字节，不能自动证明这个值在事件发生时产生。草案的信任章节本身也承认，两套签名根之间的保证取决于决定方和结果捕获方是否真正独立。如果同一个部署在事后整理两边的记录，密码学完整性仍可成立，而历史顺序仍是有条件的。

不要把集合差异写成违令结论

effect-against-refusal值得保留。它与“完全没有决定的结果”不同：这里确实有一个决定，其内容是拒绝或延后，并且同一引用下出现了结果。对审计人员而言，这比笼统的异常告警更有信息量。

但草案也明确说，这项发现不能定位问题究竟发生在控制传递、执行点、旁路还是取证链。时间叙事也应保持同样克制。“拒绝引用下出现了一项结果”由当前算法支持；“代理收到拒绝后仍然行动”额外假定了先后顺序、控制已经送达以及控制有能力生效。

这个差异会影响事件升级、供应商责任、人员处分和自动阻断设计。若报告界面省掉限制，技术标签就可能变成事实裁决。Heng Lu关于准确记录的主张提供了一条编辑纪律：记录描述现实，而不是创造现实。这里的记录可以描述决定、结果和实际运行的核对，不能凭匹配关系创造没有测量过的时间顺序。这是Daniel Kade的分析应用，不是Cedulon或IETF的规则。

给顺序单独留一张凭证

无需改写现有集合结果。一次核对可以同时报告effect-against-refusal和“顺序无法确定”：前者说明两边不守恒，后者说明证据不足以判断先后。把两个维度分开，比把所有不确定性塞进一个安全告警更诚实。

顺序凭证首先应锁定两条签名记录的哈希，然后分别说明时间由哪只时钟产生、谁控制时钟、时间怎样进入记录、是否在审计前已有不可回写的承诺。允许偏差也需要带上来源：是设备同步测得、部署策略指定，还是简单沿用了别处的默认值。

结论可以保持四种：

  • “之前”：在扣除公开的不确定区间后，结果仍早于拒绝；
  • “之后”：在同样条件下，结果仍晚于拒绝；
  • “偏差内”：数字有大小，但差距不足以跨过允许误差；
  • “无法确定”：时钟来源、同步或佐证不足，不能比较。

单调计数器、渠道事件序列、可信时间戳、检查点或独立观察都可以增加证据，但各有自己的控制者和失败模式。决定方自己的序列能防止偶然乱序，不必然抵抗决定方改写；渠道序列能证明渠道内部先后，不必然证明控制何时送达。即使得到可靠的“之后”，它也只证明在公开假设下的时间优先关系，不自动证明因果、收到命令或具备执行条件。

运行代码应当能保留“不知道”

草案按RFC 7942列出的Implementation Status称，作者维护的配套仓库拥有20个一致性用例和4个离线fixture，并发布了0.13.0版。更关键的是，它没有把这些数字包装成独立验证：第02版只改文字，没有增加顺序测试；两只时钟的关系被说明，但没有执行。来源还承认没有测量真实渠道日志、没有已知独立实现，公开测试时间是在事后写入，没有时间预承诺。

因此，下一组有价值的fixture应覆盖明显早于、明显晚于、落在偏差内、时钟不可比和事后补写等情况。成功标准不是让系统对每项都下结论，而是证明“不知道”可以穿过验证器、报告和下游决策，不会被界面悄悄改成“之后”。

来源

  1. IETF Datatracker：Cedulon Decision Profile
  2. IETF存档：draft-dogru-cedulon-decision-profile-02
  3. Cedulon配套仓库
  4. IETF Datatracker：Cedulon核心草案
  5. RFC 7942：让运行代码的状态可见
  6. RFC Editor：RFC如何形成
  7. Heng Lu：The Bill of Rights of Uniqueness Coordination