摘要

  • 2026 年 9 月 24 日，draft-irtf-t2trg-taxonomy-manufacturer-anchors-21 的 IESG 冲突审查进入 “Approved No Problem”：它与多个 IETF 工作组有关，但这种关系不妨碍发布。
  • 该文本属于 IRTF 流，拟以 Informational 发布；草案明确只为五种 IDevID 制造方法统一命名，不作评估，也不作数值排名。
  • Avocado、Broccoli、Carrot、Squash 与 Spinach 标出密钥在哪里生成、经过谁的保管，却不能替代熵源、种子交接、工厂暴露、CA 托管和锚生命周期证明。

这次批准只越过一道程序门

“Approved No Problem” 很容易被压缩成“已认可”。RFC 5742 所规定的冲突审查却很窄：IESG 判断非 IETF 流文件的发布是否与 IETF 标准工作冲突。这次答复指出，分类法与 ANIMA、LAMPS、TEEP、RATS、SUIT 有关，但不构成发布障碍。

Datatracker 同时写明：这仍是 IRTF 流 Internet-Draft，不获 IETF 背书，在 IETF 标准流程中没有正式地位。RFC 5743 把 IRTF 研究成果与 IETF 产品分开，RFC 2014 则直接说明 IRTF 不制定标准。因此，9 月 24 日确定的是制度路径，不是产品认证。

草案对自身能力同样克制。它希望用一致名称改善沟通，不评价不同机制；它认为人和流程因素太多，不尝试给缓解措施打分，而把这类工作留给 ISO 27001 等正式过程。名字好记，不代表结论已经产生。

五种名字把风险指向五个位置

Avocado 由设备内部生成私钥。私钥可以不离开设备，但设备随机数必须可信；公钥或 CSR 仍要完整地送到制造商 CA，并与正确序列号绑定。完成后还须永久关闭制造模式，防止设备被恢复到可重新写入身份的状态。

Broccoli 在设备外的工厂系统生成密钥对。它能提前办理证书、降低生产线等待 CA 的风险，却让私钥暴露给制造基础设施。谁能看见、是否落盘、如何传入正确设备，成为主要控制面。

Carrot 以芯片供应商预置的唯一秘密种子为起点。设备和制造商系统可推导同一密钥对，外部私钥副本随后销毁。设备不再依赖本地随机源，但供应商必须维护客户专属种子清单，并安全交给设备制造商。草案把这次种子转移称为最弱环节。

Squash 由设备内 Secure Element 生成并封存私钥。抗提取是结构目标，却不能自动证明器件实现、整机集成、序列号绑定和后续 CA 运作。

Spinach 则由 Secure Element 供应商在自己的工厂生成。它可能使用供应商身份、代设备制造商运行 CA，或连接后者的 CA。已能签名的元件会进入物流，因此运输失窃、激活口令、客户专属库存与证书对应都必须核对。

五条路线没有领奖台。它们只是把应当索取证据的位置暴露出来。

证书无法重放它的出生过程

有效 IDevID 证明某个 CA 对公钥和身份信息签过名。它看不出私钥来自可靠熵源、被工厂复制、由失管种子推导，还是一直留在妥善集成的 Secure Element 中。外观相同的证书，可以对应完全不同的制造风险。

所以还要保存独立的生产收据：批次、方法、芯片和固件版本、生成或写入事件、序列号绑定、CA 交易、制造接口关闭结果。Avocado 需要熵源和锁定证明；Broccoli 需要可见性、留存与传输记录；Carrot 需要种子来源、交接、访问与销毁记录；Squash、Spinach 则要核对器件、预置方、激活与库存。

CA 风险还会跨越设备寿命。其私钥可能泄漏、丢失或被越权使用。烧录在硬件里的锚若无法更新，替换可能意味着实物召回；即使无人攻击，合法操作者失去签名或吊销能力，也可能让整个设备群无法修复。

这正是 Heng Lu 所强调的现实分层：IESG 结果是流程事实，五个名称是词汇事实，证书是配置产物；只有设备确实守住私钥、拒绝返厂重置、验证预期锚，并通过轮换和恢复演练，才构成运行证据。

来源