摘要

  • draft-nikolaichuk-scitt-continuity-receipts-01 提议把有状态资产的恢复声明签名后登记到 SCITT 透明服务，并用 RFC 9942 Receipt 证明该声明进入了特定日志位置。
  • 服务可以先返回 HTTP 202 与条目编号；这只证明异步流程已受理，不等于 Receipt。此时若向消费者放行资产，恢复仍是“未被见证”的状态。
  • Receipt 证明的是签名断言被登记，不证明恢复真的发生、证明结果有利、实际字节忠实于原件，或系统在语义和行为上等价。

同一个绿色状态，混进了五种事实

灾备面板上常见一个诱人的状态：恢复成功。它可能只表示解密任务退出码为零，也可能表示应用健康探针已经响应。更精致的系统还会附上一份证明结果、一个日志条目编号，最后把整行染成绿色。

问题不在于这些记录虚假，而在于它们各自回答不同的问题。密钥是否获准释放？恢复环境是否处于某个可接受状态？实际生成了哪些明文字节？恢复机构签署了什么声明？透明日志是否已经收录该声明？消费者最终拿走了什么？

2026 年 9 月 29 日提交的 draft-nikolaichuk-scitt-continuity-receipts-01 尝试给其中一段补上可验证记录。它是一份目标状态为 Informational 的个人 Internet-Draft，不是 SCITT 工作组采纳文本，也不是 RFC。它设计的是恢复声明的载荷和登记方式，而不是新的透明服务、证明格式或密钥放行机制。

它最重要的价值，是拒绝让一个绿色状态吞掉所有现实层。

从密钥到消费者，中间没有万能证明人

草案描述的流程先由恢复环境中的 Attester 产生 Evidence，再由 Verifier 评估并给出 Attestation Results。另一个密钥放行机制决定是否向该环境释放封存材料。环境解密、重组资产，并对真正生成的明文计算 recovered-digest。

Recovery Authority 随后构造 claims，以资产稳定标识为 subject，签成符合 RFC 9943 的 Signed Statement。Transparency Service 根据 Registration Policy 决定是否接收，把声明追加到日志，并依据 RFC 9942 返回 Receipt。Relying Party 最后仍要验证签名、收据、声明、证明引用和自己的使用政策。

这条链故意没有设置一位“全知审计人”。密钥服务只知道自己为何放行密钥；它未必看见最终产物。Recovery Authority 负责其断言，但可能与恢复操作属于同一组织。透明服务见证声明进入日志，却没有重新执行恢复。消费者拥有最后的效果面，也因此不能把前一层的凭证直接当成使用许可。

按照 Lu Heng 关于现实层与运行代码的纪律，共享记录的权威必须被限定在它真正观察到的对象上。登记的权威是登记，不能自动上升为事件真实。

Receipt 的证明对象很窄

草案给出的边界十分明确。Continuity Receipt 证明：某一特定 Issuer 签署的特定 Recovery Statement，被登记到某一特定 Transparency Service 的追加式日志中的特定位置，而且服务对这项事实签了证明。

它不证明恢复事件确实发生；不证明恢复后的字节与原资产一致；不证明被引用的 Attestation Results 已经验证或结论有利；不证明环境实际处于声明描述的状态；也不证明登记策略检查了这些命题。

这不是“证明太弱”。恰恰相反，边界清楚的证明比冒充审计的服务更可靠。Receipt 让断言具有归属、次序、持久性，并使事后悄悄撤回变得困难。它留下可追责的记录，却不会神奇地让错误断言变真。

因此，“收据有效”与“恢复已验证”不能共用一个布尔值。合格的验证界面至少要分开展示：Issuer 声称了什么、独立检查建立了什么、哪些事实仍无法验证。

HTTP 202 是最容易被染绿的一段

当前 SCRAPI 草案允许异步登记。透明服务收到 Signed Statement 后，可以返回 HTTP 202 和条目编号，之后再通过该条目资源提供 Receipt。

条目编号当然有用。它让发行方能够轮询、对账和最终附加收据。但它证明的是工作流已被受理，而不是声明已经包含在日志里。连续性收据草案要求操作方明确二选一：等到 Receipt 再放行，或者在没有 Receipt 的情况下继续，并把恢复记为 unwitnessed，直到收据真正解析出来。

高可用系统有时必须选择继续。若透明服务暂时不可用，而等待会让医院、交易或关键控制系统停摆，恢复负责人可能有充分理由先恢复业务。关键是把这个决定写成受限例外：由谁批准、适用于哪类资产和消费者、持续多久、有哪些补偿控制、何时必须完成对账。

