摘要

  • 2026 年 9 月 24 日，IESG 认定一份关于制造商预置密钥与信任锚的 IRTF 草案虽与五个 IETF 工作组相关，但这种关联不妨碍其发表。
  • 草案为不同制造、置入和保管方法命名，明确不评价优劣；目前仍是等待 IRTF 后续步骤的 Internet-Draft，而不是已出版的 RFC。
  • “不妨碍发表”不能证明某批设备实际采用了哪种方法，也不能回答更新签署密钥遗失时谁有权恢复。

采购清单上的一个词，可能让控制链看起来已经清楚。假设供货方写明“设备端生成密钥”，采购人员又看见 IESG 允许相关分类草案继续发表，便把两件事合并成“设备安全已经得到标准机构认可”。这一步推理没有依据：分类草案给出了词汇，IESG 判断的是发表是否与既有标准工作冲突，而特定设备在工厂中的实际操作、记录与签署权并未因此得到验证。

IESG 的决定针对 draft-irtf-t2trg-taxonomy-manufacturer-anchors-21。该文稿来自 IRTF 的 Thing-to-Thing Research Group，拟以 Informational RFC 发表。9 月 24 日的回复列明，它与 ANIMA、LAMPS、TEEP、RATS 和 SUIT 工作组的工作有关，但这种关系不构成发表障碍。回复同时请 IRTF 检视 Datatracker 中的意见，自行判断是否吸收。当前文档状态仍显示有效的 Internet-Draft 及 IRTF 主席在 IESG 审查完成后的待办步骤；不能把冲突审查完成写成 RFC 已经出版。

RFC 5742 说明了这道边界。对 IRTF 通道文稿，IESG 所审的是与 IETF 工作的冲突，技术价值由 IRSG 判断。此次采用的正是“有关联但不妨碍发表”这一规定答复。因此，这既不是 IETF 标准轨道批准，也不是对某一制造商设备的安全认证。草案页面更直接提醒：这份 IRTF 文稿未获 IETF 背书，在 IETF 标准制定程序中没有正式地位。

草案的实际贡献是让常被统称为“设备信任根”的不同权力能够逐项询问。私钥可以在设备内生成、在设备外生成后转入，也可以基于种子建立；安全元件又带来另外的制造安排。初始启动、软件更新、私有服务和设备入网所依赖的锚，各自授权的操作并不相同。文稿分别讨论替换、增添、删除或损坏锚，以及相关私钥遭窃和无人窃取却失去使用能力等情形。最后一种尤其容易在宣传材料里消失：密钥未泄露，不代表制造商还能合法、及时地签署恢复所需的更新。

失去更新授权锚后，有的设备可以远程更换，有的可能需要专门硬件到场，甚至整机替换。草案也询问生产第一阶段到锁定状态之间的时间与距离、身份基础设施的寿命、制造商侧签署密钥如何保存。它没有给这些答案打分，也没有规定优胜方案、提出 IANA 登记或指控任何现有设备不安全。问题目录与实测证明是两回事。

一项比例适当的做法，是让制造商为设备类别或批次提供“锚保管回执”：列明启动、更新和入网锚的角色，所用置入方式，完成锁定的控制点，制造商侧签署权的责任主体，以及轮换、遗失与替换路径的版本和验证日期。采购或运营方还应记录证据保管人、例外与剩余风险由谁接受。公开回执不必泄露私钥、单台设备身份或工厂细部。这是编辑提出的问责方法，并非 IRTF 草案强制的格式。

此次审查背后没有已证实的产品事故。IESG 放行的是一个共同讨论问题的词汇表，不是对设备制造链的通行证。设备可信与否，仍取决于那些实际拥有置入、签署和恢复权的人能否为具体设备范围交出证据。

资料来源