摘要

  • 一台设备可同时包含应用、操作系统、固件和硬件等 Target Environment；拥有一组“可信背书者”，并不能说明每个背书者能对哪一层增加声明。
  • 操作系统厂商的签名可以完全有效，但它若描述硬件，仍可能越过授权边界。
  • 第 11 版允许把“背书者—目标环境”绑定放在评估策略、Evidence 或两者之中，因此最终结果必须带回实际采用的授权边。

设想一台设备由四家公司共同构成。应用开发者知道应用版本，操作系统厂商知道发行分支，固件供应商知道启动组件，硬件制造商知道根信任与验证密钥。把四者都列为可信来源，看似合理。

问题在于，“来源可信”只回答消息来自谁，并不回答这个人可以替谁说话。如果验证器把一张可信名单当作整机通行证，操作系统厂商就可能向硬件层注入声明。证书链没有断，签名没有错，权限却已经扩张。

RATS Endorsements 第 11 版用多层设备说明这一点：应用、OS、固件和硬件分别是 Target Environment，各自可由不同 Endorser 补充声明。草案明确指出，验证器只有一组可信 Endorser 还不够；它必须分辨哪个 Endorser 被允许对哪个 Target Environment 提供 Endorsement。

草案给出的例子没有模糊空间：OS Endorser 可以被信任去描述 OS，却未必有权描述硬件。这不是恶意行为才会触发的规则。只要系统把“成功验明身份”误当成“拥有跨层授权”，错误就已经发生。

第 11 版没有把这条绑定固定在唯一位置。它可以写入 Appraisal Policy for Evidence，也可以由 Evidence 声明哪个 Endorser 可为某层补充信息，还可以由两边共同决定。Endorsement 格式需要解释如何处理这条边，但草案没有创造一个放之四海而皆准的线缆格式。

因此，两台验证器面对完全相同的签名内容，可能给出不同的准入结论：它们使用的层级地图、策略版本或 Evidence 内授权不同。若审计记录只有 Endorsement 和证书链，就无法复盘为什么这条声明进入了评估。

这与 RFC 9334 的角色划分一致。Endorser 提供声明；Verifier Owner 掌握 Evidence 的评估策略；Relying Party Owner 决定如何使用 Attestation Result。来源认证、可信度判断和业务动作不属于同一个权力中心。

条件式背书还带来另一层容易混淆的判断。条件匹配只决定某个 Endorser 的声明是否适用，并不直接判定设备是否可信，也不能替代“该 Endorser 是否有权描述这一层”。即使固定点匹配算法运行完全正确，也可能让一个越权来源进入输入集合。

找到正确密钥同样不等于解决了范围。RFC 9711 定义的 UEID 可以帮助验证器定位 Attester 的验证材料；第 11 版仍把密钥适用粒度——单个实例、一个类别或其他声明范围——留给具体协议。密钥对上了，层级授权仍可能没有对上。

可复盘的最小链条应包含：具备新鲜度的 Evidence；Endorser 身份、证书链和有效状态；Target Environment 标识及层级图；授权该 Endorser 描述该层和该类声明的策略边；所选 Endorsement 版本；Verifier 与策略身份；以及 Relying Party 的授权决定和实际执行结果。

Datatracker 历史显示第 11 版处于 IESG Evaluation，并列入 2026 年 10 月 8 日电话会议议程。09 到 11 的差异可以核查，但第 11 版纯文本依然是工作草案，不是 RFC。

CoRIM 第 11 版提供了与 Endorsement 和 Reference Value 相关的具体数据模型。采用它并不会自动证明某个实现保存或执行了正确的授权范围。

来源