1.1. 需求 术语

本文档中的关键词 “MUST”、“MUST NOT”、 “REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL”，只有在如这里所示全部以大写形式出现时， 才应按 BCP 14 [RFC2119] [RFC8174] 中所述进行解释。¶

1.3. 相对于 JOSE 的设计变更

• 已定义一个单一的总体消息结构，使得 加密、签名和 MACed 消息可以易于识别，同时仍具有 一致的视图。¶
• 签名消息区分了与内容相关的 受保护和不受保护头部参数，以及与签名相关的那些参数。¶
• MACed 消息与签名消息分离。¶
• MACed 消息能够使用与封装消息相同的一组 接收方算法来获得 MAC 认证密钥。¶
• 使用二进制编码，而不是 base64url 编码，来编码二进制数据。¶
• 加密算法的认证标签 已与密文合并。¶
• 加密算法集合在某些方向上扩展， 在另一些方向上裁剪。¶

1.4. 用于 CBOR 数据结构的 CDDL 语法

最初编写 COSE 时，简明数据定义 语言（CDDL）[RFC8610] 尚未作为 RFC 发布，因此不能用作数据描述 语言来规范性地描述 COSE 所采用的 CBOR 数据结构。 因此，这里定义的 CBOR 数据对象以散文形式描述。 下文所述的 CDDL 子集还提供了 COSE 数据对象的额外（非规范性）描述。¶

本文档的开发方式是先处理语法，然后开发与之配套的散文描述。 这种做法的一个产物是，散文使用了 简明数据定义语言（CDDL）[RFC8610] 定义的原始类型字符串。 本规范中使用以下原始类型：¶

any:

一种非特定值，允许在此处放置所有 CBOR 值。¶

bool:

布尔值（true：主类型 7，值 21；false：主类型 7，值 20）。¶

bstr:

字节字符串（主类型 2）。¶

int:

无符号整数或负整数。¶

nil:

空值（主类型 7，值 22）。¶

nint:

负整数（主类型 1）。¶

tstr:

UTF-8 文本字符串（主类型 3）。¶

uint:

无符号整数（主类型 0）。¶

本文档中出现了三种 CDDL 语法作为简写。它们是：¶

FOO / BAR:

表示这里可以出现 FOO 或 BAR。¶

[+ FOO]:

表示类型 FOO 在数组中出现一次或 多次。¶

* FOO:

表示类型 FOO 出现零次或 多次。¶

本文档还使用了 CDDL 定义的两种约束。它们是：¶

type1 .cbor type2:

表示 type1 的内容 （通常为 bstr）包含一个 type2 的值。¶

type1 .size integer:

表示 type1 的内容长度为 integer 个字节。¶

除散文描述外，还以前述 CDDL 子集给出了 CBOR 数据结构的语法。 CDDL 语法是资料性的；散文描述是规范性的。¶

可通过下面的 XPath 表达式从本文档的 XML 版本中 提取收集到的 CDDL。（取决于所使用的 XPath 求值器，可能 需要将 > 作为实体处理。）¶

//sourcecode[@type='cddl']/text()

CDDL 期望初始非终结符符号是 文件中的第一个符号。因此，第一个 CDDL 片段在此给出。¶

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; This is defined to make the tool quieter:
Internal_Types = Sig_structure / Enc_structure / MAC_structure

非终结符 Internal_Types 是为处理在编写本文档期间 使用的自动化验证工具而定义的。它引用那些 用于安全计算但不为传输而发出的非终结符。¶

1.5. CBOR 相关 术语

在 JSON 中，映射被称为对象，并且只有一种映射键： 文本字符串。在 COSE 中，我们使用文本字符串、负整数和无符号整数作为映射键。 整数用于实现编码紧凑性和易于比较。包含文本字符串也允许使用 额外范围的短编码值。由于 “key” 这个词主要用于它的另一种含义，即 加密密钥，因此我们使用术语 “label” 来表示其作为映射键的这种用法。¶

在本规范定义的 CBOR 映射中，如果存在既不是文本字符串 也不是整数的标签，则为错误。 应用可以使处理失败，或者通过忽略不正确标签来处理消息； 但是，它们MUST NOT 创建带有不正确标签的消息。¶

一个 CDDL 语法片段定义了非终结符 “label”， 如上一段所述，以及 “values”，它允许使用任何值。¶

label = int / tstr
values = any

3.1. 通用 COSE 头部 参数

本节定义一组通用头部参数。这些 头部参数的摘要可见于 表 3。应查阅该表 以确定标签值和值的类型。¶

本节定义的头部参数集合如下：¶

alg:

