Skip to main content

5. Producing and Consuming JWEs (生成和使用 JWE)

5.1 Message Encryption (消息加密)

消息加密过程如下. 在输入和输出之间没有依赖关系的情况下, 步骤的顺序并不重要.

  1. 确定用于确定 Content Encryption Key 值的算法所采用的 Key Management Mode. (这是记录在结果 JWE 的 "alg" (algorithm, 算法) Header Parameter 中的算法.)

  2. 当采用 Key Wrapping (密钥包装)、Key Encryption (密钥加密) 或 Key Agreement with Key Wrapping (带密钥包装的密钥协商) 时, 生成随机 CEK 值. 有关生成随机值的注意事项, 请参见 RFC 4086 [RFC4086]. CEK 的长度必须 (MUST) 等于内容加密算法所需的长度.

  3. 当采用 Direct Key Agreement (直接密钥协商) 或 Key Agreement with Key Wrapping 时, 使用密钥协商算法计算协商密钥的值. 当采用 Direct Key Agreement 时, 让 CEK 成为协商的密钥. 当采用 Key Agreement with Key Wrapping 时, 协商的密钥将用于包装 CEK.

  4. 当采用 Key Wrapping、Key Encryption 或 Key Agreement with Key Wrapping 时, 将 CEK 加密给接收方, 并让结果成为 JWE Encrypted Key.

  5. 当采用 Direct Key Agreement 或 Direct Encryption (直接加密) 时, 让 JWE Encrypted Key 成为空八位字节序列.

  6. 当采用 Direct Encryption 时, 让 CEK 成为共享的对称密钥.

  7. 计算编码的密钥值 BASE64URL(JWE Encrypted Key).

  8. 如果正在使用 JWE JSON Serialization, 则对每个接收方重复此过程 (步骤 1-7).

  9. 为内容加密算法生成正确大小的随机 JWE Initialization Vector (如果算法需要); 否则, 让 JWE Initialization Vector 成为空八位字节序列.

  10. 计算编码的 Initialization Vector 值 BASE64URL(JWE Initialization Vector).

  11. 如果包含 "zip" 参数, 则使用指定的压缩算法压缩明文, 并让 M 成为表示压缩明文的八位字节序列; 否则, 让 M 成为表示明文的八位字节序列.

  12. 创建包含所需 Header Parameters 集合的 JSON 对象, 这些对象共同构成 JOSE Header: JWE Protected Header、JWE Shared Unprotected Header 和 JWE Per-Recipient Unprotected Header 中的一个或多个.

  13. 计算 Encoded Protected Header 值 BASE64URL(UTF8(JWE Protected Header)). 如果 JWE Protected Header 不存在 (这只能在使用 JWE JSON Serialization 且没有 "protected" 成员存在时发生), 则让此值为空字符串.

  14. 让 Additional Authenticated Data 加密参数为 ASCII(Encoded Protected Header). 但是, 如果存在 JWE AAD 值 (这只能在使用 JWE JSON Serialization 时), 则让 Additional Authenticated Data 加密参数为 ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

  15. 使用 CEK、JWE Initialization Vector 和 Additional Authenticated Data 值, 使用指定的内容加密算法加密 M, 以创建 JWE Ciphertext 值和 JWE Authentication Tag (这是加密操作的 Authentication Tag 输出).

  16. 计算编码的密文值 BASE64URL(JWE Ciphertext).

  17. 计算编码的 Authentication Tag 值 BASE64URL(JWE Authentication Tag).

  18. 如果存在 JWE AAD 值, 则计算编码的 AAD 值 BASE64URL(JWE AAD).

  19. 创建所需的序列化输出. 此结果的 Compact Serialization 是字符串 BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). JWE JSON Serialization 在第 7.2 节中描述.

5.2 Message Decryption (消息解密)

消息解密过程是加密过程的逆过程. 在输入和输出之间没有依赖关系的情况下, 步骤的顺序并不重要. 如果任何这些步骤失败, 则无法验证加密内容.

