摘要

  • draft-poirier-rats-eat-da-10 的 RATS 征集采纳将于 2026 年 9 月 11 日结束。它问的是工作组是否应接手一份个人草案，不是已经采纳的结论、RFC 或部署指令。
  • 设备分配令牌可以携带关于设备的证据；它不能选择额外安全约束、评估证据、设定依赖方策略，或授权设备进入某项工作负载。

被征询的是工作项，不是可信设备

公开对象有明确的名称和版本：第 10 版 An EAT Profile for Trustworthy Device Assignment。Datatracker 仍把它列为活跃 Internet-Draft、RATS 的候选文本，并非 IETF 背书的标准文件。9 月 11 日前的实际问题很窄：工作组是否愿意处理这份文本。日后即使形成工作组处置，也只是改变工作项的程序状态，不能为某张网卡、GPU 或虚拟功能签发某个工作负载中的准入结论。

这里的技术场景确实重要。设备分配让可信虚拟机控制网络适配器、GPU 或 PCIe 功能，而主机管理程序或其他虚拟机可能并不在该虚拟机的信任边界内。草案要求设备提供有关身份、固件和配置的证明，并把这种证明表示为 EAT 配置文件，即 Device Assignment Token（DAT）。

可互操作的表示本身很有价值。它能让不同实现以更一致的方式描述声明、子模块、签名和封装。可是，统一表示不会让观测自动完整、足够新鲜，或自动适合某一工作负载。共同格式减少的是记录的歧义，而不是记录之后必须作出的判断。

额外约束没有装在令牌里

草案把这个界限说得很清楚：格式以 SPDM 提供的信息为基础，并不施加额外安全约束；其他实体应按照运行要求描述、选择并执行这些约束。这不是可以靠乐观推断填补的空白，而是控制权仍然所在的位置。

工作负载的拥有者仍要决定接受哪些信任锚、哪些固件和配置状态可接受、证据允许多旧、哪些撤销信息相关、信任哪个验证者、是否允许转发结果，以及失效后如何撤回。一家云租户、共享 GPU 的平台运营者和处理敏感密钥的组织可以使用同一令牌语法，却合理地作出不同结论，因为他们承担的损失与义务不同。

草案当前范围也要求克制：重点是支持 SPDM 的 PCIe 设备；芯片内 SPDM 设备留待未来考虑；可信虚拟机的实时迁移不在覆盖范围内。文本自己列出这些边界时，不能把它包装成适用于所有设备分配架构的安全结论。

验证者结果不是依赖方授权

RFC 9334 区分两步。验证者用证据、参考值、背书和自己的证据评估策略生成认证结果；依赖方再用自己的认证结果评估策略作出特定于应用的决定，其中包括授权。两套策略可以由不同、各自负责的所有者提供或配置。

RFC 9711 也给出限制：EAT 可以描述一个实体，供依赖方作信任判断，但它不为验证者规定一套规范性的处理规则。验证者可依其策略转发、修改或补充声明；依赖方在解释结果前必须了解该处理规则。因此，签名有效、格式正确的令牌只是关于一个工件的证据，不是“允许该设备”的可移植命令。

RATS 章程与此一致。它把证据和认证结果的格式及传递程序列为工作内容，却把评估策略的格式与协议排除在范围之外。这不是标准化的失败，而是必要分工：共同格式可以流动，却不能假装替每个组织选择风险承受度。

两张凭据，对应两种责任

公共凭据应保持精简、可核验：征集采纳、日期、准确版本、配置文件覆盖范围、不附加约束的明示语句、反馈及后续处置。它绝不能被夸大成“RATS 批准了这台设备”。旁边应有本地决策凭据：设备及分配情境、证据来源、接受的信任锚、验证者身份和处理规则、参考值、新鲜度、策略版本、授权范围、责任人、监控和回退路径。

下一步值得观察的是征集采纳的书面结论、第一份工作组版本以及配置文件范围的明示变化。任何有关部署的结论则应另看依赖方策略、验证者的评估基础、授权决定和实际运行观测。分开保存这些记录，是保护共同格式，而不是把它冒充为它不拥有的权力。

来源

  1. RATS 对 draft-poirier-rats-eat-da-10 的征集采纳
  2. 草案 Datatracker 记录
  3. draft-poirier-rats-eat-da-10 正文
  4. RATS 工作组章程
  5. RFC 9334
  6. RFC 9711