摘要

  • 远程证明报告可能必须在 SUIT_Command_Invoke 之前完成签名；suit-report-reason-invoke-pending 只说明即将尝试调用，最终结果仍未知。
  • SUIT_Record 是借清单压缩过的路径坐标。没有与 digest 精确匹配并通过验证的清单，就不得用这些记录重建执行过程。
  • 可靠决策必须分别保存签名、鲜度、清单、报告环境测量、控制权交接、首次执行、持续运行与服务效果的凭证。

一份不能等到“事后”的报告

设备已经核验 SUIT 信封，走过清单中的条件和指令，接下来要执行调用。问题在于，被调用的代码可能不会把控制权还给 Manifest Processor。若远程证明要求报告由当前环境签名，签名动作只能发生在交接之前。

工程上最省事的做法，是先写“成功”，再跳过去执行。这样上游能及时收到一个签名完整、格式漂亮的对象。但它把尚未发生的未来写成了过去式。

draft-ietf-suit-report-22 专门为这个时间差定义 suit-report-reason-invoke-pending：调用即将被尝试，最终结果尚不清楚。草案解释，如果调用最终失败，预先签署无条件成功会造成误导。

这不是失败码的同义词。它也不是“基本成功”。它把签名发生的时间边界公开出来：报告系统已经走到交接点，但还没有资格陈述交接后的事实。

密码学可以证明一句话是谁说的、有没有被改，却不能让这句话提前变成真。签名越强，越需要限制它实际覆盖的时间和对象。

这份日志的一半含义在清单里

SUIT 报告并不复制完整执行日志。SUIT_Record 保存依赖树路径、当前命令序列、序列内字节偏移、组件索引和测量属性。具体是哪条指令、位于什么上下文，要回到原始 SUIT Manifest 才能解释。

这种把清单当作字典的设计节省受限设备的带宽和存储，却带来严格前提。报告接收方只有在取得匹配清单，并使用 suit-report-manifest-digest 完成验证后，才能重建记录。若根清单带 suit-reference-uri，报告里的 URI 还必须完全一致。没有匹配清单时，草案明确禁止用 SUIT_Record 做清单重建。

为什么不能只看序号？因为多名受信签署者可能产生相同 sequence number。序号可以描述各自历史中的顺序，却未必唯一指向某份清单。特征 digest 才把报告锁定到给这些偏移和索引赋予意义的那组字节。

system-property-claims 是有限例外：它直接携带组件标识，因此可以在尚未取得清单时单独处理。这个例外反过来说明，只有组件索引和字节偏移的 waypoint 并不能自我解释。

因此，只归档报告、不保存清单，不叫完整留证。报告仍然真实，却像一张没有图例的路线图，无法安全还原。

鲜度证明也不能代替结果

报告可用 suit-report-nonce 承载鲜度或防重放信息。如果外层认证容器已经提供鲜度，例如证明交互本身带挑战值，该字段可以省略。

这里至少有四个不同问题。签名回答内容是否来自预期密钥且未被篡改；鲜度回答它是否属于当前交互；manifest digest 回答该用哪份清单解释记录；结果字段回答处理器在签名时刻愿意陈述什么。

一份新鲜的 invoke-pending 仍然只是“即将调用”。上一轮启动的成功报告即使签名有效，也不能证明这一次启动。清单匹配精确，也不能自动证明报告生成环境可信。

如果界面只显示“验证通过”，就把多项不同核验压扁成了一个含义不明的绿灯。

测量“负责测量的人”

第 22 版草案明确指出：SUIT Report 要作为 Attestation Evidence 使用，生成报告的环境也必须被测量。通常包括执行清单命令的 Manifest Processor、组装报告的 Report Generator，以及承载它们的 bootloader 或操作系统。

原因并不抽象。被篡改的报告生成器仍可能使用合法密钥，签下一份内部自洽的故事。被替换的处理器也可能如实记录“错误代码”所做的决定。容器验证只保护输出；环境测量让验证方判断谁产生了这些输出。

RFC 9334 进一步分开角色。Attester 产生 Evidence，Verifier 按策略评估并产生 Attestation Results，Relying Party 再作信任与访问决定。信任是决策，可信性是系统属性，两者不能因为有签名就合并。

SUIT 的 waypoint 也不是 Relying Party 可以直接消费的业务结论。Verifier 需要取得匹配清单，重建路径，再转换成可供评估的 claims。缺少精确清单或环境测量时，结论可能格式完整，却证据链不完整。

安全传输只保护边界，不会跨越边界

草案要求设备向远端发送状态报告时使用已认证、保密的信道，或者放在具有相当保护的机制中。EAT 内的受保护测量、COSE 容器和安全传输都可以承担这项职责。如果本地政策要求认证，设备不得退回未认证报告；部分报告也必须满足同样的完整性规则。

这些要求防止伪造、修改和泄露，非常重要。但一份机密、已认证的 invoke-pending，含义仍是最终结果未知。传输层不会在途中替设备完成调用。

交接之后必须出现新的观察者。它可以是启动测量、watchdog 心跳、应用健康记录或外部探针。还应区分“入口执行过一次”和“在要求的时间内持续正常”。短暂启动不是服务结果。

把交接后的事实接回来

最小证据档案先保存报告原始字节、认证方法、签署者和验证结论，再保存鲜度机制。然后以根清单 digest 取得完全匹配的清单，重建依赖路径、命令序列、偏移和组件。接着评估处理器、生成器、bootloader 与 OS 的测量值。

报告结果应原样记录：成功、明确失败、隐式交接或 invoke-pending。不要用后来的结果覆盖原来那一刻的陈述。

之后再接入运行期凭证：控制权到达入口、代码持续存活、服务从指定观察点达到目标。完整链条是：

认证报告 → 鲜度 → 精确清单 → 路径重建 → 报告环境测量 → 控制权交接 → 首次执行 → 持续运行 → 服务效果

研究冻结时，第 22 版仍是拟成为 Proposed Standard 的有效 Internet-Draft。Datatracker 显示它已在 RFC Editor 队列，但因第二代引用尚未收到而阻塞。它不是 RFC，更不是部署成功证明。

来源