1. 简介 (Introduction)

RFC 3161 [RFC3161] 提供了一种为消息摘要添加时间戳的方法, 用以证明该摘要是在给定时间之前创建的.

本文档定义两个新的 CBOR Object Signing and Encryption (COSE) [RFC9052] header parameters. 这些参数携带 TimeStampToken (TST) 输出 [RFC3161], 从而允许用于签名的 COSE structures (COSE_Sign 和 COSE_Sign1) 使用现有且已广泛部署的信任基础设施.

1.1. 用例 (Use Cases)

本节讨论两个用例, 每个用例分别代表第 2 节定义的两种使用模式之一. 由于这两种场景的安全特性不同, 为给定应用选择适当模式时必须谨慎. 关于实现安全性的讨论见第 5.1 节.

主要用例是 "long-term signatures", 即即使签名证书已经过期后仍可验证的签名. 这可以处理需要防止签名者事后否认, 或需要验证使用(非常)短期证书所生成签名的情况. 为实现这一点, 文档签名者从受信任的 Time Stamping Authority (TSA) [RFC3161] 为文档签名获取一个新的 TST, 并将其与文档连接起来. 之后, 当依赖方验证已签名文档及其关联 TST 时, 可以确信该文档至少是在 TSA 指定的时间签署的, 并且签名证书在生成签名时有效.

这个主要使用场景促成了第 2.1 节描述的 "COSE, Then Timestamp" 模式.

第二个用例是新的. 它是通过将已签名文档注册到透明性服务来对其进行公证. 这是确保已签发文档具备可问责性和可审计性的常见做法, 在此上下文中这些文档通常称为 "statements". 常见做法还包括只将 statement 的已签名部分 ("signed statement" 部分) 注册到透明性服务, 以降低后续一致性检查的复杂度, 并避免检索或重建未签名部分的需求. 一旦文档的已签名部分被注册到透明性服务的 append-only log 中, 日志条目就不能更改. 为避免在注册过程中丢失 TST, TST 必须包含在 signed statement 中. 为实现这一点, 发行者从 TSA 获取 TST, 将其包含在 statement 的待签名部分中, 使生成的 signed statement 包含该 TST, 然后注册已签名部分 (使其成为 "transparent statement"). 之后, 使用包含 TST 的 transparent statement 的依赖方可以确信该 statement 至少是在 TSA 指定的时间由发行者签署的. 如果发行者的签名密钥已过期(或已泄露), 可以通过确保在发行者声明并注册到透明性服务的时间之前没有公开任何撤销信息, 来确认 statement 的真实性.

这个新的使用场景促成了第 2.2 节定义的 "Timestamp, Then COSE" 模式.

1.2. 要求记法 (Requirements Notation)

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在以这里所示的全大写形式出现时, 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述解释.