Appendix A. 算法外部数据认证指南

在 COSE 开发期间, 将算法标识符放在受保护属性中的要求从 MUST 放宽为 SHOULD. 支持这一立场的基本理由有两个. 第一, 如果在 CoAP 环境中最常见的消息里省略算法标识符, 生成的消息会更小. 第二, 如果没有在算法标识符可能放置的不同位置之间正确完成完整检查 (消息本身, 应用声明, 发送者拥有的 key 结构, 以及 recipient 拥有的 key 结构), 就可能产生潜在 bug.

本附录说明如何做出这种改变, 以及应用为了使用此选项需要指定的细节. 这里指定两组不同细节: 省略算法标识符所需的细节, 以及使用不包含自身属性的 countersignature 属性变体所需的细节.

这里给出三组建议. 第一组建议适用于为 COSE 对象的单层标识隐式算法. 第二组建议适用于为 COSE 对象的多层标识多个隐式算法. 第三组建议适用于为多个 COSE 对象构造使用隐式算法.

这里有意不使用 BCP 14 ([RFC2119] and [RFC8174]) 中的关键词. 本规范可以提供建议, 但无法强制执行它们.

这组建议适用于如下情形: 应用随密钥信息一起分发固定算法, 供单个 COSE 对象使用. 这通常适用于最小的 COSE 对象, 具体是 COSE_Sign1, COSE_Mac0, and COSE_Encrypt0, 但也可以适用于其他结构.

应考虑以下事项:

应用需要列出要使用隐式算法的 COSE 结构集合. 应用需要要求, 在这些结构之一中接收到显式算法标识符将导致消息被拒绝. 提出此要求是为了永远不会出现关于应使用哪个算法 (隐式算法还是显式算法) 的任何歧义. 即使传输的算法标识符是受保护属性, 这一点也适用. 即使传输的算法与隐式算法相同, 这一点也适用.
应用需要定义在省略算法标识符时应被视为 context 一部分的信息集合. 至少, 这将包括密钥标识符 (如需要), 密钥, 算法, 以及使用它的 COSE 结构. 应用应将单个密钥的使用限制为单个算法. 如 [RFC9053] 中某些算法所指出, 在不同但相关的算法中使用同一密钥, 可能导致有关密钥的信息泄露, 有关数据的泄露, 或执行伪造的能力.
在许多情况下, 使算法标识符成为隐式的应用也会出于同样原因希望使 context 标识符成为隐式的. 也就是说, 省略 context 标识符会减小消息大小 (可能显著减小, 取决于标识符长度). 这样做的应用需要描述应省略 context 标识符的情形, 以及在这些情形中如何推断 context 标识符. (通常不会认为对所有密钥进行穷举搜索是可接受的.) 一种实现方式是将 context 绑定到事务标识符. 两者都会在原始消息中发送, 但此后只需要发送事务标识符, 因为 context 已绑定到该事务标识符. 另一种方式是将 context 与网络地址关联. 可以假定来自单一网络地址的所有消息都与特定 context 关联. (在这种情况下, 地址通常会作为 context 的一部分分发.)
应用不能依赖 key identifier 的唯一性, 除非它们付出大量努力来确保 key identifier 以能够提供此保证的方式计算. 即使应用这样做, 如果应用在不同 context 中运行 (即使用不同的 context 提供方), 或者系统将不同应用的安全 context 合并到单个存储中, 唯一性也可能被破坏.
应用应继续保护算法标识符的做法. 由于这不是通过将其放入 protected attributes 字段来完成的, 应用应定义一个包含该值的应用特定外部数据结构. 此 external data 字段可按此方式用于内容加密, MAC, 和签名算法. 对于使用 KDF 派生密钥值的算法, 它可以在 SuppPrivInfo 字段中使用. 应用可能还希望保护 context 结构中其他信息. 应注意, 密钥或 Base IV 等由于被用于密码计算而受到保护的字段, 不需要包含在 external data 字段中.

第二种情况是为多层 COSE 对象指定多个隐式算法标识符. 一个工作示例是应用指定的加密 context, 其中包含内容加密算法, key wrap 算法, key identifier, 和共享 secret. 发送者省略内容层和 recipient 层的算法标识符, 只留下 key identifier. 接收者随后使用 key identifier 获取隐式算法标识符.

需要额外考虑以下事项:

希望支持这一点的应用需要定义一种结构, 允许并清晰标识给定密钥要搭配使用的 COSE 结构, 以及辅助层要使用的结构和算法. 辅助层的密钥照常从 recipient 层计算.

第三种情况是具有多个隐式算法标识符, 但目标可能是不相关的层或不同 COSE 对象. 有许多不同场景可能适用. 其中一些场景是:

两个 context 作为一对分发. 每个 context 都用于 COSE_Encrypt 消息. 每个 context 将包含不同的 secret key 和 IV, 甚至可能包含不同算法. 一个 context 用于从 party A 向 party B 发送消息, 第二个 context 用于从 party B 向 party A 发送消息. 这意味着不会发生反射攻击, 因为每一方使用不同 secret key 发送其消息; 被反射回来的消息将无法解密.
两个 context 作为一对分发. 第一个 context 用于消息加密, 第二个 context 用于在消息上放置 countersignature. 其意图是第二个 context 可以独立于第一个 context 分发给其他实体. 这允许这些实体验证消息来自某个个体, 而不能解密消息并查看内容.
两个 context 作为一对分发. 第一个 context 包含用于处理 MACed 消息的密钥, 第二个 context 包含用于处理加密消息的不同密钥. 这允许向参与者统一分发不同类型消息的密钥, 这些消息具有不同密钥, 但这些密钥可以以协调方式使用.

对于这些情况, 需要额外考虑以下事项:

应用需要确保多个 context 保持关联. 如果其中一个 context 因任何原因失效, 与其关联的所有 context 也应失效.