摘要

  • SCITT 主席于 9 月 25 日正式征询，是否将 MMR 的 COSE 收据个人草案纳入工作组后续工作；回复截止 10 月 9 日。
  • 7 月 IETF 126 会议统计的是愿意审稿的人数，不是接纳表决；当前版本仍为未获 IETF 正式背书的个人 Internet-Draft。
  • RFC 9942 明言，不应预设不同可验证数据结构之间可以互通。验证者须真正识别并执行所选结构的证明规则。

这次新闻不是某种收据已经成为标准，而是标准制定者正在决定要不要承担它的后续维护。SCITT 主席的 9 月 25 日邮件要求社群说明支持或反对 draft-bryce-cose-receipts-mmr-profile-03 的理由，并交代是否愿意审阅、参与或实现。邮件把“接纳为进一步工作的基础”与“文稿已经完成、可以发表”明确分开。10 月 9 日只是回信期限，不是预定批准日。

这一措辞也纠正了对 7 月会议的易见误读。IETF 126 的 SCITT 纪要记录，在场 34 人中，四人愿意审稿、无人表示不愿审稿、三人无意见；当时的问题是参与评审，而非工作组接纳。Datatracker 现在仍把 -03 列为个人提交的有效草案，说明它没有 IETF 的正式标准地位。会议兴趣、邮件征询、工作组接纳和最终规范，是四个不同状态。

草案的技术对象相当具体。MMR 即 Merkle Mountain Range，以后序排列的二叉树和若干“峰”构成累加器。提案分别编码纳入证明与一致性证明：前者把某个候选条目连到指定账本状态，后者检验较早状态与较晚状态的关系。收据在受保护的 COSE 头中标明数据结构，证明材料则有自己的格式；分离的载荷要求验证者先由证明重算根值，再验证签名。这并非“能解析 COSE 就能验证 MMR”。

RFC 9942 为 COSE 收据提供共同外层，却明确提醒实施者不要期待不同可验证数据结构天然互通。SCITT 已有另一份 CCF 收据工作组文稿。即使两个格式都使用同一框架，能够验证 CCF 的程序也不会自动获得 MMR 的证明算法。征询的实际治理问题，是谁来继续打磨第二种专用格式，以及将来怎样让依赖方辨认自己的验证能力，而不是为任意收据盖一枚通用印章。

草案还指出，纳入证明不判断一笔登记本身是否合法，也无法发现从未被纳入的项目。本文不把这条一般性限制当成新发现；更窄的判断是：依赖方要明确询问验证软件支持哪种结构标识、哪类证明、哪一版规则，并以可重复样例检查纳入与跨状态一致性。这是编辑提出的采购核查法，不是 SCITT 已通过的符合性条款。

来源