摘要

  • RFC 10013 的 measured component 保存稳定名称、可选版本、原始值或带算法的摘要，并可附带组件权威标识；该标识说明谁能权威识别或签署组件，不说明谁签署了外层 EAT。
  • authorities 的每个位置、排列顺序与 64 位 profile flags 都由具体 EAT profile 定义。消费方若不认识该 profile，却看到 authorities 或 flags，就必须拒绝令牌。
  • 可复核凭据必须连接组件、采样边界、测量值、组件签名者、profile、attester、时效、参考值、验证策略、证明结果与依赖方自己的授权决定。

一次设备准入失败后，三个团队给出三个解释。

固件团队说，组件签名有效；证明服务说，EAT 签名有效；业务系统说，设备没有权限。表面上只有最后一步“矛盾”，实际上三步可能全都正确。问题在于，它们证明的不是同一件事。

RFC 10013 正面处理这条身份边界。该标准于2026年7月发布，作者为 Simon Frost、Thomas Fossati、Hannes Tschofenig 与 Henk Birkholz。IETF Datatracker 将 Tschofenig 与这份 RFC 及长期安全标准工作联系起来；慕尼黑联邦国防军大学称他自2026年3月起担任 Secure Networks 教授。这些是有日期的贡献与职务证据，不是个人对所有 EAT 部署的控制权。

测量组件只是证据载体

measured component 可以是 flash 中的固件、启动加载器、已载入软件、文件、配置或 CPU 寄存器。RFC 10013 给它一套可传输的数据结构，但没有替应用做结论。

组件名称必填，版本可选。测量值可以是原始 bytes，也可以是“算法＋digest”。此外还可携带 authorities 数组和八个字节的 profile-specific flags。

每项字段都很窄。名称表示生产方声称测了哪个对象；版本区分发布；算法与摘要提供比较输入；authority 指向组件签署或识别关系；flags 留给具体部署。字段齐全并不等于采样环境可靠，也不说明样本是否新鲜、参考值由谁批准、这个状态是否适合当前动作。

“hash 相同”尤其容易被过读。摘要没有记录采样代码是否被欺骗，没有说明目标边界，也没有自带 nonce、采样时间与参考值版本。旧启动状态可以被准确重放，错误对象也可以被完美测量。

RFC 9711 同样限定 EAT 的承诺：它定义消息语义与真实性、完整性保护，并不规定所有 attester 或 claim 收集都达到同一个安全级别。格式正确是下一步判断的输入，不是判断结束。

组件签名者与 attester 分属两层

RFC 10013 把 authority 定义为能够用数字签名权威识别组件的实体。该签名通常在安装时，或由启动固件、操作系统、应用启动器执行组件时验证。其标识可以是 X.509 证书、原始公钥、公钥指纹或其他能唯一联系签名密钥的值。

紧接着，标准明确排除一种推断：这个组件签名与 attester 对 EAT 证据的签名没有必然关系；authority identifier 本身不表示外层 EAT 的签名者。

固件作者对构件出处发言。机群所有者可能追加部署批准。第三方审计者可能再签一次。设备中的证明环境随后观察目标状态，并用自己的密钥对 Evidence 发言。同属一家公司并不会让这些角色自动合并，不同公司参与更不能靠一个 authority 标签抹平。

RFC 9019 从更新侧给出相同纪律：认证签名者只是授权的输入。不同签名者权限不同，关键设备可以要求作者与运营者同时批准。密码学让声明可归属；策略决定声明者能授权什么。

profile 是不可省略的语义合同

一个 authorities 数组可能有多个条目。第一项可能代表更新系统，第二项代表 fleet owner，第三项代表审计者；另一个部署可以采用完全不同的顺序。64 位 flags 也没有跨部署的天然词典。

因此，EAT profile 必须说明是否使用 authorities、每一项代表什么、如何解释其值；使用 flags 时也必须定义每一位的含义。长度固定不等于意义固定。

当消费方不认识 profile，而组件中存在 authorities 或 flags，RFC 10013 要求拒绝 EAT。它不能把未知字段当装饰丢掉，不能借用另一产品的顺序，也不能因为外层签名有效就默认未知语义无害。

这正体现 Minimum Initial Specification：共同层只固定互操作所需的结构、核心字段与禁止猜测的边界；机群自己的角色留给机群 profile。标准没有冒充本地授权者，本地策略也不能冒充通用标准。

上线顺序由此成为安全属性。生产端过早发出新 profile，会让合规 verifier 拒绝；verifier 静默 fallback 则更危险——它宣告成功，却无法重建自己接受了什么。

外层签名之后还有两次决定

典型 EAT 由 attester 生成 claims set，并以证明密钥保护 Evidence；nonce 或其他机制提供时效。verifier 仍需确认密钥来源、Evidence 与正确目标的关联、证明环境强度及 replay 边界。

随后，verifier 用 reference values 与 appraisal policy 评价 Evidence，产生 Attestation Result。RFC 9334 把最终动作留给 relying party：它依据自己的策略，决定特定设备能否对特定资源执行特定操作。

因此，“符合厂商基线”不等于“获准进入企业网络”。一台健康设备可能属于另一租户；一个已批准组件可能无权处理某类数据；一份有效结果可能超过业务要求的时效窗口。拒绝不是前面签名失败的同义词。

完整责任链至少有四个主体：组件权威、attester、verifier、relying party。前者不能借 EAT 代替证明环境发言；attester 不能替 verifier 定义参考值；verifier 不能替资源所有者授权。

稳定名称既利于追踪，也可能追踪用户

RFC 10013 建议组件名称跨版本保持稳定，以便持续识别同一对象。这能改善升级与诊断，却也形成相关性。标准的隐私部分提醒，名称和版本可能暴露软件、配置与设备所有者信息，稳定名称还可能被用于追踪。

长期复用的 authority 公钥标识也会扩大关联。profile 应说明谁真正需要明细。专业 verifier 可能需要原始测量与密钥，业务 relying party 也许只需一个与动作、范围、有效期绑定的简化结果。

数据最小化不是销毁内部审计证据，而是防止一份必要的安全证据变成跨服务的永久设备身份。

把每个判断写进凭据

先保存准确 EAT 或其内容寻址对象，以及 media type、编码、profile 标识与版本。记录外层签名算法、attester key、验证密钥来源、nonce、采集时间、接收时间与 verifier 版本。

逐项保存组件名称、版本规则、目标与采样边界。区分 raw 与 digest；若为 digest，保留算法和值。原样保留 authorities 顺序，连接定义角色的 profile、组件签名材料与验证结果；flags 既保留原始八字节，也保留按 profile 解码的解释。

评价部分记录 reference value provider、数据集与版本、所有比较、缺失测量、verifier policy 与版本，以及准确 Attestation Result。最后记录 relying party、资源、动作、授权策略、决定、限制、到期与修复路径。

这样，“profile 未知”“组件签名者不被接受”“外层签名无效”“Evidence 过期”“摘要不匹配”“设备合规但无权访问”会成为六种不同事件，而不是一个无法处理的红灯。

Running-Code Primacy 要求观察实际代码怎样作决定。若系统只留下 pass/fail，而丢掉输入、主体与策略，绿色状态并不是运行事实的证据，只是界面颜色。

来源