摘要

  • draft-ietf-scitt-receipts-ccf-profile-04 的包含证明携带候选叶子和一串标明左右方向的兄弟哈希，但没有显式叶子序号，也没有树的大小。
  • 这不会妨碍验证者逐层计算并核对签名根。问题只在下游把“确实包含”悄悄扩大成“处于某个顺序位置”时出现。

从结果倒推序号，最容易在整齐的树里显得理所当然。两片叶子时，路径 1 指向序号 1；树长到三片叶子，同一条路径指向序号 2；长到五片和九片，它又指向 4 和 8。方向信息没有撒谎，只是它从来没有承诺描述完整的坐标系。

这项修正发生在 IETF 对 CCF Profile for COSE Receipts 第 04 版的最后征求意见期间。Datatracker 显示，该文本属于 IETF 流，目标状态为 Proposed Standard，已经提交 IESG，目前仍处于 “In Last Call”。征求意见从 8 月 24 日持续到 2026 年 9 月 7 日。它仍是 Internet-Draft，不是 RFC，也没有因为这项评论而被 IETF 接受或否决。

包含关系成立，不等于序位已经给出

草案采用与 Certificate Transparency 相近的树形规则：叶子数超过一时，以小于总数的最大二次幂为分界。叶子数恰好为二次幂，树是平衡的；多出来的叶子会构成较小的右侧子树。

第 3 节把包含证明写成候选叶子加兄弟哈希数组，每个兄弟哈希旁边有一个布尔值，表示它位于左侧还是右侧。文本称，这些方向位可以按从叶子到根的顺序，视为叶子序号的二进制分解。这个说法在平衡树中成立，在同一分割规则允许的全部树形中却不成立。

9 月 6 日，Henri Sirkkavaara 修正了自己先前的审阅意见。他枚举了叶子数 2 到 11 的树：2、4、8 没有偏差；其他每一种非二次幂大小，至少有一片叶子的方向路径会解出错误序号。

Emek Can Dogru 随后独立复现，并公开了十一行程序。把范围扩大到 2 至 1,024，只有十种二次幂大小能让每片叶子都准确；其余 1,013 种大小至少错一片。复现源码 很短，也把问题限定得很清楚：这不是概率事件，更不是哈希碰撞。

例如，三片叶子的树里，实际序号 2 会被解成 1；五片叶子时，序号 4 也会被解成 1；九片叶子时，序号 8 仍会被解成 1。路径看到的是从本地叶子向上走的左右关系，看不到整棵树在另一侧还有多大。

但第 3.2 节规定的根验证仍然可以成功。验证者以候选叶子哈希为起点，按路径指定的左右位置逐个组合兄弟哈希，最终得到一个根。如果 COSE 签名覆盖的正是这个根，候选叶子的包含关系便得到验证。这个运算不需要先恢复全局序号。

因此，真正的边界不是“证明有效还是无效”，而是证明回答了哪个问题。它可以回答“这个候选项是否位于签名根之下”，却未必回答“它是第几项”。只有下游把前一句显示成后一句，技术上的窄结论才会变成制度上的宽授权。

参照标准把坐标单独绑定

RFC 9162 的 Certificate Transparency 2.0 在验证包含证明时，明确把树大小和叶子序号作为输入。RFC 9942 为这类树定义 COSE 收据时，也编码了树大小与叶子序号，并说明序号只相对于给定树大小才有意义。

这两个字段不只是实现便利。它们定义了“位置”所在的坐标系。没有树大小，孤立的序号并不完整；既没有树大小也没有序号时，同一个左右路径就可能落在多个全局位置。

真实的 CCF 部署也许掌握更多上下文。微软的 CCF 收据验证文档以交易标识取回收据，commit_evidence 还可能暴露完整 TxID。SCITT 配置也有 internal-evidence 文本字段，但它允许验证者忽略该字段，也没有把它定义成跨实现的叶子位置语法。某个系统能靠本地数据库查回位置，不等于收据本身携带了这个位置。

两位审阅者都把问题称为非阻塞，并继续支持发布。他们没有报告伪造签名、错误根、实现入侵或已部署事故。在后续讨论中，Sirkkavaara 进一步指出，单靠路径长度仍需先知道树大小，因此更倾向显式序号。这是协议语义校准，不是漏洞公告。

风险发生在验证之后

收据很少停留在密码学库里。它会进入软件发布策略、审计记录、透明度看板和自动处置系统。如果系统只关心某个对象是否提交，现有包含证明可能已经足够。如果规则关心先后、排名或序列号，它就需要额外保存构成位置结论的输入。

Heng Lu 的最小初始规范给出了合适尺度：公共规范只固定必要且可验证的最小断言，更强保证由有需要的系统明确采用。现实层提醒我们，数学关系与机构对顺序的叙述不是同一层。运行代码优先则要求保留验证器真正读取的值，而不是事后替一盏绿灯补写含义。

这份草案不必因为少一个坐标就失去价值。它只需克制名称：签名了包含关系，就把它当作包含收据；要让序位产生后果，就把树大小或显式序号也绑定进去。

来源

  1. IETF Datatracker 文档记录
  2. IETF 文档事件记录
  3. CCF Profile for COSE Receipts 第 04 版
  4. IETF 最后征求意见公告
  5. Henri Sirkkavaara 的修正意见
  6. Emek Can Dogru 的独立复现
  7. 关于修复方式的后续意见
  8. 公开复现源码
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. CCF 收据验证文档
  13. Heng Lu：最小初始规范
  14. Heng Lu：现实层
  15. Heng Lu：运行代码优先