此头部参数用于指示 安全处理所使用的算法。在存在这样能力的地方，此头部参数MUST 被认证。AEAD 算法或构造（例如 COSE_Sign 和 COSE_Mac0） 提供这种支持。这种认证可以通过将该头部参数放入 protected-header-parameters 桶来完成，也可以作为外部提供数据（第 4.3 节）的一部分来完成。该值取自 “COSE Algorithms” 注册表（见 [COSE.Algorithms]）。¶

crit:

此头部参数用于指示 处理消息的应用需要理解哪些 受保护头部参数。本文档中定义的头部 参数不需要包含在内，因为所有 实现都应理解它们。此外，为了与 遵循 [RFC8152] 并假设所有实现都会理解它的 发送方保持兼容，新实现必须理解该文档定义的 “counter signature” 头部参数（标签 7）。当存在时，“crit” 头部 参数MUST 放在 protected-header-parameters 桶中。该数组 MUST 至少有一个值。¶

并非所有头部参数标签都需要包含在 “crit” 头部参数中。 决定哪些头部参数放入数组的规则是：¶

• 0 到 7 范围内的整数标签SHOULD 被省略。¶
• -1 到 -128 范围内的整数标签可以省略。 算法可以在此范围内分配标签，其中 处理标签内容的能力被认为是实现该算法的核心。 算法可以在此范围之外分配标签，并在 处理该标签内容的能力不被认为是算法核心功能、 但确实需要理解才能正确处理此实例时， 将它们包含在 “crit” 头部参数中。 -129 到 -65536 范围内的整数标签 SHOULD 被包含，因为这些会是 较不常见、可能并非普遍支持的头部参数。¶
• 应用所需的头部参数标签 MAY 被省略。应用应有声明说明该 标签是否可以省略。¶

“crit” 指示的头部参数可以由 安全库代码处理，也可以由使用安全库的应用处理；唯一要求 是该头部参数被处理。如果 “crit” 值列表包含一个标签，而 对应头部参数不在 protected-header-parameters 桶中，这就是 处理该消息时的致命错误。¶

content type:

此头部参数用于指示 “payload” 或 “ciphertext” 字段中数据的内容类型。整数来自 “CoAP Content-Formats” IANA 注册表 [COAP.Formats]。文本值遵循 “<type-name>/<subtype-name>” 的语法，其中 <type-name> 和 <subtype-name> 定义于 [RFC6838] 第 4.2 节。不允许前导和尾随空白。 文本内容类型值及其参数和子参数可使用 IANA “Media Types” 注册表定位。如果内容结构可能存在歧义，应用SHOULD 提供此 头部参数。¶

kid:

此头部参数标识一段 可用作输入以查找所需加密密钥的数据。该 头部参数的值可以与 COSE_Key 结构中的 “kid” 成员匹配。其他 密钥分发方法可以定义一个等价字段进行匹配。应用MUST NOT 假设 “kid” 值是唯一的。可能存在多个 具有相同 “kid” 值的密钥，因此可能需要检查与该 “kid” 关联的所有密钥。 “kid” 值的内部结构未定义，应用不能依赖它。 密钥标识符值是关于使用哪个密钥的提示。这不是 安全关键字段。因此，它可以放在 unprotected-header-parameters 桶中。¶

IV:

此头部参数保存 初始化向量（IV）值。对于某些对称加密算法，这也可以 称为 nonce。IV 可以放在不受保护桶中，因为对于 AE 和 AEAD 算法，修改 IV 会导致解密失败。¶

Partial IV:

此头部参数保存 IV 值的一部分。 使用 COSE_Encrypt0 结构时，IV 的一部分可以是与密钥 关联的上下文的一部分（Context IV），而一部分可以随每条消息 改变（Partial IV）。 此字段用于承载一个值，使 IV 对每条消息发生改变。 Partial IV 可以放在不受保护桶中，因为修改该值会 导致解密产生容易检测为乱码的明文。 “Initialization Vector” 和 “Partial Initialization Vector” 头部参数MUST NOT 同时出现在同一安全层中。¶

消息 IV 通过以下步骤生成：¶

1. 将 Partial IV 左侧补零至 IV 的长度 （由算法确定）。¶
2. 将补齐后的 Partial IV 与 Context IV 进行 XOR。¶

下面给出了表示本节所定义头部参数集合的 CDDL 片段。每个头部参数都标记为可选，因为它们不 需要出现在每个映射中；特定映射中所需的头部参数在上文讨论。¶

Generic_Headers = (
    ? 1 => int / tstr,  ; algorithm identifier
    ? 2 => [+label],    ; criticality
    ? 3 => tstr / int,  ; content type
    ? 4 => bstr,        ; key identifier
    ? ( 5 => bstr //    ; IV
        6 => bstr )     ; Partial IV
)

