摘要

  • RFC 10013 定义了紧凑的被测组件对象：组件名和原始值或摘要值必填，版本、组件签名权威与由配置文件解释的标志可选；对象可作为 EAT 的 Measurement claim，以 JSON 或 CBOR 表示。
  • 对象提供的是证据，不是裁决。组件权威不等于外层 EAT 的签名者；摘要相等不证明测量范围完整；通过 Verifier 的评估，也不证明设备属于本组织、已经登记或有权访问某项资源。
  • 可审计的系统必须保留整条决策链：测量对象与时点、采集器、EAT 签名与新鲜度、配置文件、参考值、Verifier 策略、Attestation Result、Relying Party 授权规则以及实际结果。

恢复上线按钮前的最后一厘米

设想一台完成硬件维修的数据中心服务器。隔离区里的自动化系统要求它在重新接入管理网络前提交远程证明。

服务器发来一个签名正确、nonce 新鲜的 Entity Attestation Token。被测组件名为“boot loader X”，附有版本和 SHA-256 摘要。摘要与生产参考值相同，authorities 数组中的两个标识也对应获准签署该启动组件的主体。系统识别了 EAT profile，Verifier 返回“compliant”。

界面上的恢复上线按钮亮了。

但这台服务器是否应当获得管理权限，仍未回答。

采集器可能只覆盖了签名过的启动加载器，没有覆盖决定后续模块的可变配置；被允许的参考集合可能还包含刚被披露存在漏洞的版本；设备可能硬件与软件状态正常，却已经从资产清单中退役；它可能只被批准恢复遥测，不得取得管理口令；authorities 的顺序含义也可能只在另一个 profile 中成立。

这些情况并不证明测量是假的。它们证明系统把测量之外的问题塞进了同一个绿色状态。

2026 年 7 月发布的 RFC 10013 是 IETF Standards Track 文档。它解决的是表达与互操作：如何描述一个组件及其被采样的状态，并放入 EAT。它没有替资产所有者、Verifier 或资源控制者决定后果。

测量之前，已经发生了一次权力选择

RFC 10013 所说的组件可以是闪存中的固件、启动时载入内存的软件、运行时完整性检查对象、文件系统对象、配置块或 CPU 寄存器。这个范围比软件清单宽得多。

RFC 9393 定义的 CoSWID 擅长描述软件身份、补丁与安装生命周期。EAT 原先可以携带 evidence 类型的 CoSWID，但早期启动环境、硬件寄存器或不依赖文件系统的对象不一定适合被描述成安装的软件条目。RFC 10013 补上了这种表示空缺。

它没有规定必须测哪些字节。

平台设计者先划定组件边界，采集机制再从这个边界取样。硬件信任根或隔离执行环境可以让篡改更困难，却不会自动发现边界之外的可变状态。对一个过窄对象计算出完全正确的摘要，仍然只是对过窄对象的正确证明。

因此，生产证据不能只保存一个值。还应保存 Target Environment、组件边界、采集器保护方式、采集时间或 boot epoch，以及哪些依赖明确不在测量范围内。“secure boot passed”是界面标签，不是这些事实的替代品。

Heng Lu 的 Running-Code Primacy 给出了检验顺序：标准声明的是共同语义；运行证据必须说明实际读取了什么、后来执行了什么、系统最终允许了什么。符号不能比运行系统拥有更高权威。

小对象里的五类主张

组件名是必填的人类可读标识，命名规则取决于组件类型。RFC 10013 要求同一组件在不同发布版本之间保持名字稳定，以便持续跟踪更新；这并不创建全球唯一命名空间。

两个厂商可能使用相似名字。同一路径 /boot/loader.bin 也可能在升级后指向语义不同的对象。审计必须知道谁命名、按什么规则命名，以及名字如何映射到实际被采样的对象。

