摘要

  • IESG 于9月2日就证书申请远程证明草案第29版启动最后征询，意见截止日为9月16日；草案尚未成为 RFC。
  • 多个验证方支持同一格式标识时，如何消除选择歧义由相应格式规范处理。能够读取载荷，不足以说明双方对处理目的地已有共同约定。

证书自动化接入一项设备证明服务，首先面对的可能不是计算能力，而是派送规则。收到一份熟悉格式的证明后，系统应将它交给哪个验证方？如果两家都声称支持该格式，这个问题仍然存在。

这正是 IETF 新一轮审议涉及的一个具体边界。9月2日的最后征询公告请求公众就 draft-ietf-lamps-csr-attestation-29 提交意见，截止日为9月16日。IESG 正考虑将其推进为 Proposed Standard；这不是已经批准的 RFC，也不代表相关机制已经部署。

草案为 PKCS#10 与 CRMF 证书申请提供携带远程证明的共同结构，兼容标准化和专有格式。证书颁发机构 CA 或注册机构 RA 可以自行验证，也可以把材料送给外部验证方。共同载体减少了传递格式的分歧，却没有替所有使用者选定同一个处理者。

格式相同，处理约定仍须明确

第29版第4.3节直接提出：多个验证方支持同一证明格式的对象标识符 OID 时，派送可能出现歧义。文本建议采用不同 OID 区分验证方或验证类型，即使底层结构相同；也可以在封装中提供明确提示。具体的派送和随机数选择机制，应由证明格式的规范规定。

OID 在这里不是服务器地址。它指明格式，但格式本身未必唯一确定处理服务。格式设计者因此还要回答接收端如何解释提示、如何识别预期的验证类型。该草案没有统一包办这一层，而是标明了由谁继续完成规范工作。

对运营方来说，治理问题落在维护这份映射的人手中。改变派送规则，可能改变实际评估设备证据的服务。采购或接入说明若只列“支持哪些格式”，读者仍不知道系统将依据什么选择验证方，以及缺少提示时会采取什么行为。

不要混淆内外两层编号

截至核查时，IANA 的 S/MIME 属性登记表将59号列为 id-aa-evidence。第29版要求保留59这个值，将名称改为 id-aa-attestation。这是外层证书申请属性的登记，不是验证服务目录；也不能据此认为里面每一种证明格式都由同一套登记程序分配。

草案第4.2节把各证明格式的 OID 留给格式作者，从其控制的编号分支中分配。外层共同结构与内层格式，维护责任并不相同。查到外层登记项，仍不能确定某个部署如何挑选验证服务。

RFC 9334说明了为什么这个选择值得单独看：验证方的管理者制定证据评估策略，依赖方的管理者制定如何使用评估结果的策略。把材料发往某个处理者，可能同时选中了一个评估环境，而不只是选中一台读得懂字节的机器。两种角色可以由同一组织承担，但责任不能因此混写。

一个有意义的接入测试，是把相同格式的材料置于不同、已约定的派送条件下，检查是否到达预期验证方。这是本文提出的检验方法，不是草案新增的强制条款。后续安全职责也没有被派送成功替代：第29版仍要求 CA/RA 对证明与申请公钥之间的绑定负责。

目前查阅的材料没有提供误派送事故、供应商锁定程度或迁移成本数据。新闻价值在于最后征询中的责任划分：共同封装可以方便材料流动，服务选择能否互通，还取决于另一份写清楚的约定。

来源

  1. IESG 最后征询公告
  2. 证书申请远程证明草案第29版
  3. RFC 9334 远程证明架构
  4. IANA SMI 编号登记