摘要

  • 9 月 27 日署期的 SUIT 更新管理草案第 16 版仍是 IETF 工作中的 Internet-Draft；它明确规定扩展的实现与使用均属可选，接收设备的支持情况取决于具体部署，也可以经带外方式获知。
  • 第 15 版曾要求清单作者在投递依赖这些扩展的清单前，确保目标接收设备公布支持能力；新版删去这一普遍表述，但没有凭空产生统一的能力协商协议。
  • 这并不允许把不认识的指令当作执行成功。真正待核对的是目标设备版本、所需可选命令，以及确认其支持能力的证据从何而来。

设想同一批更新要发给几个硬件版本：运维人员可以检查清单的签名，却不能仅凭签名得知每个版本是否认识“等待事件”或“检查最低电量”等可选命令。清单通过完整性验证，是对材料来源和未被篡改的判断；设备能否按照预期解释命令，则要看接收端的实现和部署约定。

IETF 的《SUIT 清单更新管理扩展》第 16 版把这个界线写得更清楚。文件提出版本、软件标识等附加元数据，也列出电量、优先级、授权、版本比较和等待条件等参数或命令。草案开头说明，扩展既不强制设备实现，也不强制清单使用。新版随后说，接收设备是否支持更新管理扩展，属于具体部署的知识，可以通过带外方式建立。Datatracker 此时仍将其列为 IESG 评估后的 AD Followup；它不是正式 RFC，更不能据此推断产品已部署。

值得报道的不是“可选”二字本身，而是从第 15 版到第 16 版的责任措辞变化。旧版明确要求清单作者先确保目标设备公布了必需扩展的支持情况，再投递依赖该扩展的清单。新版用“依部署而定、可以带外建立”的说法替代。它没有规定所有厂商必须使用同一个公开能力目录，也没有提供一套自动协商的网络报文。究竟依赖管理界面、部署配置、相容性测试，还是已有的设备配置文件，必须在具体环境中说清楚；不能把其中任何一种视为草案已经替所有部署选定的答案。

还须避免反向误读：删去作者侧的普遍确认句，并不等于接收端可以无声跳过未知的关键命令。配套的 SUIT 基础清单草案第 6.1 节，把遇到不支持的命令或参数列为可能排除清单的情形。更新管理草案也仍称其定义的命令均可选实现。要判断特定设备遇到未知扩展后究竟如何处理，仍需看适用的基础规则、部署配置与实测结果；单看修订删掉的一句话不足以下结论。

第 16 版的部署章节更具体地指出，权限标识要映射到本地访问控制，电量信息需要来源及准确度，优先级要有本地政策，等待事件还依赖时间、网络或其他设备的信息。它建议管理界面展示设备支持哪些扩展，以及更新在等待还是失败；这里的建议不等于所有设备已经提供了这样的界面。一个分发系统显示“已排队”，也不能因此声称目标设备一定能执行。

所以本篇的问题与“签名者有没有安装权”不同。这里要追踪的是可选功能在投递边界上的能力证明：哪个设备群、哪个软件版本、哪项命令、哪份支持证据。少了这条链路，技术协调文本中留给部署方的选择，容易被误当成标准替具体设备作出的保证。

来源