4.1. 使用一个或 多个签名者进行签名

COSE_Sign 结构允许对 消息负载应用一个或多个签名。与内容相关的头部参数以及与 签名相关的头部参数会随签名本身一起携带。这些头部参数可以由 签名认证，也可以只是存在。关于 内容的头部参数示例是内容类型头部参数。关于 签名的头部参数示例则是用于创建签名的算法和密钥。¶

[RFC5652] 指出：¶

当存在多个签名时，通常会把与给定签名者关联的一个签名验证成功 视为该签名者的签名成功。但是，也有一些应用环境 需要其他规则。采用并非“每个签名者一个有效签名”规则的应用 必须规定这些规则。此外，在简单匹配签名者标识符 不足以确定这些签名是否由同一签名者生成时，应用规范必须 描述如何确定哪些签名由同一签名者生成。支持不同接收方社群 是签名者选择包含多个签名的主要原因。¶

例如，COSE_Sign 结构可能包含使用 Edwards 曲线 数字签名算法（EdDSA）[RFC8032] 和椭圆曲线数字签名算法（ECDSA）[DSS] 生成的签名。这允许接收方验证 与其中一种算法关联的签名。关于多个签名评估的更多详细信息可见 [RFC5752]。¶

签名结构可以编码为带标签或无标签，具体取决于 其使用上下文。带标签的 COSE_Sign 结构由 CBOR 标签 98 标识。表示这一点的 CDDL 片段为：¶

COSE_Sign_Tagged = #6.98(COSE_Sign)

COSE 签名消息分为两个部分定义。携带 主体和消息相关信息的 CBOR 对象称为 COSE_Sign 结构。携带 签名以及签名相关信息的 CBOR 对象称为 COSE_Signature 结构。COSE 签名消息示例可见 附录 C.1。¶

COSE_Sign 结构是一个 CBOR 数组。数组字段按顺序 为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

payload:

此字段包含要签名的序列化内容。 如果消息中不存在负载，则要求应用单独提供 负载。 负载被包裹在 bstr 中，以确保其传输时不发生改变。 如果负载被单独传输（“分离内容”），则会在此位置放置一个 nil CBOR 对象， 并由应用负责确保其传输时不发生改变。¶

注：使用带消息恢复算法的签名时（第 8.1 节），可恢复的最大字节数是 原始负载的长度。 编码负载的大小会按将要恢复的字节数减少。 如果原始负载的所有字节都被消耗，则传输的负载 编码为零长度字节字符串，而不是作为不存在处理。¶

signatures:

此字段是一个签名数组。每个 签名都表示为一个 COSE_Signature 结构。¶

表示上述 COSE_Sign 文本的 CDDL 片段如下。¶

COSE_Sign = [
    Headers,
    payload : bstr / nil,
    signatures : [+ COSE_Signature]
]

COSE_Signature 结构是一个 CBOR 数组。数组字段 按顺序为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

signature:

此字段包含计算得到的签名 值。该字段类型为 bstr。如果签名值不是 8 位的倍数，算法MUST 规定 填充方式。¶

表示上述 COSE_Signature 文本的 CDDL 片段 如下。¶

COSE_Signature =  [
    Headers,
    signature : bstr
]

4.3. 外部提供的 数据

COSE 提供的一项特性是，应用能够提供需要被认证但 不作为 COSE 对象一部分携带的额外数据。 支持这一点的主要原因可通过查看 CoAP 消息结构 [RFC7252] 看出，其中存在 在负载之前携带选项的机制。 可放置在此位置的数据示例包括 CoAP 代码或 CoAP 选项。 如果数据位于 CoAP 消息的头部中，则代理可使用这些数据来帮助 执行代理操作。 例如，代理可以使用 Accept 选项来确定 代理缓存中是否存在合适的值。 发送方可以使用 additional-data 功能来检测 代理或攻击者对 Accept 值集合所做的任何更改。通过 将该字段包含在外部提供的数据中，任何后续 修改都会导致服务器处理消息时 失败。¶

本文档描述了使用外部提供的认证数据字节数组的过程； 构造该字节数组的方法是应用的函数。 使用此特性的应用需要定义如何构造外部提供的认证数据。 这种构造需要考虑以下问题：¶