最危险的不是选择可用性，而是让 202 在界面上看起来与 Receipt 无异。只有条目编号而没有收据，仍是一项承诺，不是一项证明。

不要拿期望值冒充测量值

recovered-digest 必须来自恢复结束时真正存在的明文字节。备份清单中记录的期望摘要可以用来比较，却不能直接复制到恢复声明中。复制会把“应该得到什么”伪装成“实际得到了什么”。

环境测量同样必须保留原生算法和原生长度。草案特别指出，与其相邻的参考实现把 AWS Nitro PCR0 和 AMD SEV-SNP 的 48 字节 SHA-384 测量截短为 32 字节。即使字段仍然长得像摘要，也已经无法与使用完整值的策略引擎做逐字节比较。

运行代码优先，不是代码输出什么就相信什么，而是让记录能够回到实际执行产生的字节、算法与比较规则。模式名称不能替代物理测量。

有 Attestation Results，不等于结果新鲜且有利

Attestation Results 可以采用三种方式。引用模式只在声明中保存摘要，减少公开内容，但未来验证依赖原始字节持续可取。嵌入模式把结果带在声明里，增强自包含性，却可能泄露硬件、区域和工作负载信息。单独登记模式让证明结果拥有自己的 Receipt 与日志位置，也增加了另一个对象和服务依赖。

新鲜度也不是一个模糊标签。草案列出 nonce、epoch ID、timestamp 和 none。none 表示底层 Evidence 没有绑定挑战，可以重放。它是诚实披露，不是格式错误，但消费者不能把它显示成“实时证明”。

同样，签名真实的 Attestation Results 也可能给出不利结论。对象存在、签名有效、证据新鲜、评估有利，是四件事。

“能启动”只是最弱的一类等价

equivalence 是可选字段；缺失就等于 none。byte-identical 需要恢复摘要与封存时记录的明文摘要完全一致，并由 Issuer 实际完成比较。operational 只表示通过了一个明确定义的检查，例如加载、启动或健康探针，而且必须引用检查定义与结果。

草案把 operational 明确视为弱断言。数据库能启动，不代表所有记录都在。模型能加载，不代表输出行为相同。应用能回答探针，不代表业务不变量已经恢复。

草案刻意不定义“语义等价”或“行为等价”的代码值，因为一条烟雾测试不足以支撑这种结论。Receipt 与忠实性属于两个独立轴：收据可以完全有效，而等价状态仍是 none。

Issuer 的前后关系，不是日志的全局次序

连续的恢复声明可以用 prev-event 连接，形成同一 subject 下的 Continuity Chain。它表达的是 Issuer 在签署当前声明时承认的上一项恢复。追加式日志则表达所有登记记录的全局先后。

两者之间出现缺口时，验证者必须报告，而不能自动修复。缺口可能意味着 Issuer 不知道中间事件，也可能意味着它选择不承认。prev-entry-id 与 leaf index 是定位线索；真正有密码学意义的是上一份 Signed Statement 的摘要。

如果链跨越多个 Transparency Service，每个服务只能证明自己的顺序。跨服务不存在天然可组合的全局次序。长期审计还需要 consistency Receipt 把新旧树根连接起来；仅证明记录属于某个孤立树根，无法排除日志昨天被重建。

隐私保护会改变谁还能验证

把 claims 附在声明中，透明服务可以对内容执行登记策略，但稳定 subject、恢复频率、区域、服务关系和硬件标识可能进入永久日志。把 payload 分离出来可以减少公开暴露，却也意味着服务无法检查它没有收到的内容，Relying Party 还必须通过旁路取得原文。

用 HMAC 生成假名 subject 可以降低公众关联能力，却会打断跨机构拼接，把 Issuer 密钥变成长寿关联秘密，并在密钥轮换时切断链。隐私不是写完日志后再加的遮罩；它预先决定未来能验证哪些连续性。

参考代码与规范仍处在不同层

草案主动说明，相邻的参考实现并未实现本文件。它不生成 RFC 9942 COSE Receipts，使用另一套日志链结构，证明验证不完整，也没有 nonce 绑定。其重建模块是一个确定性的三阶字节 Markov chain，并不能证明语义恢复。

这段坦白不是对 SCITT 的失败判决。它只是提醒读者：文档提出的结构、代码实际做的事、生产部署的效果，三者必须分别记账。仓库存在不等于机制已经落地。

来源与限制

这些来源记录了草案、现有收据与远程证明架构，以及相邻实现自述的差距；它们没有证明生产部署、真实恢复、攻击、互操作性、采纳状态或语义忠实。下文的放行档案是 Daniel Kade 的运营分析，不是 revision 01 已经规定的标准要求。