版本字段可选，并可复用 CoSWID 的版本方案。信息模型推荐 Semantic Versioning，但没有强迫 CPU 寄存器、配置块和所有固件生态采用同一种发布哲学。版本字符串只有在发布流程与字节映射可追溯时才有证明力。

测量值必须是原始值或摘要值之一。原始值可能只是一个寄存器，也可能是很大的配置块。规范允许解码器限制为它分配的内存；否则证明输入会变成资源耗尽与敏感数据沉积面。

摘要形式同时携带算法标识和值。算法标识依照 IANA Named Information Hash Algorithm 注册表解释，RFC 10013 要求使用强密码哈希。强算法可以保护比较过程不被弱碰撞破坏，却不能证明采集器读对了区域、参考值仍然安全，或测量属于当前启动。

“权威”字段里藏着另一种签名

authorities 数组最容易被界面误译成“这个 EAT 由谁签名”。

在 RFC 10013 中，组件 authority 是能够通过数字签名权威识别已安装组件的主体。标识可以关联 X.509 证书、原始公钥、公钥指纹或其他唯一值。组件签名可能在安装时验证，例如 RFC 9019 描述的固件更新架构，也可能由启动固件、操作系统或应用启动器验证。

它明确不同于 Attester 对外层 EAT evidence 的签名。

前者回答谁批准或识别了这个软件制品；后者回答谁生成并保护了这一组关于设备状态的 claims。把两者合并，会抹掉“谁观察了这个状态、观察发生在哪台设备、观察机制受何种保护”。

数组还可以包含更新系统、设备群所有者、第三方审计者等多个权威。条目顺序可能有意义，但基础规范不定义该意义。使用被测组件的 EAT profile 必须说明是否使用该字段、每个条目代表什么以及如何解释其字节。

flags 也一样。它恰好是八个字节，却没有任何一位在基础规范中具有通用含义。如果 EAT 带有 authorities 或 flags，而消费者不知道适用 profile，规范要求拒绝。按经验猜测位布局不是兼容，而是在无记录地发明策略。

295 和 296 只告诉系统怎样解码

RFC 10013 同时协调 JSON 与 CBOR 数据模型。CBOR EAT 可原生携带 CBOR 被测组件，也可封装 JSON；JSON EAT 可原生携带 JSON，也可用 base64url 封装 CBOR。IANA 已登记 application/measured-component+cbor 与 application/measured-component+json，CoRE Content-Formats 注册表则分配了 295 和 296。

这些登记消除了“这串字节是什么”的一部分歧义，没有回答“它是否足以放行设备”。

这正是 Minimum Initial Specification、Localized Future Decision 与 Voluntary Adoption的建设性边界：共同层只规定交换所需的最小语义与编码；profile、参考值、评估规则和授权后果由承担风险的本地参与者明确决定。

官方 RFC 10013 勘误查询在 2026 年 8 月 30 日显示无匹配记录。这只是查询当日的注册表状态，不是对所有实现的正确性认证。

EAT 统一 claims，却不统一安全强度

RFC 9711 对边界写得很直接：EAT 规范定义 claim 的语义，不为 claim 的实现或 Attester 本身规定某个统一安全等级。接收方要通过理解厂商实现和／或 Verifier 所做的检查，判断 claims 是否可信。

同一种 EAT 格式可以来自高强度硬件保护，也可以来自普通应用。格式一致不等于防护强度一致。

所有 EAT 使用都必须提供新鲜度机制，nonce、时间或其他适用机制用来防止旧 token 重放。然而 token 新鲜，不自动等于每个测量值都刚刚采集。启动时取得的值可以稍后装入一个新 token。审计应分别记录采样、token 生成与 boot epoch。

EAT 还区分 measurements 与 measres。后者可以表示与参考值比较成功、失败、未执行或不存在；RFC 9711 明确说明它不是 Verifier 的总体结果。把 measres=success 渲染成“设备可信”，等于在 UI 层扩大了字段授权。