• 如果包含多个项目，应用需要确保不同输入不会 生成同一字节字符串。 可能出现问题场景的一个示例是连接文本字符串 “AB” 和 “CDE”，或连接文本字符串 “ABC” 和 “DE”。 通常通过使字段具有固定宽度和/或把字段长度编码为 输出的一部分来解决这一问题。 以 CoAP [RFC7252] 中的选项为 例，这些字段使用 TLV 结构，因此它们可以连接而不会出现 问题。¶
• 如果包含多个项目，则需要 定义这些项目的顺序。以 CoAP 选项为例，应用可以声明 字段应按选项编号排序。¶
• 应用需要确保双方得到的字节字符串相同。 如果保留相同的相对编号，使用 CoAP 选项可能会产生问题。 中间节点可能插入或移除某个选项，从而改变相对编号 的方式。 应用需要规定必须重新编码相对编号，使其仅相对于 外部数据中的选项。¶

4.4. 签名与 验证过程

为了创建签名，需要一个定义良好的字节字符串。 Sig_structure 用于创建规范形式。 此签名与验证过程接收主体信息（COSE_Sign 或 COSE_Sign1）、 签名者信息（COSE_Signature）以及应用数据（外部来源）。 Sig_structure 是一个 CBOR 数组。 Sig_structure 的字段按顺序为：¶

1. 一个用于标识签名上下文的上下文文本字符串。上下文文本字符串 是：¶

   • “Signature” 用于使用 COSE_Signature 结构的签名。¶
   • “Signature1” 用于使用 COSE_Sign1 结构的签名。¶
2. 主体结构中的受保护属性，编码为 bstr 类型。如果没有受保护属性，则使用零长度字节字符串。¶
3. 签名者结构中的受保护属性，编码为 bstr 类型。如果没有受保护属性，则使用零长度字节字符串。对于 COSE_Sign1 签名结构，将省略此字段。¶
4. 来自应用的外部提供数据，编码为 bstr 类型。如果未提供此字段，则默认为零长度字节字符串。（有关构造 此字段的应用指南，见 第 4.3 节。）¶
5. 要签名的负载，编码为 bstr 类型。这里使用完整负载， 与其如何传输无关。¶

描述上述文本的 CDDL 片段为：¶

Sig_structure = [
    context : "Signature" / "Signature1",
    body_protected : empty_or_serialized_map,
    ? sign_protected : empty_or_serialized_map,
    external_aad : bstr,
    payload : bstr
]

如何计算签名：¶

1. 创建 Sig_structure，并用适当字段填充它。¶
2. 通过将 Sig_structure 按 第 9 节所述编码方式编码为字节字符串，创建 ToBeSigned 值。¶
3. 调用签名创建算法，传入 K（用于签名的密钥）、 alg（用于签名的算法）和 ToBeSigned（要签名的值）。¶
4. 将所得签名值放置在正确位置。 这是 COSE_Signature 或 COSE_Sign1 结构中的 “signature” 字段。¶

验证签名的步骤为：¶

1. 创建 Sig_structure，并用适当字段填充它。¶
2. 通过将 Sig_structure 按 第 9 节所述编码方式编码为字节字符串，创建 ToBeSigned 值。¶
3. 调用签名验证算法，传入 K（用于验证的密钥）、 alg（用于签名的算法）、ToBeSigned（要签名的值）以及 sig （要验证的签名）。¶

除执行签名验证外，应用还会执行适当检查，以确保密钥与签名身份 正确配对，并确保签名身份在执行操作之前已获得授权。¶

5.1. 封装的 COSE 结构

封装结构允许消息有一个或多个接收方。消息中 可携带关于内容的头部参数以及关于接收方 信息的头部参数。与内容关联的受保护头部参数由 内容加密算法认证。与接收方关联的受保护头部参数 （当算法支持时）由接收方算法认证。关于内容的 头部参数示例包括内容类型和内容加密算法。关于接收方的 头部参数示例包括接收方的密钥标识符和接收方的加密算法。¶

加密明文和加密密钥使用相同技术以及几乎相同的结构。 这不同于“加密消息语法（CMS）”[RFC5652] 和 “JSON Web Encryption（JWE）” [RFC7516] 所采用的方法，后者为 内容层和接收方层使用不同结构。 定义了两个结构：COSE_Encrypt 用于保存加密内容，COSE_recipient 用于 保存接收方的加密密钥。 封装消息示例可见 附录 C.3。¶

COSE_Encrypt 结构可以根据其使用上下文编码为带标签或无标签。 带标签的 COSE_Encrypt 结构由 CBOR 标签 96 标识。表示这一点的 CDDL 片段为：¶

COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)

COSE_Encrypt 结构是一个 CBOR 数组。数组字段按顺序 为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

ciphertext:

此字段包含密文，编码 为 bstr。如果密文将独立于有关加密过程的控制信息 传输（即分离内容），则该字段编码为 nil 值。¶

recipients:

此字段包含一个接收方 信息结构数组。接收方信息结构的类型是 COSE_recipient。¶

与上述文本对应的 CDDL 片段为：¶

