摘要

  • 9 月 23 日提交的 CCF COSE 收据规范草案第 05 版，不再只申请一种可验证数据结构算法，还申请两项对应的证明类型。
  • 第 04 版仅要求登记 CCF_LEDGER_SHA256；新版把纳入证明的 -1 标签和一致性证明的 -2 标签明确归在拟议的结构编号 2 之下。
  • 这是申请而非分配。IANA 的现行 COSE 表只列出结构 1 及其两类证明，新稿仍待复核。

若把公开登记表看作验证软件共同使用的字典，旧稿缺的不是算法名称，而是字典的后两页。软件即使读到一个表示 CCF 账本结构的数字，也需要知道可收到哪些证明、各证明的编码应如何解释。IANA 在 9 月 12 日审阅第 04 版时指出：申请登记了可验证数据结构，却没有要求登记证明类型。SCITT 工作组 9 月 23 日提交的第 05 版，针对这一具体缺口添加了成对的申请。

两份登记表承担不同工作。算法表中的拟议条目名为 CCF_LEDGER_SHA256，请求值为 2；证明表则针对该结构请求纳入证明 -1 和一致性证明 -2。现有证明表确实出现了 -1 与 -2，但它们属于结构 1，即 RFC9162_SHA256。孤立的负数标签不足以标识 CCF 的证明格式，必须连同结构编号一起理解。新版还将受保护头中的 vds 用于结构标识，将非受保护头中的 vdp 映射用于按类型携带证明，与 RFC 9942 的 COSE 收据框架接轨。

这一修订有清晰的程序边界。草案把 2 写成“请求分配”，并保留占位符；它并未宣称 IANA 已给出号码。Datatracker 的记录显示，旧稿曾处于 IANA - Not OK，新稿上传后变为 Version Changed - Review Needed。页面上先前专家审阅的状态仍标示 Issues identified。与此同时，IANA 公开的两个表都没有新增 CCF 行。所谓“新版本获准张贴”也只是文件进入草案库，不能等同于编号获准或 RFC 已发布。

证明的能力边界同样写在第 05 版中。检验一致性时，验证者要把重算出的旧根与自己此前已经验证的根比较，而不能把收据同时带来的一个旧根当作独立锚点。草案也明确说，一致性收据本身不说明账本内容，更无法保证登记政策被正确执行。这里发生的新闻不是“收据获得了更高权威”，而是一个供不同验证者共同理解的格式申请得到了补齐。

资料来源