摘要

  • draft-ietf-suit-update-management-16 明确：更新管理扩展是否实现、是否写入清单都属于可选项，接收方支持能力是部署特定事实，也可能通过带外方式获得。
  • 面向人的版本文字是不可信的展示信息，不能驱动机器决定；能力、授权、等待、安装、激活和实际运行必须分别留下回执。

签名回答不了“这台机器会不会做”

一份有效签名可以证明清单来自预期作者，内容在传输中没有被悄悄替换。它不能证明接收设备的代码里存在某条可选指令，更不能证明这条指令在当前构建中启用。

SUIT 更新管理草案第 16 版把这条边界写得很短，却很重：规范中的扩展可以不实现，也可以不放进清单；接收方是否支持这些扩展，是部署特定知识，可以在协议之外建立。

于是，一个看似完整的发布动作实际横跨四套记录：作者签出的清单、设备能力清册、补足本地含义的部署配置，以及设备执行后的观察。只保存第一套，最强的文档就会被迫替另外三套说话。

带外并不等于不重要。能力事实可能来自采购规格、厂商矩阵、编译开关、启动加载器版本或现场验证。问题在于，这些来源常被压缩成一句“这个型号支持 SUIT”。同一型号可能包含不同固件、不同功能开关，甚至不同的清单处理器。一条可审计的能力声明至少要写明声明者、覆盖对象、实现版本、验证方法和时间。

草案把本地选择称为部署配置：它规定规范故意留白的选项和映射，但不是新的线上格式对象。这意味着它既有决定权，又容易从事件档案中消失。清单哈希相同，不代表两套部署配置会得到相同结果。

第 15 版到第 16 版，责任落点变了

紧邻版本的差异很有解释力。第 15 版曾明确要求：遇到未实现的命令或参数，接收方必须拒绝清单；如果作者依赖这些更新管理行为，也必须先确认目标接收方已经声明支持。

第 16 版用一句更开放的表述替换了这段话：支持知识取决于部署，也可以带外建立。这只是规范文本的变化，不能被写成某个产品已经改变行为。但它改变了审计问题：不能只在协议流里寻找能力通告，还要保存让操作方相信“它支持”的外部证据。

如果那份外部证据没有版本、范围和过期规则，它就成为隐形控制面。它可以让同一份签名清单在一组设备上继续、在另一组设备上停住，却不在清单本身留下原因。

页面上的版本不是处理器的版本条件

草案把版本分成机器面和人类面。

suit-set-version 用受限格式表达可确定比较的版本；suit-parameter-version 把比较符与组件版本条件结合起来。构建元数据不参与语义版本优先级，因此不能进入这套机器比较。

suit-text-current-version 和 suit-text-version-required 则用来帮助操作人员理解当前版本与依赖。后者看起来甚至可以像 >=1.2.5,<2。但“看起来像条件”并不意味着它是条件。清单处理器不得解释或处理这些文字；若人类文字与机器字段冲突，以机器字段为准。

安全章节更进一步，把这些自由文本定义为不可信输入：不能求值，不能执行嵌入标记，不能覆盖机器决定；展示端还必须防止界面、日志或控制字符注入。

这里最容易出现的错误不一定是代码执行，而是证据偷换。控制台可能准确显示“需要 2.0”，随后用一个绿色图标暗示兼容性已经验证。真正的比较回执应另行记录机器字段、被观察的组件、版本来源、比较结果和时间。展示文本只负责解释，不能领取决定权。

优先级是授权请求的输入，不是授权本身

更新优先级采用“数值越小，优先级越高”的顺序，但每个数值区间的意义由本地策略定义。授权条件把这个优先级交给应用判断；若应用不授权，条件失败。

因此，“紧急”不是特权。作者可以表达风险排序，却不能凭一个负数接管现场的决策权。若部署确实规定某个优先级自动放行，那也是本地政策，应当以版本化规则和决策回执出现。

最小证据包括原始优先级、解释它的策略版本、决策主体、结果和时间。否则，“作者认为紧急”会被悄悄改写成“现场已经授权”。

等待是一种有原因、有记忆的状态

suit-directive-wait 可以等待授权、外部供电、网络、另一台设备的版本、某个时刻、当地时间或星期。声明了多个事件时，必须全部满足才可继续。

草案没有规定唯一的等待实现。处理器可以阻塞、注册事件后挂起、轮询，也可以中止并在通知后重新开始。四种方式在重启、掉电、重复下载和状态持久化方面的风险完全不同。

一些事件离开本地定义就根本不存在。当地时间等待要求设备配置时区和夏令时规则，否则应视为不支持。等待另一台设备版本时，部署配置必须定义设备标识的命名空间、唯一范围、版本获取机制和编码；缺少这些定义，同一串字节没有可互操作的对象。

草案因此建议管理界面公开接收方支持哪些扩展，以及更新为何等待或失败；部署政策还应说明等待能否跨重启保留、操作员如何取消、是否有本地超时。

一个“待处理”状态会掩盖至少五种不同情况：指令不受支持、事件映射缺失、条件尚未发生、条件发生但处理器没有恢复、恢复后在其他环节失败。可治理的回执要写明当前状态、未满足事件、信号来源、最近一次计算和下一条合法迁移。

软件标识不是启动见证

suit-coswid 可承载 CoSWID 信息，服务于软件清册、SBOM 和证明系统。它可以设计成可分离元素，让不需要它的中间方或接收方在不破坏清单签名的前提下丢弃。即使不分离，字段存在也不等于每台设备会消费其细节。

CoSWID 描述验证系统应该期待什么，不证明具体设备已经安装、重启并运行它。要证明运行状态，还需要下载、写入、安装、激活、重启与组件测量等后续记录。