COSE_Encrypt = [
    Headers,
    ciphertext : bstr / nil,
    recipients : [+COSE_recipient]
]

COSE_recipient 结构是一个 CBOR 数组。数组字段 按顺序为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

ciphertext:

此字段包含加密密钥， 编码为 bstr。所有已编码密钥都是对称密钥；密钥的二进制值就是 内容。如果没有加密密钥，则此字段编码为 nil 值。¶

recipients:

此字段包含一个接收方 信息结构数组。接收方信息结构的类型是 COSE_recipient （其示例可见 附录 B）。如果 没有接收方信息结构，则此元素不存在。¶

与上述 COSE_recipient 文本对应的 CDDL 片段为：¶

COSE_recipient = [
    Headers,
    ciphertext : bstr / nil,
    ? recipients : [+COSE_recipient]
]

5.2. 单一接收方 加密

COSE_Encrypt0 加密结构无法指定 消息接收方。该结构假定对象的接收方已经 知道为解密消息要使用的密钥的身份。如果需要向 接收方标识密钥，则应使用封装结构。¶

加密消息示例可见 附录 C.4。¶

COSE_Encrypt0 结构可以根据其使用上下文编码为带标签或无标签。 带标签的 COSE_Encrypt0 结构由 CBOR 标签 16 标识。表示这一点的 CDDL 片段为：¶

COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)

COSE_Encrypt0 结构是一个 CBOR 数组。数组字段 按顺序为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

ciphertext:

如 第 5.1 节所述。¶

与上述文本对应的 COSE_Encrypt0 CDDL 片段为：¶

COSE_Encrypt0 = [
    Headers,
    ciphertext : bstr / nil,
]

5.3. 如何为 AEAD 算法 加密和解密

AEAD 算法的加密算法相当简单。第一步 是为认证数据结构创建一致的字节字符串。为此，我们 使用 Enc_structure。Enc_structure 是一个 CBOR 数组。Enc_structure 的字段 按顺序为：¶

1. 一个用于标识认证 数据结构上下文的上下文文本字符串。上下文文本字符串为：¶

   • “Encrypt0” 用于 COSE_Encrypt0 数据结构的内容加密。¶
   • “Encrypt” 用于 COSE_Encrypt 数据结构的第一层（即用于内容加密）。¶
   • “Enc_Recipient” 用于 要放置在 COSE_Encrypt 数据结构中的接收方编码。¶
   • “Mac_Recipient” 用于 要放置在 MACed 消息结构中的接收方编码。¶
   • “Rec_Recipient” 用于 要放置在接收方结构中的接收方编码。¶
2. 主体结构中的受保护属性，编码为 bstr 类型。如果没有受保护属性，则使用零长度字节字符串。¶
3. 来自应用的外部提供数据，编码为 bstr 类型。如果未提供此字段，则默认为零长度字节字符串。（有关构造 此字段的应用指南，见 第 4.3 节。）¶

描述上述文本的 CDDL 片段为：¶

Enc_structure = [
    context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
        "Mac_Recipient" / "Rec_Recipient",
    protected : empty_or_serialized_map,
    external_aad : bstr
]

如何加密消息：¶

1. 创建 Enc_structure，并用适当字段填充它。¶
2. 将 Enc_structure 编码为字节字符串（附加认证 数据（AAD）），使用 第 9 节中描述的编码。¶

3. 确定加密密钥（K）。此步骤取决于 所使用的接收方算法类别。对于：¶

   无接收方：

   要使用的密钥由 当前层的算法和密钥确定。示例包括密钥包装密钥（第 8.5.2 节）和预共享秘密。¶

   直接加密和直接密钥协商：

   密钥由接收方结构中的密钥和算法确定。 要使用的加密算法和密钥大小是 接收方所用 KDF 的输入。 （对于 direct，可以将 KDF 视为恒等操作。） 这些算法的示例可见 [RFC9053] 的第 6.1 节和第 6.3 节。¶

   其他：

   密钥随机生成。¶

4. 使用 K（加密密钥）、P（明文）和 AAD 调用加密算法。将返回的密文放入结构的 “ciphertext” 字段。¶
5. 对于消息中使用非直接算法的接收方， 递归地为该接收方执行加密算法，使用 K（加密密钥）作为 明文。¶

如何解密消息：¶

1. 创建 Enc_structure，并用适当字段填充它。¶
2. 将 Enc_structure 编码为字节字符串（AAD），使用 第 9 节中描述的编码。¶