当存在多个接收方时, 由应用程序决定哪些接收方的加密内容必须成功验证才能接受 JWE. 在某些情况下, 所有接收方的加密内容都必须成功验证, 否则 JWE 将被视为无效. 在其他情况下, 只需要成功验证单个接收方的加密内容. 但是, 在所有情况下, 至少一个接收方的加密内容必须 (MUST) 成功验证, 否则必须 (MUST) 将 JWE 视为无效.

  1. 解析 JWE 表示以提取 JWE 组件的序列化值. 使用 JWE Compact Serialization 时, 这些组件是 JWE Protected Header、JWE Encrypted Key、JWE Initialization Vector、JWE Ciphertext 和 JWE Authentication Tag 的 base64url 编码表示, 使用 JWE JSON Serialization 时, 这些组件还包括 JWE AAD 的 base64url 编码表示以及未编码的 JWE Shared Unprotected Header 和 JWE Per-Recipient Unprotected Header 值. 使用 JWE Compact Serialization 时, JWE Protected Header、JWE Encrypted Key、JWE Initialization Vector、JWE Ciphertext 和 JWE Authentication Tag 按该顺序表示为 base64url 编码的值, 每个值与下一个值之间用单个句点 ('.') 字符分隔, 从而恰好使用四个分隔句点字符. JWE JSON Serialization 在第 7.2 节中描述.

  2. Base64url 解码 JWE Protected Header、JWE Encrypted Key、JWE Initialization Vector、JWE Ciphertext、JWE Authentication Tag 和 JWE AAD 的编码表示, 遵循不使用换行符、空白或其他附加字符的限制.

  3. 验证解码编码的 JWE Protected Header 产生的八位字节序列是符合 RFC 7159 [RFC7159] 的完全有效 JSON 对象的 UTF-8 编码表示; 让 JWE Protected Header 成为此 JSON 对象.

  4. 如果使用 JWE Compact Serialization, 则让 JOSE Header 成为 JWE Protected Header. 否则, 当使用 JWE JSON Serialization 时, 让 JOSE Header 成为 JWE Protected Header、JWE Shared Unprotected Header 和相应 JWE Per-Recipient Unprotected Header 的成员的并集, 所有这些都必须是完全有效的 JSON 对象. 在此步骤中, 验证结果 JOSE Header 不包含重复的 Header Parameter 名称. 使用 JWE JSON Serialization 时, 此限制包括相同的 Header Parameter 名称也禁止 (MUST NOT) 出现在共同构成 JOSE Header 的不同 JSON 对象值中.

  5. 验证实现理解并可以处理它需要支持的所有字段, 无论是本规范要求的、正在使用的算法要求的, 还是 "crit" Header Parameter 值要求的, 并且这些参数的值也被理解和支持.

  6. 确定 "alg" (algorithm, 算法) Header Parameter 指定的算法所采用的 Key Management Mode.

  7. 验证 JWE 使用接收方已知的密钥.

  8. 当采用 Direct Key Agreement 或 Key Agreement with Key Wrapping 时, 使用密钥协商算法计算协商密钥的值. 当采用 Direct Key Agreement 时, 让 CEK 成为协商的密钥. 当采用 Key Agreement with Key Wrapping 时, 协商的密钥将用于解密 JWE Encrypted Key.

  9. 当采用 Key Wrapping、Key Encryption 或 Key Agreement with Key Wrapping 时, 解密 JWE Encrypted Key 以产生 CEK. CEK 的长度必须 (MUST) 等于内容加密算法所需的长度. 请注意, 当存在多个接收方时, 每个接收方只能解密加密到该接收方拥有的密钥的 JWE Encrypted Key 值. 因此, 只能解密每接收方 JWE Encrypted Key 值之一以获取 CEK 值是正常的. 另请参见第 11.5 节, 了解有关缓解时序攻击的安全注意事项.

  10. 当采用 Direct Key Agreement 或 Direct Encryption 时, 验证 JWE Encrypted Key 值是空八位字节序列.

  11. 当采用 Direct Encryption 时, 让 CEK 成为共享的对称密钥.

  12. 记录是否能够为此接收方成功确定 CEK.

  13. 如果正在使用 JWE JSON Serialization, 则对表示中包含的每个接收方重复此过程 (步骤 4-12).

  14. 计算 Encoded Protected Header 值 BASE64URL(UTF8(JWE Protected Header)). 如果 JWE Protected Header 不存在 (这只能在使用 JWE JSON Serialization 且没有 "protected" 成员存在时发生), 则让此值为空字符串.

  15. 让 Additional Authenticated Data 加密参数为 ASCII(Encoded Protected Header). 但是, 如果存在 JWE AAD 值 (这只能在使用 JWE JSON Serialization 时), 则让 Additional Authenticated Data 加密参数为 ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

  16. 使用 CEK、JWE Initialization Vector、Additional Authenticated Data 值和 JWE Authentication Tag (这是计算的 Authentication Tag 输入), 使用指定的内容加密算法解密 JWE Ciphertext, 返回解密的明文并以为算法指定的方式验证 JWE Authentication Tag, 如果 JWE Authentication Tag 不正确则拒绝输入而不发出任何解密输出.

  17. 如果包含 "zip" 参数, 则使用指定的压缩算法解压缩解密的明文.

  18. 如果没有接收方的所有解密步骤都成功, 则必须 (MUST) 将 JWE 视为无效. 否则, 输出明文. 在 JWE JSON Serialization 情况下, 还向应用程序返回一个结果, 指示哪些接收方的解密成功和失败.

最后, 请注意, 由应用程序决定在给定上下文中可以使用哪些算法. 即使可以成功解密 JWE, 除非 JWE 中使用的算法对应用程序可接受, 否则应该 (SHOULD) 将 JWE 视为无效.

5.3 String Comparison Rules (字符串比较规则)

本规范的字符串比较规则与 [JWS] 第 5.3 节中定义的规则相同.