RFC 9783 的 PSA Attestation Token 是 RFC 10013 数据模型的前身之一。它展示了不同评估思路：要求精确测量值、允许一个发布序列，或接受由已知签名者签署的组件。三种规则承担的风险不同，token 不会替运营方选定一种。

Verifier 负责评估，Relying Party 承担后果

RFC 9334 把远程证明划分为不同角色。

Attester 生成 Evidence；Reference Value Provider 提供预期值；Endorser 为某些能力与信任基础背书；Verifier 按 Appraisal Policy for Evidence 评估并生成 Attestation Result；Relying Party 再按照自身策略决定允许访问哪些数据或执行哪些操作。

同一平台可以兼任多个角色，但逻辑责任不会因此消失。

Reference Value 有提供者、版本、生效时间与撤回状态。漏洞披露后，设备字节可能一位未变，原本允许的摘要却应当转为拒绝。控制参考集合和评估策略的人因此拥有远程改变整个设备群准入状态的能力。

Verifier 把厂商特定 evidence 转换成 Relying Party 能消费的结果，便利也带来信任集中。结果应绑定 Verifier 身份、软件与策略版本、输入 evidence 强度和时间，而不是只留下一个“通过”。

最关键的边界是：健康不等于有权。RFC 9334 举例说明，企业即使认可某厂商所有健康笔记本的状态，也可能只允许自己拥有的设备接入网络。真实、健康的承包商设备仍然不是企业资产。

Relying Party 最了解资源、请求操作、设备登记、账户、资产归属、交易价值与事故状态。Verifier 可以报告它评估了什么，不能替所有下游资源默默决定业务授权。

事故调查必须沿箭头展开

一条完整链路至少包括：

测量边界 → 采集器与时点 → 原始值或摘要 → 命名规则 → 组件 authority 含义 → EAT 签名者与新鲜度 → profile → Reference Value 与提供者 → Verifier 策略与结果 → Relying Party 策略 → 获准操作 → 实际结果。

这条链不能压缩成一个布尔值后再指望恢复。

如果错误软件获得了访问权限，调查要区分：采集器是否漏测、参考集合是否仍然接受、Verifier 是否误执行策略，还是 Relying Party 授予了超过结果所支持的权利。没有中间证据时，每个团队都能指向同一个绿灯，也没有团队真正拥有决定。

Heng Lu 关于现实层与符号权力的分析在这里非常具体。名称、版本、摘要、签名者标识与结果，都是对选定状态的表示。只有持续保留表示与运行现实的边界，这些符号才值得信任。

证据链也会成为攻击者的资产清单

组件名与版本可能暴露软件、补丁级别与配置，稳定命名还可能帮助跨时间追踪设备。原始测量值泄露得更多。

多个消费者会放大风险。第一个服务可能解密并验证 EAT，再把 claim 子集发给其他评估器。失去原始加密封装后，RFC 9711 要求使用等效通信保护，并强调只向每个消费者暴露必要信息。

设备的名义所有权不能回答谁在实际读取证据。Heng Lu 对技术与实践数据主权的区分要求列出 Verifier、日志、追踪、分析、支持与下游服务持有的每一份副本。硬件在机房里，不代表组件状态图也留在机房里。

默认策略应当按用途选择性披露。网络准入服务也许只需一个新鲜、带范围的 Attestation Result；修复服务也许只需版本与参考集合；它们不应自动获得完整配置块与持久设备标识。

标准停下来的地方，正是责任开始的地方

RFC 10013 完成了它应完成的工作：统一被测组件对象，协调 JSON/CBOR，要求 profile 明确定义 authorities 与 flags，要求强摘要，在无法理解依赖 profile 的字段时拒绝，并警告稳定身份的隐私风险。

它没有宣布设备“良好”。

采集器负责边界，Attester 负责 Evidence，组件签名者负责制品来源，Reference Value Provider 负责预期状态，Verifier 负责评估，Relying Party 负责授权，运营方负责组合这些决定带来的后果。

启动测量可以通过。服务器的权利仍须另行决定。