3. 确定解密密钥。此步骤取决于 所使用的接收方算法类别。对于：¶

   无接收方：

   要使用的密钥由 当前层的算法和密钥确定。示例包括密钥包装密钥（第 8.5.2 节）和预共享秘密。¶

   直接加密和直接密钥协商：

   密钥由接收方结构中的密钥和算法确定。 要使用的加密算法和密钥大小是 接收方所用 KDF 的输入。 （对于 direct，可以将 KDF 视为恒等操作。）¶

   其他：

   密钥通过 解码并解密其中一个接收方结构来确定。¶

4. 使用 K（要使用的解密密钥）、C （密文）和 AAD 调用解密算法。¶

5.4. 如何为 AE 算法 加密和解密

如何加密消息：¶

1. 验证 “protected” 字段是零长度字节字符串。¶
2. 验证没有为此操作提供外部附加认证数据。¶

3. 确定加密密钥。此步骤取决于 所使用的接收方算法类别。对于：¶

   无接收方：

   要使用的密钥由 当前层的算法和密钥确定。示例包括密钥包装密钥（第 8.5.2 节）和预共享秘密。¶

   直接加密和直接密钥协商：

   密钥由 接收方结构中的密钥和算法确定。要使用的加密算法和 密钥大小是接收方所用 KDF 的输入。（对于 direct，可以将 KDF 视为恒等操作。） 这些算法的示例可见 [RFC9053] 的第 6.1 节和第 6.3 节。¶

   其他：

   密钥随机生成。¶

4. 使用 K（要使用的加密密钥）和 P （明文）调用加密算法。将返回的密文放入 结构的 “ciphertext” 字段。¶
5. 对于消息中使用非直接算法的接收方，递归地 为该接收方执行加密算法，使用 K（加密密钥）作为 明文。¶

如何解密消息：¶

1. 验证 “protected” 字段是零长度字节字符串。¶
2. 验证没有为此操作提供外部附加认证数据。¶

3. 确定解密密钥。此步骤取决于 所使用的接收方算法类别。对于：¶

   无接收方：

   要使用的密钥由 当前层的算法和密钥确定。示例包括密钥包装密钥（第 8.5.2 节）和预共享秘密。¶

   直接加密和直接密钥协商：

   密钥由 接收方结构中的密钥和算法确定。要使用的加密算法和 密钥大小是接收方所用 KDF 的输入。（对于 direct，可以将 KDF 视为恒等操作。） 这些算法的示例可见 [RFC9053] 的第 6.1 节和第 6.3 节。¶

   其他：

   密钥通过 解码并解密其中一个接收方结构来确定。¶

4. 使用 K（要使用的解密密钥）和 C （密文）调用解密算法。¶

6.1. 带接收方的 MACed 消息

多接收方 MACed 消息使用两个结构：本节定义的 COSE_Mac 结构用于携带主体，而 COSE_recipient 结构（第 5.1 节）用于保存 MAC 计算所用的密钥。MACed 消息示例可见 附录 C.5。¶

MAC 结构可以根据其使用上下文编码为带标签或无标签。 带标签的 COSE_Mac 结构由 CBOR 标签 97 标识。表示这一点的 CDDL 片段为：¶

COSE_Mac_Tagged = #6.97(COSE_Mac)

COSE_Mac 结构是一个 CBOR 数组。数组字段按顺序 为：¶

protected:

如 第 3 节所述。¶

unprotected:

如 第 3 节所述。¶

payload:

此字段包含要进行 MAC 的序列化内容。 如果消息中不存在负载，则要求应用单独提供 负载。负载被包裹在 bstr 中，以确保其 传输时不发生改变。如果负载被单独传输（即分离 内容），则会在此位置放置一个 nil CBOR 值，并由 应用负责确保其传输时不发生改变。¶

tag:

此字段包含 MAC 值。¶

recipients:

如 第 5.1 节所述。¶

表示上述 COSE_Mac 文本的 CDDL 片段如下。¶

COSE_Mac = [
   Headers,
   payload : bstr / nil,
   tag : bstr,
   recipients : [+COSE_recipient]
]

7.1. COSE 密钥通用 参数

本文档为 COSE Key 对象定义一组通用参数。表 4 提供了本节 定义参数的摘要。也存在为特定密钥类型定义的参数。 密钥类型特定参数可见于 [RFC9053]。¶

kty:

此参数用于标识该 结构的密钥族，从而标识可找到的一组密钥类型特定参数。 本文档中定义的一组值可见于 [COSE.KeyTypes]。此参数MUST 存在于密钥对象中。实现MUST 验证密钥类型适合正在处理的算法。 密钥类型MUST 作为 信任决策过程的一部分包含在内。¶

alg:

此参数用于限制 与该密钥一起使用的算法。如果此参数存在于密钥结构中， 应用MUST 验证此算法与该密钥所用于的算法匹配。 如果算法不匹配，则此密钥对象MUST NOT 用于执行该密码学操作。注意， 同一密钥可以出现在另一个密钥结构中，并指定不同算法或不指定算法； 但是，这被认为是不良安全实践。¶

