摘要

  • IESG 于 8 月 24 日对 draft-ietf-rats-endorsements-09 启动 Last Call，评论截止日为 9 月 7 日，拟议发布状态是 Informational RFC；证据截止时没有批准决定。
  • Anton Sokolov 在署名公开评论中指出，“声明内容不随时间变化”与“作出声明的 Endorser 仍具有效资格”是两个问题，并追问历史 Evidence 应按生成时点还是评估时点检查背书者资格。
  • 作者说明 CoRIM 已把内容有效期和签名有效期分开处理。评论者接受了这一技术答案，编辑仍决定把区别写入草案源码，留下可追踪痕迹。
  • PR 76 于 8 月 28 日合并。当前编辑版新增 rim-validity、signature-validity、撤销和信任锚检查的解释，但这些段落尚未进入正式编号第 09 版。
  • 一份“评论到规范”的处置回执，应连接评论、答复、差异、合并、下一编号版本、协议政策选择、评估输出与最终 IESG 处置，防止把编辑合并包装成 IETF 批准。

正式流程仍没有结尾

8 月 24 日的公告只做了一件制度上很明确的事：IESG 邀请整个 IETF 社区审阅 RATS Endorsements 第 09 版。RATS 工作组申请将其发布为 Informational RFC，实质性意见可在 9 月 7 日前提交。

这不是批准通知。Datatracker 在本稿证据截止时仍显示“In Last Call”，编号版本是 09，没有 telechat 日期，也没有最终 IESG action。后续源码已经发生变化，并不会自动改写这条正式状态。

RATS 架构处理的是远程证明中的角色和消息。Attester 产生关于系统状态的 Evidence；Verifier 结合 Reference Values、Endorsements 与 Appraisal Policy for Evidence 进行评估。Verifier Owner 对证据评估政策有权，Relying Party Owner 则对如何使用 Attestation Result 的政策有权。Endorser 可以增加主张，却不能因为签了字就取得最终判断权。

第 09 版第 5 节先把 Endorsement 本身的时效机制交给具体协议文档，例如用证书有效期实现；接着又说，如果 Endorsement 增加的是 Environment 的不变量，即“static”声明，那么声明内容无需额外的时效步骤。

两句话各自成立。问题出在读者可能把第二句当成第一句的终点：内容是静态的，所以与时间有关的检查已经全部完成。

静态事实不会冻结作出判断的人

Anton Sokolov 在公开 Last Call 评论中把这个区别说得很具体。某个芯片的物理属性可以不变，但制造商的证书可能到期，密钥可能被撤销，Verifier 也可能从信任锚集合中移除相应条目。声明的内容是否恒定，与声明者此刻是否仍被接受，不是一只钟。

他还提出了 T1/T2 问题：如果 Evidence 在 T1 记录设备状态，Verifier 到 T2 才评估，那么 Endorser 的 standing 应按照哪一个时点判断？这条评论支持文档发布，没有声称存在漏洞、受害设备或失败实现。它要求架构把选择说清楚。

这项观察属于公开评论者，不能改写成 Daniel Kade 的“发现”。本文的独立问题是：审议机制怎样证明它收到了意见、如何回答、修改了哪些字节，以及修改在什么时候才取得下一层制度状态。

作者 Thomas Fossati 先在邮件中复述解决方向：Endorser standing 的检查与声明内容的时效在逻辑上独立，T1 还是 T2 由具体协议或评估政策决定。Sokolov 接受这个表述，并建议让 Attestation Result 能看出使用了哪种选择。

随后，讨论找到的不是一套新机制，而是已经存在的结构。Fossati 指向 CoRIM：内容与签名有各自的有效窗口；该处理器在评估时检查签名有效性、撤销状态和信任锚。若结果同时记录 verifier identity，依赖方就有机会解释“为什么这个实现采用 T2”。Sokolov 最后明确关闭了实质关切，认为现有机制已经给出答案。

邮件里的共识足以结束一次对话。编辑选择继续把答案落到源码中。

合并后的文字实际上拆出了三层变化

PR 76题为“Addressing Anton's LC review”，8 月 25 日开启，经过多轮文字调整，获得 Dave Thaler 与 Henk Birkholz 批准，于 8 月 28 日合并，merge commit 为 bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624。

当前编辑版第 5 节不只是补充“记得检查撤销”。它先区分静态匹配条件与 Endorser 的判断。一个固件测量值可以保持相同；Endorser 早先认为它可信，后来因为新漏洞而判断不可信。两个判断都可能由始终具有有效资格的同一 Endorser 签发。于是需要用内容有效期判断哪一份 Endorsement 适用，CoRIM 的 rim-validity 为此提供窗口。

然后才是第二只钟：Endorser 自身的 standing。签名密钥、证书和信任锚状态可能变化。CoRIM 用 signature-validity 约束签名有效期，并在评估时结合撤销与信任锚状态检查。其他协议或政策可以选择不同参照时点，但必须说明选择。

从操作上看，其实有三条时间线：Environment 属性或匹配值、Endorser 对它的判断、Endorser 本身的资格。把它们压缩成一个“valid”字段，会让正确的局部检查拼成错误的整体结论。

源码已变，不等于正式文本已变

PR 的审阅、批准和合并都有公开证据。当前渲染页的标识却是 draft-ietf-rats-endorsements-latest，而不是编号第 10 版，更不是 RFC。Datatracker 上接受 Last Call 的仍是第 09 版，里面没有新增段落。

这种差异本来就是编辑工作流的一部分。Internet-Draft 可以更新，编辑需要先在工作源码中吸收评论，再提交新的编号版本。真正的风险是引用时删掉状态标签：“编辑接受了修正”“工作组提交了第 09 版”“IESG 批准发布”听起来像同一事实的三种说法，实际上分别属于编辑处置、工作组提交和 IESG 权力。当前证据只支持前两项，而且两项指向不同文字快照。

Heng Lu 所说的“授权洗白”在这里非常直观。GitHub merge 可以证明编辑接受了哪些字节，不能替 IESG 产生决定；反过来，正式第 09 版的流程地位也不能抹去已经合并、且对理解问题很有价值的新文字。

为评论建立一条处置链

所需证据已经公开，只是散落在 Mail Archive、GitHub、编辑版与 Datatracker。可以用一份精简回执把它们连起来，而无需创设新的审批机构。

回执应记录贡献的稳定链接、日期、贡献者、受影响版本与章节，以及“接受、部分接受、由现有机制回答、延期或拒绝”等明确处置。随后连接编辑答复、issue 或 PR、head 与 merge commit、审阅者、合并时间，并用有限文字说明改了什么、没改什么。

下一段必须回到正式流程：哪一个编号 Internet-Draft 首次包含修改，IESG 后来采取了什么行动，最终是否有 RFC。对于本案，还应记录内容有效窗口、Endorser standing 窗口、Evidence 时间、评估时间、选择 T1 或 T2 的协议/政策所有者，以及足以解释结果的 Verifier 或政策版本。

回执不能取消非结论。一条评论得到技术回应，不等于代表 IETF 共识；一次源码合并不等于批准发布；一次签名检查也只能说明特定信任路径下的完整性与来源，不能独自证明声明真实、机构有权或设备可信。

这份记录不需要公开私下讨论。稳定链接、哈希、角色、时点与处置状态已经足够。它的作用不是替代邮件列表、编辑、主席或 IESG，而是阻止每一层冒充下一层。

来源