与此同时，精细的软件名称和版本也可能帮助攻击者。谁能看到 CoSWID、何时把它分离、哪套策略允许处理，都属于控制边界。

版本判断不如摘要精确

版本号适合回答兼容性问题，却不一定能唯一指向一组字节。草案因此明确提醒：与版本检查相比，image digest 更精确。两个构建可以共享同一对外版本号，却包含不同补丁、编译选项或重新打包内容；相反，一个人类版本串也可能带有机器优先级不采用的 build metadata。

这不会让版本条件失去价值。它说明版本回执和摘要回执回答不同问题。前者说明本地版本规则如何判断范围，后者说明处理器面对的是哪一份具体内容。可审计记录应同时保存比较规则、观察到的版本、内容摘要和组件标识，而不是让一个绿色“版本通过”图标代替全部事实。

同样，suit-condition-image-not-match 只判断当前内容是否不同于给定摘要；它不是安装成功证明。判断结果可以告诉处理器“值得继续”，不能证明后面的获取、写入和激活已经发生。每个条件的输出都应该附带它所使用的输入，避免结果在离开上下文后被夸大。

带外能力也要有自己的数据结构

既然第 16 版允许在协议之外建立支持知识，最危险的做法就是把它留在口头约定里。最小能力记录应当包括设备或设备集合的稳定选择器、清单处理器与启动加载器版本、所支持扩展和命令、验证方法、验证时间、声明者、有效期，以及适用的部署配置标识。

这份记录不需要被伪装成新的 SUIT 线上对象。相反，它应诚实保留自己的本地身份，并在每次发布决定中被引用。这样一来，清单仍然只负责它能证明的内容，能力系统也能独立更新和撤销。

撤销尤其重要。某次固件回滚、功能开关变更或安全缓解措施可能让原本支持的命令暂时失效。如果能力清册只会增加“支持”，不会记录“不再支持”或“未知”，它就会把历史真相错误投射到当前设备。

能力证据还要区分“解析”与“执行”。实现能够识别标签，并不等于它实现了相应语义；实现了语义，也不等于本地政策允许执行。可以把这三层分别记为语法能力、命令能力和政策可用性。任何一层未知，都不应被一个总括性的“兼容”掩盖。

恢复路径必须知道自己从哪里继续

草案允许实现以不同方式等待，其中“中止并在通知后重新开始”特别容易被误读为无状态。重新开始时，处理器仍需知道先前采用的清单、部署配置和条件输入是否保持有效；否则，同一更新会在新的环境里重新作决定。

跨重启保留等待，也不能只保存一个布尔值。需要记录等待事件集合、已满足与未满足项、最近观察值、时钟基础、授权状态和恢复策略。若当地时区在等待期间改变，草案要求重新按新的时区配置评估；这正说明“等待到某时”不是固定字符串，而是依赖环境的计算。

取消和超时同样属于权力动作。谁可以取消，超时后是失败、回滚还是重新排队，不能由仪表盘默认值替代。恢复回执应写明触发者、旧状态、新状态、采用的政策和是否重新验证前置条件。

管理界面还应拒绝把不同未知状态合并成“设备离线”。如果处理器从未实现命令，网络探测成功也无济于事；如果事件源本身失真，重试只会重复错误决定。界面应让操作员看见事实缺口属于能力、映射、信号、政策还是执行阶段，并把人工干预作为新的授权事件记录，而不是直接覆盖旧状态。

这样设计也有利于跨供应商迁移。新管理平台可以重新解释标准化字段，却不能假定旧平台的本地优先级、标识空间与超时含义。迁移包必须携带部署配置和未完成等待的语义，否则“状态已导入”只是复制了一个没有上下文的标签。

最后，等待指标应按原因而非总量计算。网络等待上升、授权等待上升和跨设备版本等待上升，对容量、组织审批与依赖编排提出的是三种不同问题。一个总数会制造安静，分类后的时间序列才会暴露控制面的漂移。

能力成立，也不等于结果成立

假设带外能力记录完全正确，部署配置也完整，设备确实理解所有命令。此时仍然只有“可以处理”的证明，而没有“已经处理完”的证明。最低电量条件可能失败，应用可能拒绝授权，使用期限可能已经过去，等待事件也可能一直不出现。

即使全部条件通过，安装链仍有多个独立阶段。处理器可能已获取组件，却没有写入；已经写入，却没有切换活动槽；已经切换，却在重启后回滚；已经运行新组件，却没有产生预期业务效果。把这些阶段折叠成“部署成功”，会在真正需要恢复时丢失断点。

因此，状态模型需要保留单向和可逆边界：清单已验证、能力已确认、条件已评估、进入等待、解除等待、组件已获取、已写入、已安装、已激活、已观测运行、已观测效果。不是每个部署都必须使用这些中文标签，但不能失去它们之间的事实差异。

从意图到效果，至少十张回执

一套完整记录应分别保存：研究时采用的规范与注册表状态；签名清单；目标接收方；能力声明的来源、范围、版本和年龄；部署配置；机器字段与本地信号；每个条件的结果；等待或失败原因；安装产物摘要；激活/重启；以及最终运行组件与业务效果的观察。

冻结研究时，Datatracker 显示第 16 版已发送批准公告，但它仍然是 Internet-Draft，IANA 动作仍在进行。制度推进值得记录，却不能被夸大成 RFC 编号、实现覆盖率或部署成功。

这并不削弱清单。它只是把清单放回正确层级：它能强有力地证明指令，却不能证明能力、授权与效果。真正可靠的系统，不让一份文件越权代表整台设备。

来源