kid:

此参数用于给出密钥的标识符。 该标识符没有结构，可以是从用户提供的字节字符串到基于密钥公开部分计算的值。 此字段旨在与消息中的 “kid” 参数进行匹配，以缩小需要检查的 密钥集合。 标识符的值不是唯一值，并且可能出现在其他密钥对象中， 即使这些对象用于不同密钥。¶

key_ops:

此参数定义为限制 一个密钥可用于的操作集合。该字段的值是来自 表 5 的值数组。算法定义 允许出现的 key ops 值以及特定操作所需的值。该组 值与 [RFC7517] 和 [W3C.WebCrypto] 中的值匹配。¶

Base IV:

此参数定义为承载 IV 的基础部分。它 设计为与 第 3.1 节 中定义的 Partial IV 头部参数一起使用。 此字段提供将 Base IV 与密钥关联的能力，然后该 Base IV 会按每条消息 通过 Partial IV 进行修改。¶

在应用中使用 Base IV 时需要极其小心。 如果同一 IV 被使用两次，许多加密算法会失去安全性。¶

如果为每个发送方派生不同密钥，则从同一个 Base IV 开始很可能 满足此条件。 如果多个发送方使用同一密钥，则应用需要提供一种方法，在 发送方之间划分 IV 空间。 这可以通过提供不同的基础起点或不同的 起始 Partial IV，并限制重新换密钥前可发送的消息数量来完成。¶

11.1. COSE Header Parameters 注册表

“COSE Header Parameters” 注册表由 [RFC8152] 定义。 IANA 已更新此注册表的引用，使其指向本文档而不是 [RFC8152]。IANA 还更新了所有 引用 [RFC8152] 的条目，除了 “counter signature” 和 “CounterSignature0”，使其引用本文档。“counter signature” 和 “CounterSignature0” 的引用继续引用 [RFC8152]。¶

11.2. COSE Key Common Parameters 注册表

“COSE Key Common Parameters” 注册表 [COSE.KeyParameters] 定义于 [RFC8152]。 IANA 已更新此注册表的引用，使其指向本文档而不是 [RFC8152]。IANA 还更新了 引用 [RFC8152] 的条目，使其引用 本文档。¶

11.6. 专家评审 指令

[RFC8152] 建立的所有 IANA 注册表至少部分定义为专家评审 [RFC8126]。本节给出一些通用 指南，说明专家应关注什么，但他们被指定为专家是有原因的， 因而应给予他们相当大的自由裁量权。¶

专家评审员应考虑以下事项：¶

• 应阻止码点抢占。鼓励评审员 为注册请求获取足够信息，以确保其用途不会 重复现有注册，并且该码点很可能会在部署中使用。标记为私有使用的范围 旨在用于测试目的和封闭环境；其他范围中的码点不应为测试而分配。¶
• 在 Standards Action 范围内注册 码点需要标准轨道或 BCP RFC。Specification Required 范围应存在规范，但在 RFC 可用之前的早期分配被认为是 允许的。如果预期码点会以可互操作方式在封闭环境之外使用， 则先到先得范围也需要规范。如果 未提供规范，则所提供描述需要有足够 信息来识别该码点用途。¶
• 专家在批准码点分配时，应考虑 字段的预期用途。 Standards Action 范围仅可供 标准轨道文档使用这一事实，并不意味着标准轨道文档 不能在该范围之外分配点。应权衡编码值的长度 与该长度还剩多少码点，以及将使用它的设备大小。¶
• 注册算法时，应阻止虚荣注册。 一种做法是要求注册提供关于算法安全分析的额外 文档。另一个应考虑的事项是向 Crypto Forum Research Group（CFRG） 请求对该算法的意见。 预计算法要满足社群的安全要求以及消息结构的要求， 才适合注册。¶

C.1. 签名 消息示例

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ]
    ]
  ]
)

98(
  [
    / protected / h'',
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
      ],
      [
        / protected h'a1013823' / << {
            / alg / 1:-36 / ECDSA 521 /
          } >> ,
        / unprotected / {
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297'
      ]
    ]
  ]
)

98(
  [
    / protected h'a2687265736572766564f40281687265736572766564' /
    << {
        "reserved":false,
        / crit / 2:[
          "reserved"
        ]
      } >>,
    / unprotected / {},
    / payload / 'This is the content.',
    / signatures / [
      [
        / protected h'a10126' / << {
            / alg / 1:-7 / ECDSA 256 /
          } >>,
        / unprotected / {
          / kid / 4:'11'
        },
        / signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
18aba9d1fad1bd9c'
      ]
    ]
  ]
)

