5. 安全考虑 (Security Considerations)

请查阅 [RFC3161] 中的 Security Considerations 一节. 这些考虑同样适用于本文档.

还请查阅 [RFC9052] 中的 Security Considerations 一节. 这些考虑同样适用于本文档, 尤其是关于实现需要保护 private key material 的要求. 此外, 基于本文档定义的 COSE header parameters 的解决方案必须能够及时报告已泄露的密钥.

以下场景假设攻击者可以操纵 COSE signer 及其依赖方的时钟, 但不能操纵 TSA. 还假设 TSA 是受信任的第三方, 因此攻击者不能冒充 TSA 并创建有效的 timestamp tokens. 在这种环境下, 对 COSE signer 时钟的任何篡改都不会产生影响, 因为一旦从 TSA 获得时间戳, 它就成为唯一可靠的时间来源. 但是, 在 CTT mode 和 TTC mode 中, 如果攻击者能够调整依赖方的时钟而导致 CMS validation 失败, 则可能发生 denial of service. 这可能会中断 timestamp validation.

在 CTT mode 中, 攻击者可以通过移除或替换 timestamp 来操纵 unprotected header. 为避免这种情况, COSE Signed Message 在传输过程中和静态存储时都应该受到完整性保护.

在 TTC mode 中, TSA 会获得 payload 的 opaque identifier (cryptographic hash value). 虽然这意味着 payload 的内容不会被直接泄露, 但为了防止与已知 payloads 比较, 或防止随着时间推移暴露相同 payloads 的使用情况, payload 需要被 armored, 例如使用与 header parameter 接收方共享但不与 TSA 共享的 nonce. 此类机制超出本文档范围.

在实现基于本文档定义的 COSE header parameters 的解决方案时, 必须考虑 TSA 时钟的 resolution, accuracy 和 precision, 以及往返 TSA 所引入的预期 latency.

5.1. 避免语义混淆 (Avoiding Semantic Confusion)

CTT mode 和 TTC mode 具有不同的语义含义. 实现必须确保 CTT 和 TTC headers 的内容按照其特定语义解释. 特别是, 与签名和组装机制相对称, 每种模式都有自己独立的验证算法.

实现者必须清楚区分 TSA timestamps [RFC3161] 所证明的内容: TTC 证明 payload data 在较早时间点已存在, 而 CTT 明确提供 cryptographic signature 已存在的证据. 未能清楚区分这些 timestamp 语义可能导致漏洞, 例如基于较旧的仅 payload timestamp 错误接受在密钥撤销之后创建的签名. Validators 不得将 protected-header payload timestamps 解释为签名创建时间的证明, 并且应该仅依赖明确覆盖 signature data 的 TSA timestamps [RFC3161] 来确定签名有效性时间.