摘要

  • RFC 9783 为 PSA Initial Attestation 的 Entity Attestation Token 定义了 nonce、client ID、instance ID、implementation ID、生命周期和软件组件等有边界的声明。
  • 受保护的令牌能够支持验证方进行评估；它本身不能证明依赖方应当登记设备、授予权限、保留资格或批准后续操作。

理解这份 RFC 的最佳方式不是问“令牌可信不可信”，而是逐项问：它支持什么事实，谁负责检查，以及哪一项决定仍需由承担后果的人作出。RFC 9334 的 RATS 架构已经把角色分开：Attester 产生 Evidence，Verifier 评估证据，Relying Party 为自己的目的使用 Attestation Result。RFC 9783 细化的是前一段 PSA 证据的表达和保护；它没有让一份令牌跳过评估和本地决策。

nonce 很能说明问题。该配置要求恰好一个 nonce，长度可为 32、48 或 64 字节。它把报告绑定到一个具体挑战，使验证方能检查提交的证据是否新鲜，而不是旧报告的重放。这种新鲜性极其重要，但它只属于一次挑战与一次证据之间的时间关系。它不说明发起挑战的主体有无服务资格，不说明设备所属运营方是否批准，也不说明一份刚生成的报告应该换来长期权限。防重放不是通行证。

client ID 的作用也不能被夸大。它表示从哪个安全域调用了 Initial Attestation；RFC 9783 要求验证方检查它，避免一个端点把自己伪装成另一个安全域。这一检查是实质性控制：不匹配时，报告不应被用来支持该请求。即使匹配，结论也只是调用域得到了区分。它并没有识别商业账户、批准某个客户环境，更没有写出该环境能获得哪些权限。区分调用者和分配权利是两件事。

instance ID 与 implementation ID 更直接显示了 RFC 的克制。前者识别特定 Initial Attestation Key 和实例；后者识别不可变的 PSA Root of Trust 硬件组件组合，而不是某一个实例。验证方可据 implementation ID 查询 Endorser 提供的信息，例如制造商资料或认证状态。一个问题是“哪一个实例产生了此报告”，另一个问题是“报告声明的是什么实现”。两项答案都很有价值，却都不是“这个服务现在必须怎样做”的答案。

生命周期与软件组件的声明亦有明确但有限的用途。生命周期包含主、次状态，RFC 给出不应信任报告的状态范围。软件组件描述 PSA Root of Trust 所测量范围内已装载的代码、配置或其他成分。它们足以使验证方拒绝报告、适用较窄的评估规则，或要求补充材料。但它们不自动证明工作负载当前的业务目的、租户的同意、运营者的授权、异常保留的正当性，更不证明随后发出的命令已经产生预期效果。

因此，即使令牌完全符合技术规则，决策仍可能是拒绝。验证方可以确认签名保护、nonce、调用域、实现和生命周期都符合自己的评估规则；依赖方仍可因设备不在已批准的部署范围内拒绝登记，因 Endorser 信息未齐全而只提供临时访问，或因后果重大而要求另一份操作批准。这不是证明系统失灵，而是明确谁对把技术信号变成现实后果负责。

Heng Lu 关于最小初始规范的观点在这里尤其适用。共同机制的价值在于让有限的共同声明可检验，而不是冒充已经解决了所有未来和本地的决定。运行代码的成功同样只说明已定义的机制确实生成并检查了报告；它不把服务控制、资本风险或人的后果交给一个字段。