C.2. 单一签名者示例

18(
  [
    / protected h'a10126' / << {
        / alg / 1:-7 / ECDSA 256 /
      } >>,
    / unprotected / {
      / kid / 4:'11'
    },
    / payload / 'This is the content.',
    / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36'
  ]
)

C.3. 封装 消息示例

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >>,
    / unprotected / {
      / iv / 5:h'c9cf4df2fe6c632bf7886413'
    },
    / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
    / recipients / [
      [
        / protected h'a1013818' / << {
            / alg / 1:-25 / ECDH-ES + HKDF-256 /
          } >>,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:1,
            / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
            / y / -3:true
          },
          / kid / 4:'meriadoc.brandybuck@buckland.example'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >>,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a76c'
    },
    / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847',
    / recipients / [
      [
        / protected h'a10129' / << {
            / alg / 1:-10
          } >>,
        / unprotected / {
          / salt / -20:'aabbccddeeffgghh',
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'02d1f7e6f26c43d4868d87ce'
    },
    / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
e5f0165eee976b4a5f6c6f09d',
    / recipients / [
      [
        / protected / h'a101381f' / {
            \ alg \ 1:-32 \ ECDH-SS+A128KW \
          } / ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'0101'
        },
        / ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
e1c62'
      ]
    ]
  ]
)

C.4. 加密 消息示例

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / iv / 5:h'89f52f65a1c580933b5261a78c'
    },
    / ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
460ffb569'
  ]
)

16(
  [
    / protected h'a1010a' / << {
        / alg / 1:10 / AES-CCM-16-64-128 /
      } >> ,
    / unprotected / {
      / partial iv / 6:h'61a7'
    },
    / ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca'
  ]
)

C.5. MACed 消息示例

97(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'9e1226ba1f81b848',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-6 / direct /,
          / kid / 4:'our-secret'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41',
    / recipients / [
      [
        / protected h'a101381a' / << {
            / alg / 1:-27 / ECDH-SS + HKDF-256 /
          } >> ,
        / unprotected / {
          / static kid / -3:'peregrin.took@tuckborough.example',
          / kid / 4:'meriadoc.brandybuck@buckland.example',
          / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5'
        },
        / ciphertext / h''
      ]
    ]
  ]
)

97(
  [
    / protected h'a1010e' / << {
        / alg / 1:14 / AES-CBC-MAC-128//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'36f5afaf0bab5d43',
    / recipients / [
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
b6eb0'
      ]
    ]
  ]
)

97(
  [
    / protected h'a10105' / << {
        / alg / 1:5 / HMAC 256//256 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
1e49e9323e',
    / recipients / [
      [
        / protected h'a101381c' / << {
            / alg / 1:-29 / ECDH-ES+A128KW /
          } >> ,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:3,
            / x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
d613574e7dc242f79c3',
            / y / -3:true
          },
          / kid / 4:'bilbo.baggins@hobbiton.example'
        },
        / ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
      ],
      [
        / protected / h'',
        / unprotected / {
          / alg / 1:-5 / A256KW /,
          / kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
        },
        / ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
518e7736549e998370695e6d6a83b4ae507bb'
      ]
    ]
  ]
)

C.6. MAC0 消息示例

17(
  [
    / protected h'a1010f' / << {
        / alg / 1:15 / AES-CBC-MAC-256//64 /
      } >> ,
    / unprotected / {},
    / payload / 'This is the content.',
    / tag / h'726043745027214f'
  ]
)

C.7. COSE 密钥

[
  {
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    1:2,
    2:'meriadoc.brandybuck@buckland.example'
  },
  {
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    1:2,
    2:'11'
  },
  {
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    1:2,
    2:'bilbo.baggins@hobbiton.example'
  },
  {
    -1:1,
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    1:2,
    2:'peregrin.took@tuckborough.example'
  }
]

[
  {
    1:2,
    2:'meriadoc.brandybuck@buckland.example',
    -1:1,
    -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
    -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
    -4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
208cf'
  },
  {
    1:2,
    2:'11',
    -1:1,
    -2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
    -3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
    -4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
7b4d3'
  },
  {
    1:2,
    2:'bilbo.baggins@hobbiton.example',
    -1:3,
    -2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
    -3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
    -4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
eb26d'
  },
  {
    1:4,
    2:'our-secret',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  },
  {
    1:2,
    -1:1,
    2:'peregrin.took@tuckborough.example',
    -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
    -3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
    -4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
df1c3'
  },
  {
    1:4,
    2:'our-secret2',
    -1:h'849b5786457c1491be3a76dcea6c4271'
  },
  {
    1:4,
    2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
    -1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
  }
]