[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
JSON Web 加密（JWE）
摘要
JSON Web 加密（JWE）使用基于 JSON 的数据结构来表示被加密的内容。
本规范中使用的密码算法和标识符在独立的 JSON Web 算法（JWA）规范中
进行了描述，并由该规范所定义的 IANA 注册表进行管理。
相关的数字签名和消息认证码（MAC）能力在独立的 JSON Web 签名（JWS）
规范中进行了描述。
本文档状态
本文档是一个 Internet 标准轨道文档。
本文档是 Internet 工程任务组（IETF）的成果。
它代表了 IETF 社区的共识。
本文档已接受公众审查，并已获 Internet 工程指导组（IESG）批准发布。
有关 Internet 标准的更多信息，参见
RFC 5741 第 2 节。
有关本文档当前状态、任何勘误信息，以及如何对其提供反馈的信息，
可通过以下地址获得：
http://www.rfc-editor.org/info/rfc7516。
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones & Hildebrand Standards Track [Page 1]
RFC 7516 JSON Web Encryption (JWE) May 2015
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 符号约定 . . . . . . . . . . . . . . . . . . . . . . . 4
2. 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web 加密（JWE）概述 . . . . . . . . . . . . . . . . 8
3.1. JWE 紧凑序列化概述 . . . . . . . . . . . . . . . . . 8
3.2. JWE JSON 序列化概述 . . . . . . . . . . . . . . . . . 9
3.3. JWE 示例 . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE 头部 . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. 已注册的头部参数名称 . . . . . . . . . . . . . . . . 11
4.1.1. “alg”（算法）头部参数 . . . . . . . . . . . . . . 12
4.1.2. “enc”（加密算法）头部参数 . . . . . . . . . . . . 12
4.1.3. “zip”（压缩算法）头部参数 . . . . . . . . . . . 12
4.1.4. “jku”（JWK 集 URL）头部参数 . . . . . . . . . . 13
4.1.5. “jwk”（JSON Web 密钥）头部参数 . . . . . . . . . 13
4.1.6. “kid”（密钥 ID）头部参数 . . . . . . . . . . . 13
4.1.7. “x5u”（X.509 URL）头部参数 . . . . . . . . . . 13
4.1.8. “x5c”（X.509 证书链）头部参数 . . . . . . . . . 13
4.1.9. “x5t”（X.509 证书 SHA-1 指纹）头部
参数 . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. “x5t#S256”（X.509 证书 SHA-256 指纹）
头部参数 . . . . . . . . . . . . . . . . . . 14
4.1.11. “typ”（类型）头部参数 . . . . . . . . . . . . 14
4.1.12. “cty”（内容类型）头部参数 . . . . . . . . . . 14
4.1.13. “crit”（关键）头部参数 . . . . . . . . . . . 14
4.2. 公共头部参数名称 . . . . . . . . . . . . . . . . . 14
4.3. 私有头部参数名称 . . . . . . . . . . . . . . . . . 15
5. JWE 的生成与使用 . . . . . . . . . . . . . . . . . . . 15
5.1. 消息加密 . . . . . . . . . . . . . . . . . . . . . 15
5.2. 消息解密 . . . . . . . . . . . . . . . . . . . . . 17
5.3. 字符串比较规则 . . . . . . . . . . . . . . . . . . 20
6. 密钥标识 . . . . . . . . . . . . . . . . . . . . . . 20
7. 序列化 . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE 紧凑序列化 . . . . . . . . . . . . . . . . . . 20
7.2. JWE JSON 序列化 . . . . . . . . . . . . . . . . . 20
7.2.1. 通用 JWE JSON 序列化语法 . . . . . . . . . . . 21
7.2.2. 扁平化 JWE JSON 序列化语法 . . . . . . . . . . 23
8. TLS 要求 . . . . . . . . . . . . . . . . . . . . . . 24
9. 区分 JWS 与 JWE 对象 . . . . . . . . . . . . . . . 24
10. IANA 注意事项 . . . . . . . . . . . . . . . . . . . . 25
10.1. JSON Web 签名与加密头部参数
注册 . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. 注册表内容 . . . . . . . . . . . . . . . . . 25
11. 安全注意事项 . . . . . . . . . . . . . . . . . . . . 27
11.1. 密钥熵与随机值 . . . . . . . . . . . . . . . . 27
11.2. 密钥保护 . . . . . . . . . . . . . . . . . . . . 27
11.3. 使用匹配的算法强度 . . . . . . . . . . . . . . 28
Jones & Hildebrand Standards Track [Page 2]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.4. 自适应选择密文攻击 . . . . . . . . . . . . . . . . 28
11.5. 时序攻击 . . . . . . . . . . . . . . . . . . . . . 28
12. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. 规范性参考文献 . . . . . . . . . . . . . . . . . . 29
12.2. 参考性文献 . . . . . . . . . . . . . . . . . . . . 30
附录 A. JWE 示例 . . . . . . . . . . . . . . . . . . . . . . 32
A.1. 使用 RSAES-OAEP 与 AES GCM 的 JWE 示例 . . . . . . . 32
A.1.1. JOSE 头部 . . . . . . . . . . . . . . . . . . . . 32
A.1.2. 内容加密密钥（CEK） . . . . . . . . . . . . . . 32
A.1.3. 密钥加密 . . . . . . . . . . . . . . . . . . . 33
A.1.4. 初始化向量 . . . . . . . . . . . . . . . . . . . 34
A.1.5. 附加认证数据 . . . . . . . . . . . . . . . . . . 35
A.1.6. 内容加密 . . . . . . . . . . . . . . . . . . . 35
A.1.7. 完整表示 . . . . . . . . . . . . . . . . . . . . 36
A.1.8. 验证 . . . . . . . . . . . . . . . . . . . . . 36
A.2. 使用 RSAES-PKCS1-v1_5 与
AES_128_CBC_HMAC_SHA_256 的 JWE 示例 . . . . . . . . 36
A.2.1. JOSE 头部 . . . . . . . . . . . . . . . . . . . . 37
A.2.2. 内容加密密钥（CEK） . . . . . . . . . . . . . . 37
A.2.3. 密钥加密 . . . . . . . . . . . . . . . . . . . 38
A.2.4. 初始化向量 . . . . . . . . . . . . . . . . . . . 39
A.2.5. 附加认证数据 . . . . . . . . . . . . . . . . . . 40
A.2.6. 内容加密 . . . . . . . . . . . . . . . . . . . 40
A.2.7. 完整表示 . . . . . . . . . . . . . . . . . . . . 40
A.2.8. 验证 . . . . . . . . . . . . . . . . . . . . . 41
A.3. 使用 AES 密钥封装 与
AES_128_CBC_HMAC_SHA_256 的 JWE 示例 . . . . . . . . 41
A.3.1. JOSE 头部 . . . . . . . . . . . . . . . . . . . . 41
A.3.2. 内容加密密钥（CEK） . . . . . . . . . . . . . . 42
A.3.3. 密钥加密 . . . . . . . . . . . . . . . . . . . 42
A.3.4. 初始化向量 . . . . . . . . . . . . . . . . . . . 42
A.3.5. 附加认证数据 . . . . . . . . . . . . . . . . . . 43
A.3.6. 内容加密 . . . . . . . . . . . . . . . . . . . 43
A.3.7. 完整表示 . . . . . . . . . . . . . . . . . . . . 43
A.3.8. 验证 . . . . . . . . . . . . . . . . . . . . . 44
A.4. 使用通用 JWE JSON 序列化的 JWE 示例 . . . . . . . 44
A.4.1. JWE 按接收者未受保护头部 . . . . . . . . . . . . 45
A.4.2. JWE 受保护头部 . . . . . . . . . . . . . . . . 45
A.4.3. JWE 共享未受保护头部 . . . . . . . . . . . . . . 45
A.4.4. 完整 JOSE 头部值 . . . . . . . . . . . . . . . . 45
A.4.5. 附加认证数据 . . . . . . . . . . . . . . . . . . 46
A.4.6. 内容加密 . . . . . . . . . . . . . . . . . . . 46
A.4.7. 完整 JWE JSON 序列化表示 . . . . . . . . . . . . 47
A.5. 使用扁平化 JWE JSON 序列化的 JWE 示例 . . . . . . . 47
附录 B. AES_128_CBC_HMAC_SHA_256 计算示例 . . . . 48
B.1. 从密钥中提取 MAC_KEY 与 ENC_KEY . . . . . . . . . 48
B.2. 加密明文以创建密文 . . . . . . . . . . . . . . . . 49
B.3. AAD 长度的 64 位大端表示 . . . . . . . . . . . . . 49
Jones & Hildebrand Standards Track [Page 3]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.4. 初始化向量值 . . . . . . . . . . . . . . . . . . . 49
B.5. 创建用于 HMAC 计算的输入 . . . . . . . . . . . . . 50
B.6. 计算 HMAC 值 . . . . . . . . . . . . . . . . . . . 50
B.7. 截断 HMAC 值以创建认证标签 . . . . . . . . . . . . 50
致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1. 引言
JSON Web 加密（JWE）使用基于 JSON 的数据结构来表示加密内容
[RFC7159]。
JWE 的密码机制对任意字节序列进行加密，并提供完整性保护。
定义了两种紧密相关的 JWE 序列化方式。JWE 紧凑序列化是一种紧凑、
URL 安全的表示形式，适用于诸如 HTTP Authorization 头部和 URI
查询参数等空间受限的环境。JWE JSON 序列化将 JWE 表示为 JSON
对象，并使相同内容能够被加密给多个参与方。二者共享相同的密码学
基础。
本规范中使用的密码算法和标识符在独立的 JSON Web 算法（JWA）
[JWA] 规范以及该规范
所定义的 IANA 注册表中进行了描述。相关的数字签名和 MAC 能力在
独立的 JSON Web 签名（JWS）
[JWS] 规范中进行了描述。
本规范所定义的名称都很简短，因为一个核心目标是使最终的表示形式
保持紧凑。
1.1. 符号约定
本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、
“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、
“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL”，应按
《用于 RFC 中表示需求级别的关键词》
[RFC2119] 中的描述进行解释。
仅当这些术语以全大写形式出现时，才适用该解释。
BASE64URL(OCTETS) 表示 OCTETS 的 base64url 编码，
参见 [JWS] 的第 2 节。
UTF8(STRING) 表示 STRING 的 UTF-8
[RFC3629]
表示形式中的字节序列，其中 STRING 是由零个或多个 Unicode
[UNICODE] 字符组成的序列。
Jones & Hildebrand Standards Track [Page 4]
RFC 7516 JSON Web Encryption (JWE) May 2015
ASCII(STRING) 表示 STRING 的 ASCII
[RFC20]
表示形式中的字节序列，其中 STRING 是由零个或多个 ASCII 字符
组成的序列。
两个值 A 与 B 的连接表示为 A || B。
2. 术语
术语 “JSON Web 签名（JWS）”、“Base64url 编码”、
“抗碰撞名称”、“头部参数”、“JOSE 头部” 和
“StringOrURI” 定义于 JWS 规范
[JWS] 中。
术语 “密文（Ciphertext）”、“数字签名”、“初始化向量
（IV）”、“消息认证码（MAC）” 和 “明文（Plaintext）”
定义于《Internet Security Glossary, Version 2》
[RFC4949]。
以下术语由本规范定义：
JSON Web 加密（JWE）
表示加密并受完整性保护的消息的数据结构。
具有关联数据的认证加密（AEAD）
AEAD 算法是一类对明文进行加密、允许指定附加认证数据，
并对密文和附加认证数据提供集成内容完整性校验的算法。
AEAD 算法接受两个输入：明文和附加认证数据值，
并产生两个输出：密文和认证标签值。
AES Galois/Counter Mode（GCM）即为此类算法之一。
附加认证数据（AAD）
AEAD 操作的一个输入，该数据受完整性保护但不被加密。
认证标签
AEAD 操作的一个输出，用于确保密文和附加认证数据的完整性。
注意，某些算法可能不使用认证标签，在这种情况下，
该值为空字节序列。
内容加密密钥（CEK）
用于 AEAD 算法的对称密钥，用以加密明文并生成密文
和认证标签。
Jones & Hildebrand Standards Track [Page 5]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE 加密密钥
已加密的内容加密密钥值。注意，对于某些算法，
JWE 加密密钥值被规定为空字节序列。
JWE 初始化向量
在加密明文时使用的初始化向量值。
注意，对于某些算法，可能不使用初始化向量，
在这种情况下，该值为空字节序列。
JWE AAD
由认证加密操作进行完整性保护的附加值。
该值仅在使用 JWE JSON 序列化时存在。
（注意，在使用 JWE 紧凑序列化或 JWE JSON
序列化时，也可以通过将 AAD 值作为一个受完整性保护的
头部参数值来实现这一点，但代价是该值会被进行两次
base64url 编码。）
JWE 密文
使用附加认证数据对明文进行认证加密后得到的密文值。
JWE 认证标签
使用附加认证数据对明文进行认证加密后得到的认证标签值。
JWE 受保护头部
一个 JSON 对象，包含由认证加密操作进行完整性保护的
头部参数。这些参数适用于 JWE 的所有接收者。
对于 JWE 紧凑序列化，这构成整个 JOSE 头部。
对于 JWE JSON 序列化，这是 JOSE 头部的一个组成部分。
JWE 共享未受保护头部
一个 JSON 对象，包含适用于 JWE 所有接收者但不受完整性
保护的头部参数。该对象仅在使用 JWE JSON 序列化时存在。
JWE 按接收者未受保护头部
一个 JSON 对象，包含仅适用于某一单个接收者的头部参数。
这些头部参数值不受完整性保护。
该对象仅在使用 JWE JSON 序列化时存在。
JWE 紧凑序列化
将 JWE 表示为紧凑、URL 安全字符串的一种表示形式。
Jones & Hildebrand Standards Track [Page 6]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSON 序列化
将 JWE 表示为 JSON 对象的一种表示形式。
JWE JSON 序列化使相同内容能够被加密给多个参与方。
该表示形式既未针对紧凑性进行优化，也不是 URL 安全的。
密钥管理模式
用于确定所使用内容加密密钥值的方法。
每一种用于确定 CEK 值的算法都使用一种特定的密钥管理模式。
本规范所采用的密钥管理模式包括：密钥加密、密钥封装、
直接密钥协商、带密钥封装的密钥协商，以及直接加密。
密钥加密
一种密钥管理模式，其中使用非对称加密算法将 CEK 值
加密给预期的接收者。
密钥封装
一种密钥管理模式，其中使用对称密钥封装算法将 CEK 值
加密给预期的接收者。
直接密钥协商
一种密钥管理模式，其中使用密钥协商算法来协商 CEK 值。
带密钥封装的密钥协商
一种密钥管理模式，其中使用密钥协商算法来协商一个
对称密钥，再使用该对称密钥通过对称密钥封装算法
将 CEK 值加密给预期的接收者。
直接加密
一种密钥管理模式，其中所使用的 CEK 值即为各方之间
共享的对称秘密密钥值。
Jones & Hildebrand Standards Track [Page 7]
RFC 7516 JSON Web Encryption (JWE) May 2015
3. JSON Web 加密（JWE）概述
JWE 使用 JSON 数据结构和 base64url 编码来表示加密内容。
这些 JSON 数据结构可以在任何 JSON 值或结构字符之前或之后
包含空白字符和/或换行符，这符合
RFC 7159 第 2 节
[RFC7159]。
一个 JWE 表示以下逻辑值（每一项均定义于
第 2 节）：
o JOSE 头部
o JWE 加密密钥
o JWE 初始化向量
o JWE AAD
o JWE 密文
o JWE 认证标签
对于一个 JWE，JOSE 头部成员是以下各值成员的并集
（每一项均定义于 第 2 节）：
o JWE 受保护头部
o JWE 共享的未受保护头部
o JWE 按接收方的未受保护头部
JWE 使用带认证的加密来确保明文的机密性与完整性，
以及 JWE 受保护头部和 JWE AAD 的完整性。
本文档为 JWE 定义了两种序列化形式：一种是紧凑的、
URL 安全的序列化形式，称为 JWE 紧凑序列化；
另一种是称为 JWE JSON 序列化的 JSON 序列化形式。
在这两种序列化中，JWE 受保护头部、JWE 加密密钥、
JWE 初始化向量、JWE 密文以及 JWE 认证标签都使用
base64url 编码，因为 JSON 缺乏直接表示任意字节序列的方法。
当存在时，JWE AAD 也使用 base64url 编码。
3.1. JWE 紧凑序列化概述
在 JWE 紧凑序列化中，不使用 JWE 共享的未受保护头部
或 JWE 按接收方的未受保护头部。
在这种情况下，JOSE 头部与 JWE 受保护头部是相同的。
Jones & Hildebrand Standards Track [Page 8]
RFC 7516 JSON Web Encryption (JWE) May 2015
在 JWE 紧凑序列化中，一个 JWE 表示为以下内容的拼接：
BASE64URL(UTF8(JWE 受保护头部)) || '.' ||
BASE64URL(JWE 加密密钥) || '.' ||
BASE64URL(JWE 初始化向量) || '.' ||
BASE64URL(JWE 密文) || '.' ||
BASE64URL(JWE 认证标签)
有关 JWE 紧凑序列化的更多信息，请参见
第 7.1 节。
3.2. JWE JSON 序列化概述
在 JWE JSON 序列化中，JWE 受保护头部、
JWE 共享的未受保护头部以及 JWE 按接收方的未受保护头部
中的一个或多个必须存在。
在这种情况下，JOSE 头部的成员是所有存在的
JWE 受保护头部、JWE 共享的未受保护头部以及
JWE 按接收方的未受保护头部成员的并集。
在 JWE JSON 序列化中，一个 JWE 表示为一个 JSON 对象，
该对象包含以下八个成员中的部分或全部：
"protected"，其值为 BASE64URL(UTF8(JWE 受保护头部))
"unprotected"，其值为 JWE 共享的未受保护头部
"header"，其值为 JWE 按接收方的未受保护头部
"encrypted_key"，其值为 BASE64URL(JWE 加密密钥)
"iv"，其值为 BASE64URL(JWE 初始化向量)
"ciphertext"，其值为 BASE64URL(JWE 密文)
"tag"，其值为 BASE64URL(JWE 认证标签)
"aad"，其值为 BASE64URL(JWE AAD)
六个经 base64url 编码的结果字符串以及两个未受保护的
JSON 对象值作为成员表示在一个 JSON 对象中。
其中某些值的包含是可选的。
JWE JSON 序列化还可以将同一明文加密给多个接收方。
有关 JWE JSON 序列化的更多信息，请参见
第 7.2 节。
Jones & Hildebrand Standards Track [Page 9]
RFC 7516 JSON Web Encryption (JWE) May 2015
3.3. JWE 示例
本示例将明文
“The true sign of intelligence is not knowledge but imagination.”
加密给接收方。
以下示例 JWE 受保护头部声明了：
o 内容加密密钥使用 RSAES-OAEP
[RFC3447]
算法加密给接收方，以生成 JWE 加密密钥。
o 使用带有 256 位密钥的 AES GCM
[AES]
[NIST.800-38D]
算法对明文执行带认证的加密，
以生成密文和认证标签。
{"alg":"RSA-OAEP","enc":"A256GCM"}
将此 JWE 受保护头部编码为
BASE64URL(UTF8(JWE 受保护头部)) 得到以下值：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
完成创建该 JWE 的其余步骤如下：
o 生成一个随机的内容加密密钥（CEK）。
o 使用 RSAES-OAEP 算法并结合接收方的公钥对 CEK 进行加密，
以生成 JWE 加密密钥。
o 对 JWE 加密密钥进行 base64url 编码。
o 生成一个随机的 JWE 初始化向量。
o 对 JWE 初始化向量进行 base64url 编码。
o 令附加认证数据加密参数为
ASCII(BASE64URL(UTF8(JWE 受保护头部)))。
o 使用 AES GCM 算法对明文执行带认证的加密，
其中 CEK 作为加密密钥，
并使用 JWE 初始化向量和附加认证数据值，
请求输出一个 128 位的认证标签。
o 对密文进行 base64url 编码。
o 对认证标签进行 base64url 编码。
Jones & Hildebrand Standards Track [Page 10]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 组装最终表示形式：该结果的紧凑序列化形式为字符串
BASE64URL(UTF8(JWE 受保护头部)) || '.' ||
BASE64URL(JWE 加密密钥) || '.' ||
BASE64URL(JWE 初始化向量) || '.' ||
BASE64URL(JWE 密文) || '.' ||
BASE64URL(JWE 认证标签)。
本示例的最终结果如下（仅为显示目的加入了换行符）：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
有关计算该 JWE 的完整细节，请参见
附录 A.1。
有关更多示例，请参见
附录 A，
其中包括在 A.4 和 A.5 节中使用 JWE JSON 序列化的示例。
4. JOSE 头部
对于一个 JWE，表示 JOSE 头部的 JSON 对象的成员
描述了应用于明文的加密方式，
以及可选的 JWE 的附加属性。
JOSE 头部中的头部参数名称必须是唯一的，
正如 [JWS] 第 4 节中所描述的那样。
对于实现无法理解的头部参数的处理规则也是相同的。
头部参数名称的分类方式同样一致。
4.1. 已注册的头部参数名称
以下用于 JWE 的头部参数名称已在
[JWS]
建立的 IANA“JSON Web Signature and Encryption Header Parameters”
注册表中注册，其含义如下所定义。
如公共注册表所示，JWS 与 JWE 共享同一个头部参数命名空间；
当某个参数被这两个规范同时使用时，
其用法必须在这两个规范之间保持兼容。
Jones & Hildebrand Standards Track [Page 11]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.1. “alg”（算法）头部参数
该参数具有与
[JWS]
第 4.1.1 节中定义的 “alg” 头部参数相同的含义、
语法和处理规则，
不同之处在于该头部参数标识用于加密或确定 CEK 值的
密码算法。
如果 “alg” 的值不表示受支持的算法，
或接收方没有可用于该算法的密钥，
则加密内容不可用。
用于该用途的已定义 “alg” 值列表可在
[JWA]
建立的 IANA
“JSON Web Signature and Encryption Algorithms”
注册表中找到；
该注册表的初始内容为
[JWA]
第 4.1 节中定义的值。
4.1.2. “enc”（加密算法）头部参数
“enc”（加密算法）头部参数标识用于对明文执行
带认证的加密以生成密文和认证标签的
内容加密算法。
该算法必须是具有指定密钥长度的 AEAD 算法。
如果 “enc” 的值不表示受支持的算法，
则加密内容不可用。
“enc” 值应当注册在
[JWA]
建立的 IANA
“JSON Web Signature and Encryption Algorithms”
注册表中，或者是一个包含抗冲突名称的值。
“enc” 的值是一个区分大小写的 ASCII 字符串，
包含一个 StringOrURI 值。
该头部参数必须存在，
并且实现必须理解并处理该参数。
用于该用途的已定义 “enc” 值列表可在
[JWA]
建立的 IANA
“JSON Web Signature and Encryption Algorithms”
注册表中找到；
该注册表的初始内容为
[JWA]
第 5.1 节中定义的值。
4.1.3. “zip”（压缩算法）头部参数
在加密之前（如果有）应用于明文的
“zip”（压缩算法）。
本规范定义的 “zip” 值为：
o “DEF” —— 使用 DEFLATE
[RFC1951]
算法进行压缩
也可以使用其他值。
压缩算法值可以注册在
[JWA]
建立的 IANA
“JSON Web Encryption Compression Algorithms”
注册表中。
“zip” 的值是一个区分大小写的字符串。
如果不存在 “zip” 参数，
则在加密前不对明文进行压缩。
当使用该头部参数时，
它必须受到完整性保护；
因此，它只能出现在 JWE 受保护头部中。
使用该头部参数是可选的。
实现必须理解并处理该头部参数。
Jones & Hildebrand Standards Track [Page 12]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.4. “jku”（JWK 集 URL）头部参数
该参数具有与
[JWS]
第 4.1.2 节中定义的 “jku” 头部参数
相同的含义、语法和处理规则，
不同之处在于 JWK 集资源包含
JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
4.1.5. “jwk”（JSON Web 密钥）头部参数
该参数具有与
[JWS]
第 4.1.3 节中定义的 “jwk” 头部参数
相同的含义、语法和处理规则，
不同之处在于该密钥是
JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
4.1.6. “kid”（密钥 ID）头部参数
该参数具有与
[JWS]
第 4.1.4 节中定义的 “kid” 头部参数
相同的含义、语法和处理规则，
不同之处在于该密钥提示引用的是
JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
该参数允许生成方明确向 JWE 接收方
指示密钥的更换。
4.1.7. “x5u”（X.509 URL）头部参数
该参数具有与
[JWS]
第 4.1.5 节中定义的 “x5u” 头部参数
相同的含义、语法和处理规则，
不同之处在于 X.509 公钥证书或证书链
[RFC5280]
包含 JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
4.1.8. “x5c”（X.509 证书链）头部参数
该参数具有与
[JWS]
第 4.1.6 节中定义的 “x5c” 头部参数
相同的含义、语法和处理规则，
不同之处在于 X.509 公钥证书或证书链
[RFC5280]
包含 JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
有关 “x5c” 值的示例，
请参见 [JWS]
的 附录 B。
Jones & Hildebrand Standards Track [Page 13]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.9. “x5t”（X.509 证书 SHA-1 指纹）头部参数
该参数具有与
[JWS]
第 4.1.7 节中定义的 “x5t” 头部参数
相同的含义、语法和处理规则，
不同之处在于指纹所引用的证书
包含 JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
请注意，证书指纹有时也被称为证书指印。
4.1.10. “x5t#S256”（X.509 证书 SHA-256 指纹）头部
参数
该参数具有与
[JWS]
第 4.1.8 节中定义的 “x5t#S256” 头部参数
相同的含义、语法和处理规则，
不同之处在于指纹所引用的证书
包含 JWE 被加密到的公钥；
这可用于确定解密该 JWE 所需的私钥。
请注意，证书指纹有时也被称为证书指印。
4.1.11. “typ”（类型）头部参数
该参数具有与
[JWS]
第 4.1.9 节中定义的 “typ” 头部参数
相同的含义、语法和处理规则，
不同之处在于该类型是
此完整 JWE 的类型。
4.1.12. “cty”（内容类型）头部参数
该参数具有与
[JWS]
第 4.1.10 节中定义的 “cty” 头部参数
相同的含义、语法和处理规则，
不同之处在于该类型是
被保护内容（明文）的类型。
4.1.13. “crit”（关键）头部参数
该参数具有与
[JWS]
第 4.1.11 节中定义的 “crit” 头部参数
相同的含义、语法和处理规则，
不同之处在于这里所指的是
JWE 的头部参数，
而非 JWS 的头部参数。
4.2. 公共头部参数名称
使用 JWE 的各方可以定义附加的头部参数名称。
然而，为了防止冲突，
任何新的头部参数名称
要么应当注册在
[JWS]
建立的 IANA
“JSON Web Signature and Encryption Header Parameters”
注册表中，
要么应当是一个公共名称：
即一个包含抗冲突名称的值。
在每种情况下，
名称或值的定义者都需要采取合理的
Jones & Hildebrand Standards Track [Page 14]
RFC 7516 JSON Web Encryption (JWE) May 2015
防止措施，以确保他们能够控制用于定义 Header 参数名称的命名空间部分。
新的 Header 参数应谨慎引入，因为它们可能导致不可互操作的 JWE。
4.3. 私有 Header 参数名称
JWE 的生产者和消费者可以达成协议，使用私有名称的 Header 参数名称：这些名称不是注册的 Header 参数名称（第 4.1 节）
或公共 Header 参数名称（第 4.2 节）。与公共 Header 参数名称不同，私有 Header 参数名称可能发生冲突，因此应谨慎使用。
5. Producing and Consuming JWEs
5.1. Message Encryption
消息加密过程如下。步骤的顺序在没有输入和输出之间依赖关系的情况下不重要。
1. 确定用于确定内容加密密钥值的算法所采用的密钥管理模式。
（这是记录在结果 JWE 的 "alg"（算法）Header 参数中的算法。）
2. 当采用密钥包装、密钥加密或带密钥包装的密钥协议时，生成一个随机的 CEK 值。
请参阅 RFC 4086 [RFC4086]，了解生成随机值的注意事项。
CEK 必须具有与内容加密算法要求的长度相等的长度。
3. 当采用直接密钥协议或带密钥包装的密钥协议时，使用密钥协议算法计算商定密钥的值。
当采用直接密钥协议时，设 CEK 为商定的密钥。
当采用带密钥包装的密钥协议时，商定的密钥将用于包装 CEK。
4. 当采用密钥包装、密钥加密或带密钥包装的密钥协议时，将 CEK 加密到接收方，并让结果成为 JWE 加密密钥。
5. 当采用直接密钥协议或直接加密时，设 JWE 加密密钥为空字节序列。
6. 当采用直接加密时，设 CEK 为共享的对称密钥。
7. 计算编码后的密钥值 BASE64URL(JWE 加密密钥)。
8. 如果正在使用 JWE JSON 序列化，则对每个接收方重复此过程（步骤 1-7）。
9. 生成一个随机的 JWE 初始化向量，其大小符合内容加密算法的要求（如果该算法要求的话）；否则，将 JWE 初始化向量设为空字节序列。
10. 计算编码后的初始化向量值 BASE64URL(JWE 初始化向量)。
11. 如果包括了 "zip" 参数，则使用指定的压缩算法压缩明文，并设 M 为表示压缩明文的字节序列；否则，设 M 为表示明文的字节序列。
12. 创建包含所需 Header 参数的 JSON 对象，这些对象共同构成 JOSE Header：一个或多个 JWE 保护 Header、JWE 共享非保护 Header 和 JWE 每个接收方的非保护 Header。
13. 计算编码的保护 Header 值 BASE64URL(UTF8(JWE 保护 Header))。
如果 JWE 保护 Header 不存在（这只会发生在使用 JWE JSON 序列化且没有 "protected" 成员的情况下），则该值为空字符串。
14. 让额外认证数据加密参数为 ASCII(编码的保护 Header)。
但是，如果存在 JWE AAD 值（这只能在使用 JWE JSON 序列化时发生），则额外认证数据加密参数应为 ASCII(编码的保护 Header || '.' || BASE64URL(JWE AAD))。
15. 使用 CEK、JWE 初始化向量和额外认证数据值，使用指定的内容加密算法加密 M，生成 JWE 密文值和 JWE 认证标签（即加密操作的认证标签输出）。
16. 计算编码后的密文值 BASE64URL(JWE 密文)。
17. 计算编码的认证标签值 BASE64URL(JWE 认证标签)。
18. 如果存在 JWE AAD 值，则计算编码的 AAD 值 BASE64URL(JWE AAD)。
19. 创建所需的序列化输出。此结果的紧凑序列化是字符串 BASE64URL(UTF8(JWE 保护 Header))
|| '.' || BASE64URL(JWE 加密密钥) || '.' || BASE64URL(JWE 初始化向量) || '.' || BASE64URL(JWE 密文) || '.' ||
BASE64URL(JWE 认证标签)。 JWE JSON 序列化在 第 7.2 节 中描述。
5.2. 消息解密
消息解密过程是加密过程的逆过程。当步骤之间的输入和输出
没有依赖关系时，步骤的顺序并不重要。如果任何一个步骤失败，
则无法验证加密内容。
当有多个接收方时，由应用程序决定哪些接收方的加密内容
必须成功验证才能接受 JWE。在某些情况下，所有接收方的加密
内容都必须成功验证，否则 JWE 会被认为是无效的。在其他情况
下，只需要单个接收方的加密内容成功验证即可。然而，在所有情
况下，至少一个接收方的加密内容必须成功验证，否则 JWE 必须
被认为是无效的。
1. 解析 JWE 表示形式以提取 JWE 组件的序列化值。当使用
JWE 紧凑序列化时，这些组件是 JWE 保护头（JWE Protected
Header）、JWE 加密密钥（JWE Encrypted Key）、JWE 初始
向量（JWE Initialization Vector）、JWE 密文（JWE Ciphertext）、
和 JWE 身份验证标签（JWE Authentication Tag）的 base64url 编码表示；
当使用 JWE JSON 序列化时，这些组件还包括 JWE AAD 的 base64url
编码表示以及未编码的 JWE 共享非保护头（JWE Shared Unprotected Header）
和 JWE 每个接收方非保护头（JWE Per-Recipient Unprotected Header）值。
使用 JWE 紧凑序列化时，JWE 保护头、JWE 加密密钥、JWE
初始向量、JWE 密文和 JWE 身份验证标签按照此顺序表示为
base64url 编码值，每个值之间用一个点字符（'.'）分隔，总共
恰好使用四个分隔点字符。JWE JSON 序列化详见第7.2节。
Jones & Hildebrand Standards Track [Page 17]
RFC 7516 JSON Web Encryption (JWE) May 2015
2. 对 JWE 保护头、JWE 加密密钥、JWE 初始向量、JWE 密文、
JWE 身份验证标签和 JWE AAD 的编码表示进行 base64url 解码，
遵守未使用换行、空白或其他附加字符的限制。
3. 验证解码后的 JWE 保护头的八位字节序列是否是一个完全有效的
JSON 对象的 UTF-8 编码表示，并符合RFC 7159
[RFC7159] 的规范；
将 JWE 保护头定义为该 JSON 对象。
4. 如果使用 JWE 紧凑序列化，将 JOSE 头定义为 JWE 保护头。
否则，当使用 JWE JSON 序列化时，将 JOSE 头定义为 JWE 保护头、
JWE 共享非保护头和相应的 JWE 每个接收方非保护头成员的
并集，这些都必须是完全有效的 JSON 对象。在这一过程中，
验证生成的 JOSE 头不包含重复的头参数名称。当使用
JWE JSON 序列化时，此限制包括相同的头参数名称也不得出现在
构成 JOSE 头的不同 JSON 对象值中。
5. 验证实现能理解并处理所有需要支持的字段，无论是规范
要求、被使用的算法要求，还是由 "crit" 头参数值要求；
并验证这些参数值是否也被理解和支持。
6. 确定由 "alg"（算法）头参数指定的算法所使用的密钥管理模式。
7. 验证 JWE 是否使用了接收方已知的密钥。
8. 当采用直接密钥协商或带密钥包装的密钥协商时，
使用密钥协商算法计算协商的密钥。当使用直接密钥协商时，
将 CEK 定义为协商的密钥。当使用带密钥包装的密钥协商时，
将协商的密钥用于解密 JWE 加密密钥。
9. 当采用密钥包装、密钥加密或带密钥包装的密钥协商时，
解密 JWE 加密密钥以生成 CEK。CEK 的长度必须等于
内容加密算法的要求长度。注意，当有多个接收方时，
每个接收方只能解密使用该接收方密钥加密的 JWE 加密密钥值。
因此，通常只能解密其中一个接收方的 JWE 加密密钥值以获得
CEK 值。另见第11.5节了解关于减轻时间攻击的安全注意事项。
10. 当采用直接密钥协商或直接加密时，
验证 JWE 加密密钥值是一个空的八位字节序列。
11. 当采用直接加密时，将 CEK 定义为共享对称密钥。
12. 记录是否能成功为此接收方确定 CEK。
13. 如果使用 JWE JSON 序列化，则对表示中的每个接收方重复
此过程（步骤 4-12）。
14. 计算编码保护头值 BASE64URL(UTF8(JWE 保护头))。
如果 JWE 保护头不存在（仅当使用 JWE JSON 序列化且无
"protected" 成员时），将此值定义为空字符串。
15. 将附加身份验证数据加密参数定义为 ASCII(编码保护头)。
然而，如果存在 JWE AAD 值（仅当使用 JWE JSON 序列化时才可能出现），
则将附加身份验证数据加密参数定义为 ASCII(编码保护头 || '.' ||
BASE64URL(JWE AAD))。
16. 使用 CEK、JWE 初始向量、附加身份验证数据值和
JWE 身份验证标签（此标签即指定的内容加密算法中的
身份验证标签输入）解密 JWE 密文，返回解密后的明文，
并以算法指定的方式验证 JWE 身份验证标签；
如果 JWE 身份验证标签不正确，则拒绝输入并且不产生解密输出。
17. 如果包含 "zip" 参数，使用指定的压缩算法解压缩
解密后的明文。
18. 如果没有任何接收方的解密步骤全部成功，则 JWE 必须
被视为无效。否则，输出明文。在 JWE JSON 序列化情况下，
同时返回结果给应用程序，指示哪些接收方的解密
成功或失败。
Jones & Hildebrand Standards Track [Page 19]
RFC 7516 JSON Web Encryption (JWE) May 2015
最后，需注意由应用程序决策在特定上下文中可以使用哪些算法。
即使 JWE 可以成功解密，如果 JWE 中使用的算法不为
应用程序接受，则应用程序应视该 JWE 为无效。
5.3. 字符串比较规则
本规范的字符串比较规则与
[JWS] 第5.3节中定义的规则相同。
6. 密钥标识
本规范的密钥标识方法与
[JWS] 第6节中定义的方法相同，唯一的不同是
被标识的是 JWE 所加密的公钥。
7. 序列化
JWE 使用两种序列化方式之一：JWE 紧凑序列化或
JWE JSON 序列化。使用本规范的应用需要指定应用中
使用的序列化方式及其特性。比如，应用可能指定只使用
JWE JSON 序列化，仅支持单个接收方的 JWE JSON 序列化，
或支持多接收方。JWE 的实现只需实现其设计支持的
应用所需的功能。
7.1. JWE 紧凑序列化
JWE 紧凑序列化将加密内容表示为
一个紧凑的、URL 安全的字符串。该字符串格式为：
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)
JWE 紧凑序列化仅支持单一接收方，
它没有语法表示 JWE 共享非保护头、JWE
每接收方非保护头或 JWE AAD 值。
7.2. JWE JSON 序列化
JWE JSON 序列化将加密内容表示为 JSON
对象。这种表示既没有优化为紧凑也不
是 URL 安全的。
Jones & Hildebrand Standards Track [Page 20]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSON 序列化定义了两种密切相关
的语法：一种是完全通用语法，用于向多个接收方加密内容；
另一种是针对单接收方优化的扁平语法。
7.2.1. 通用 JWE JSON 序列化语法
以下成员被定义用于通用 JWE JSON 序列化语法的顶级 JSON 对象中：
protected
当 JWE 保护头值非空时，“protected”成员必须
存在并包含值 BASE64URL(UTF8(JWE Protected Header))；
否则，它必须不存在。这些头参数值受完整性保护。
unprotected
当 JWE 共享非保护头值非空时，“unprotected”成员
必须存在，并包含 JWE 共享非保护头值；否则，必须不存在。
此值表示为未经编码的 JSON 对象，而不是字符串。
这些头参数值不受完整性保护。
iv
当 JWE 初始向量值非空时，“iv”成员必须存在，
并包含值 BASE64URL(JWE Initialization Vector)；
否则，必须不存在。
aad
当 JWE AAD 值非空时，“aad”成员必须存在，并包含
值 BASE64URL(JWE AAD)；否则，必须不存在。
JWE AAD 值可用于提供一个 base64url 编码值，
仅供完整性保护而非加密。
ciphertext
“ciphertext”成员必须存在，并包含值
BASE64URL(JWE Ciphertext)。
tag
当 JWE 身份验证标签值非空时，“tag”成员必须存在，
并包含值 BASE64URL(JWE Authentication Tag)；
否则，必须不存在。
recipients
“recipients”成员值必须是一个 JSON 对象数组。
每个对象包含特定接收方的信息。
即使某些或所有数组元素值是空 JSON 对象 "{}"
(例如所有头参数值在接收方之间共享且未使用加密密钥，
如在直接加密中)，此成员也必须存在，每个
接收方必须正好有一个数组元素。
Jones & Hildebrand Standards Track [Page 21]
RFC 7516 JSON Web Encryption (JWE) May 2015
接收方，即使某些或所有数组元素值是空的 JSON 对象 "{}"
（可能发生在所有头参数值在所有接收方之间共享且未使用加密密钥时，
如在直接加密中）。
下列成员定义用于“recipients”数组中元素的 JSON 对象：
header
当 JWE 每接收方非保护头值非空时，“header”成员必须存在，
并包含值 JWE 每接收方非保护头；否则，必须不存在。
此值表示为未编码的 JSON 对象，而不是字符串。
这些头参数值不受完整性保护。
encrypted_key
当 JWE 加密密钥值非空时，“encrypted_key”成员必须存在，
并包含值 BASE64URL(JWE Encrypted Key)；否则，必须不存在。
“header”、“protected”和“unprotected”成员中至少有一个必须
存在，以便传递每个接收方计算所需的“alg”与“enc”头参数值。
上述 JSON 对象中还可以存在附加成员；若实现无法识别，
则必须忽略这些附加成员。
一些头参数（包括“alg”参数）可以在所有接收方计算中共享。
JWE 保护头和 JWE 共享非保护头中的头参数值在所有接收方之间共享。
创建或验证每接收方密文和身份验证标签值时使用的头参数值
是可能存在的三组头参数值的联合：(1) 在“protected”成员中表示的
JWE 保护头，(2) 在“unprotected”成员中表示的 JWE 共享非保护头，
以及 (3) 在接收方数组元素的“header”成员中表示的 JWE 每接收方
非保护头。这些头参数集合的联合构成 JOSE 头。三处的头参数名
必须彼此不重叠。
每个 JWE 加密密钥值都使用与 JWE 紧凑序列化相同方式的
相应 JOSE 头参数计算。这具有一个理想的属性，即“recipients”
数组中的每个 JWE 加密密钥值与在 JWE 紧凑序列化中为同一参数
所计算的值一致。同样，JWE 密文和 JWE 身份验证标签值也匹配
JWE 紧凑序列化所生成的值，前提是 JWE 保护头值（代表完整性受保护的
头参数值）与 JWE 紧凑序列化中使用的值一致。
Jones & Hildebrand Standards Track [Page 22]
RFC 7516 JSON Web Encryption (JWE) May 2015
所有接收方在存在时均使用相同的 JWE 保护头、JWE 初始向量、
JWE 密文和 JWE 身份验证标签值，如果消息较大，这可能导致显著
的空间节约。因此，所有指定明文值处理方式的头参数在所有接收方之间
必须相同。这主要意味着每个接收方的 JOSE 头中的“enc”（加密算法）
头参数值及该算法的所有参数值必须相同。
总之，通用 JWE JSON 序列化中 JWE 的语法如下：
{
"protected":"<integrity-protected shared header contents>",
"unprotected":<non-integrity-protected shared header contents>,
"recipients":[
{"header":<per-recipient unprotected header 1 contents>,
"encrypted_key":"<encrypted key 1 contents>"},
...
{"header":<per-recipient unprotected header N contents>,
"encrypted_key":"<encrypted key N contents>"}],
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
有关使用通用 JWE JSON 序列化语法的 JWE 示例，请参阅
附录A.4。
7.2.2. 扁平 JWE JSON 序列化语法
扁平 JWE JSON 序列化语法基于通用语法，但进行了扁平化，
针对单接收方的情况进行了优化。其方式是移除“recipients”成员，
并将为“recipients”数组中使用定义的那些成员（“header”和“encrypted_key”）
放置在顶级 JSON 对象中（与“ciphertext”成员同级）。
Jones & Hildebrand Standards Track [Page 23]
RFC 7516 JSON Web Encryption (JWE) May 2015
使用此语法时，“recipients”成员不得存在。
除了这种语法上的差异外，使用扁平语法的 JWE JSON
序列化对象与使用通用语法的对象处理方式相同。
总之，使用扁平 JWE JSON 序列化的 JWE 语法如下：
{
"protected":"<integrity-protected header contents>",
"unprotected":<non-integrity-protected header contents>,
"header":<more non-integrity-protected header contents>,
"encrypted_key":"<encrypted key contents>",
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
请注意，与使用通用语法一样，使用扁平语法时，
任何非保护头参数值可位于“unprotected”或“header”成员中，
或同时存在于两者中。
有关使用扁平 JWE JSON 序列化语法的 JWE 示例，请参阅
附录A.5。
8. TLS 要求
本规范的传输层安全性 (TLS) 要求
与 [JWS] 第8节中定义的要求相同。
9. 区分 JWS 和 JWE 对象
可以通过几种方式区分对象是 JWS 还是 JWE。
对于所有合法输入值，这些方法将得出相同的结果；
对于格式错误的输入，这些方法可能产生不同结果。
o 如果对象使用 JWS 紧凑序列化或 JWE 紧凑序列化，
按点（'.'）字符分隔的 base64url 编码段数量
在 JWS 和 JWE 之间有所不同。JWS 有三个段，
之间由两个点（'.'）字符分隔。JWE 有五个段，
之间由四个点（'.'）字符分隔。
o 如果对象使用 JWS JSON 序列化或 JWE JSON 序列化，
使用的成员将不同。JWS 包含一个“payload”成员，
而 JWE 不包含。JWE 包含一个“ciphertext”成员，
而 JWS 不包含。
Jones & Hildebrand Standards Track [Page 24]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 可以通过检查“alg”（算法）头参数的值来区分
JWS 的 JOSE 头和 JWE 的 JOSE 头。如果该值表示数字签名或
MAC 算法，或者值是“none”，则是用于 JWS；如果它表示
密钥加密、密钥包装、直接密钥协商、带密钥包装的密钥协商，
或直接加密算法，则是用于 JWE。（使用 JWS 紧凑序列化
或 JWE 紧凑序列化时，提取“alg”值进行检查是直接的，
而在使用 JWS JSON 序列化或 JWE JSON 序列化时可能更困难。）
o 还可以通过确定是否存在“enc”（加密算法）成员来区分
JWS 的 JOSE 头和 JWE 的 JOSE 头。如果存在“enc”成员，
则为 JWE；否则，为 JWS。
10. IANA 考量
10.1. JSON Web 签名和加密头参数注册
本节将在 IANA 的"JSON Web Signature and Encryption Header Parameters"
注册表中注册第 4.1 节中定义的头参数名称，
该注册表由 [JWS] 建立。
10.1.1. 注册表内容
o 头参数名称: "alg"
o 头参数描述: 算法
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.1 节
o 头参数名称: "enc"
o 头参数描述: 加密算法
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.2 节
o 头参数名称: "zip"
o 头参数描述: 压缩算法
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.3 节
Jones & Hildebrand Standards Track [Page 25]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 头参数名称: "jku"
o 头参数描述: JWK 集合 URL
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.4 节
o 头参数名称: "jwk"
o 头参数描述: JSON Web Key
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.5 节
o 头参数名称: "kid"
o 头参数描述: 密钥 ID
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.6 节
o 头参数名称: "x5u"
o 头参数描述: X.509 URL
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.7 节
o 头参数名称: "x5c"
o 头参数描述: X.509 证书链
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.8 节
o 头参数名称: "x5t"
o 头参数描述: X.509 证书 SHA-1 指纹
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.9 节
o 头参数名称: "x5t#S256"
o 头参数描述: X.509 证书 SHA-256 指纹
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.10 节
o 头参数名称: "typ"
o 头参数描述: 类型
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.11 节
Jones & Hildebrand Standards Track [Page 26]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 头参数名称: "cty"
o 头参数描述: 内容类型
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.12 节
o 头参数名称: "crit"
o 头参数描述: 关键
o 头参数使用位置: JWE
o 变更控制者: IESG
o 规范文档: RFC 7516 第 4.1.13 节
11. 安全考量
所有与密码学应用相关的安全问题都必须由 JWS/JWE/JWK
代理处理。在这些问题之中，需要保护用户的非对称私钥
和对称密钥，并采用各种针对攻击的应对措施。
JWS 规范中的所有安全考量同样适用于本规范。
同样，XML 加密 1.1 [W3C.REC-xmlenc-core1-20130411] 的所有安全考量
也适用，除了与 XML 相关的特定问题。
11.1. 密钥熵和随机值
有关密钥熵和随机值的安全考量，请参见
[JWS] 的第 10.1 节。除了那里列出的
随机值用途，请注意随机值还用于内容加密
密钥（CEKs）和初始化向量（IVs）。
11.2. 密钥保护
有关密钥保护的安全考量，请参见
[JWS] 的第 10.2 节。除
了必须保护的密钥，执行加密的实现
必须保护密钥加密密钥和内容加密密钥。
密钥加密密钥的泄露可能导致所有用该密钥保护的内容
被披露。同样，内容加密密钥的泄露可能导致关联
的加密内容被披露。
Jones & Hildebrand Standards Track [Page 27]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.3. 使用匹配的算法强度
应尽可能一起使用匹配强度的算法。例如，当使用特定
密钥大小的 AES 密钥包装时，建议在使用 AES GCM 时也采用
相同的密钥大小。如果密钥加密算法和内容加密算法
不同，则实际的安全性由二者中较弱的算法决定。
另请参见 RFC 3766 [RFC3766]，了解有关用于交换对称密钥的
公共密钥强度的详细信息。
11.4. 自适应选择密文攻击
在解密时，必须特别注意不允许 JWE 接收方被
用作解密消息的探针。有关 RSAES-PKCS1-v1_5 攻击的具体
应对措施，请参阅 RFC 3218 [RFC3218]。攻击者可能修改
“alg”头参数的内容，从“RSA-OAEP”改为“RSA1_5”，从而
生成可被检测到的格式错误，即使使用 RSAES-OAEP 来加密 CEK，
也可以利用该错误来恢复 CEK。因此，特别重要的是，在
加密内容被拒绝时，将所有格式错误报告为单一错误，
包括 CEK、附加身份验证数据或密文的错误。
此外，可以通过将密钥的使用限制为一组有限的算法（通常为一种）
来防止此类攻击。例如，如果密钥被标记为仅用于“RSA-OAEP”，
则任何试图使用“RSA1_5”算法解密消息的行为都应因密钥使用无效
而立即失败。
11.5. 时间攻击
为减轻 RFC 3218 [RFC3218] 中描述的攻击，接收方
不得区分加密密钥的格式、填充和长度错误。
强烈建议在收到格式错误的密钥时，接收方生成一个
随机的 CEK 并继续执行下一步，以减轻时间攻击的风险。
Jones & Hildebrand Standards Track [Page 28]
RFC 7516 JSON Web Encryption (JWE) May 2015
12. 参考文献
12.1. 规范性参考文献
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, 2015年5月,
<http://www.rfc-editor.org/info/rfc7518>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015年5月,
<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015年5月,
<http://www.rfc-editor.org/info/rfc7515>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, 1996年5月,
<http://www.rfc-editor.org/info/rfc1951>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969年10月,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997年3月,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月,
<http://www.rfc-editor.org/info/rfc3629>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007年8月,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 2008年5月,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 2014年3月,
<http://www.rfc-editor.org/info/rfc7159>.
Jones & Hildebrand Standards Track [Page 29]
RFC 7516 JSON Web Encryption (JWE) May 2015
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
12.2. 参考资料（说明性参考）
[AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
2001年11月, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", 2010年9月,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", 工作进行中,
draft-rescorla-jsms-00, 2011年3月.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
2007年11月, <http://csrc.nist.gov/publications/
nistpubs/800-38D/SP-800-38D.pdf>.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218,
DOI 10.17487/RFC3218, 2002年1月,
<http://www.rfc-editor.org/info/rfc3218>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, 2003年2月,
<http://www.rfc-editor.org/info/rfc3447>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, 2004年4月,
<http://www.rfc-editor.org/info/rfc3766>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005年6月,
<http://www.rfc-editor.org/info/rfc4086>.
Jones & Hildebrand Standards Track [Page 30]
RFC 7516 JSON Web Encryption (JWE) May 2015
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, 2009年9月,
<http://www.rfc-editor.org/info/rfc5652>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium Recommendation
REC-xmlenc-core1-20130411, 2013年4月,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones & Hildebrand Standards Track [Page 31]
RFC 7516 JSON Web Encryption (JWE) May 2015
Appendix A. JWE 示例
本节提供了 JWE 计算的示例。
A.1. 使用 RSAES-OAEP 和 AES GCM 的 JWE 示例
本示例将明文 "The true sign of intelligence is
not knowledge but imagination." 使用 RSAES-OAEP 对密钥进行加密，
并使用 AES GCM 对内容进行加密，从而加密给接收者。该明文的表示（使用 JSON 数组表示法）为：
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,
111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,
101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,
101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,
110, 97, 116, 105, 111, 110, 46]
A.1.1. JOSE 头部
下列示例 JWE 保护头声明：
o 内容加密密钥（CEK）使用 RSAES-OAEP 算法加密给接收方，生成 JWE 加密密钥。
o 使用 AES GCM 算法对明文执行认证加密，使用 256 位密钥生成密文和认证标签。
{"alg":"RSA-OAEP","enc":"A256GCM"}
将该 JWE 保护头作为 BASE64URL(UTF8(JWE Protected
Header)) 编码得到该值：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
A.1.2. 内容加密密钥 (CEK)
生成一个 256 位的随机 CEK。在本例中，其值（使用 JSON 数组表示法）为：
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,
212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,
234, 64, 252]
Jones & Hildebrand Standards Track [Page 32]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.3. 密钥加密
使用接收方的公钥和 RSAES-OAEP 算法加密 CEK，以产生 JWE 加密密钥。本示例使用下列以 JSON Web Key [JWK] 格式表示的 RSA 密钥（为便于显示，值中包含换行）：
{"kty":"RSA",
"n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW
cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S
psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a
sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS
tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj
YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw",
"e":"AQAB",
"d":"kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7-kpDxY4-WY5N
WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9
3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk
qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl
t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-id-4OJr0h-K-VFs3VSnd
VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ",
"p":"1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-
SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf
fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0",
"q":"wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm
UDdaDYVTSNx_8Fyw1YYa9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX
IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc",
"dp":"ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL
hMXvo-uz-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827
rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE",
"dq":"Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj
ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB
UfCAiJVeESOjJDZPYHdHY8v1b-o-Z2X5tvLx-TCekf7oxyeKDUqKWjis",
"qi":"VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7
AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3
eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY"
}
Jones & Hildebrand Standards Track [Page 33]
RFC 7516 JSON Web Encryption (JWE) May 2015
由此产生的 JWE 加密密钥值为：
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203,
22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216,
82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220,
145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214,
74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182,
13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228,
173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158,
89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138,
243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6,
41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126,
215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58,
63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98,
193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215,
206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216,
104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197,
89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219,
172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134,
117, 114, 135, 206]
将该 JWE 加密密钥作为 BASE64URL(JWE Encrypted Key) 编码得到该值（为显示目的加入换行）：
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg
A.1.4. 初始化向量
生成一个随机的 96 位 JWE 初始化向量。在本例中，该值为：
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
将该 JWE 初始化向量作为 BASE64URL(JWE
Initialization Vector) 编码得到该值：
48V1_ALb6US04U3b
Jones & Hildebrand Standards Track [Page 34]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.5. 附加认证数据
将附加认证数据（Additional Authenticated Data）加密参数设为
ASCII(BASE64URL(UTF8(JWE Protected Header)))。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,
54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
A.1.6. 内容加密
使用 CEK 作为加密密钥，用 AES GCM 算法对明文进行认证加密，
使用上述 JWE 初始化向量和附加认证数据，并请求输出 128 位的认证标签。产生的密文为：
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122,
233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111,
104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32,
123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205,
160, 109, 64, 63, 192]
产生的认证标签值为：
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91,
210, 145]
将该 JWE 密文作为 BASE64URL(JWE Ciphertext) 编码得到该值（为显示目的加入换行）：
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A
将该 JWE 认证标签作为 BASE64URL(JWE Authentication
Tag) 编码得到该值：
XFBoMYUZodetZdvTiFvSkQ
Jones & Hildebrand Standards Track [Page 35]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.7. 完整表示
组装最终表示：该结果的紧凑序列化（Compact Serialization）为字符串 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag)。
本例中的最终结果（为显示目的加入换行）为：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
A.1.8. 验证
本示例说明了使用 RSAES-OAEP 进行密钥加密和使用 AES GCM 进行内容加密的 JWE 创建过程。上述结果可用于验证这些算法的 JWE 解密实现。注意，由于 RSAES-OAEP 计算包含随机值，上述加密结果不会完全可重现。然而，由于 AES GCM 计算是确定性的，使用这些输入执行的加密其 JWE 加密密文值将对所有加密保持一致。
A.2. 使用 RSAES-PKCS1-v1_5 和 AES_128_CBC_HMAC_SHA_256 的 JWE 示例
本示例将明文 "Live long and prosper." 使用 RSAES-PKCS1-v1_5 对密钥进行加密，并使用 AES_128_CBC_HMAC_SHA_256 对内容进行加密，发送给接收方。该明文的表示（使用 JSON 数组表示法）为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
Jones & Hildebrand Standards Track [Page 36]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.1. JOSE 头部
下列示例 JWE 保护头声明：
o 内容加密密钥使用 RSAES-PKCS1-v1_5 算法加密给接收方，从而产生 JWE 加密密钥。
o 使用 AES_128_CBC_HMAC_SHA_256 算法对明文执行认证加密，以产生密文和认证标签。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
将该 JWE 保护头作为 BASE64URL(UTF8(JWE Protected
Header)) 编码得到该值：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.2.2. 内容加密密钥 (CEK)
生成一个 256 位的随机 CEK。在本例中，密钥值为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
Jones & Hildebrand Standards Track [Page 37]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.3. 密钥加密
使用接收方的公钥和 RSAES-PKCS1-v1_5 算法加密 CEK，以产生 JWE 加密密钥。该
示例使用下列以 JSON Web Key [JWK] 格式
表示的 RSA 密钥（为便于显示，值中包含换行）：
{"kty":"RSA",
"n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl
UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre
cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_
7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI
Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU
7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw",
"e":"AQAB",
"d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq
1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry
nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_
0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj
-VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj
T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ",
"p":"9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68
ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP
krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM",
"q":"uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y
BhVfuG4shsp2j7rGnIio901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN
-3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0",
"dp":"w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv
ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra
Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs",
"dq":"o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff
7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_
odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU",
"qi":"eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC
tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-Tl-m0l_eFTj2KiqwGqE9PZ
B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo"
}
Jones & Hildebrand Standards Track [Page 38]
RFC 7516 JSON Web Encryption (JWE) May 2015
由此产生的 JWE 加密密钥值为：
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151,
176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181,
156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156,
116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223,
226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66,
212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253,
215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128,
66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199,
54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151,
250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197,
21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102,
166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222,
150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241,
124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242,
16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244,
248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167,
101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169,
146, 114, 165, 204, 71, 136, 41, 252]
将该 JWE 加密密钥作为 BASE64URL(JWE Encrypted Key) 编码得到该值（为显示目的加入换行）：
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
A.2.4. 初始化向量
生成一个随机的 128 位 JWE 初始化向量。在本例中，该值为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
将该 JWE 初始化向量作为 BASE64URL(JWE
Initialization Vector) 编码得到该值：
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 39]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.5. 附加认证数据
将附加认证数据（Additional Authenticated Data）加密参数设为
ASCII(BASE64URL(UTF8(JWE Protected Header)))。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105,
74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85,
50, 73, 110, 48]
A.2.6. 内容加密
使用 CEK 作为加密密钥，用 AES_128_CBC_HMAC_SHA_256 算法对明文进行认证加密，
使用上述 JWE 初始化向量和附加认证数据。使用附录 A.3中的值进行此操作的步骤在
附录 B中有详细说明。产生的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
产生的认证标签值为：
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100,
191]
将该 JWE 密文作为 BASE64URL(JWE Ciphertext) 编码得到该值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
将该 JWE 认证标签作为 BASE64URL(JWE Authentication
Tag) 编码得到该值：
9hH0vgRfYgPnAHOd8stkvw
A.2.7. 完整表示
组装最终表示：该结果的紧凑序列化（Compact Serialization）为字符串 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag).
Jones & Hildebrand Standards Track [Page 40]
RFC 7516 JSON Web Encryption (JWE) May 2015
本例中的最终结果（为显示目的加入换行）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
A.2.8. 验证
本示例说明了使用 RSAES-PKCS1-v1_5 进行密钥加密和使用 AES_CBC_HMAC_SHA2 进行内容
加密的 JWE 创建过程。上述结果可用于验证这些算法的 JWE 解密实现。注意，由于
RSAES-PKCS1-v1_5 计算包含随机值，上述加密结果不会完全可重现。然而，由于 AES-CBC
计算是确定性的，使用这些输入执行的加密其 JWE 加密密文值将对所有加密保持一致。
A.3. 使用 AES 密钥封装（AES Key Wrap）和 AES_128_CBC_HMAC_SHA_256 的 JWE 示例
本示例将明文 "Live long and prosper." 使用 AES 密钥封装对密钥进行加密，并使用
AES_128_CBC_HMAC_SHA_256 对内容进行加密，发送给接收方。该明文的表示（使用 JSON 数组表示法）为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
A.3.1. JOSE 头部
下列示例 JWE 保护头声明：
o 内容加密密钥使用 AES 密钥封装（AES Key Wrap）算法并以 128 位密钥加密给接收方，
从而产生 JWE 加密密钥。
o 使用 AES_128_CBC_HMAC_SHA_256 算法对明文执行认证加密，以产生密文和认证标签。
{"alg":"A128KW","enc":"A128CBC-HS256"}
Jones & Hildebrand Standards Track [Page 41]
RFC 7516 JSON Web Encryption (JWE) May 2015
将该 JWE 保护头作为 BASE64URL(UTF8(JWE Protected
Header)) 编码得到该值：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.3.2. 内容加密密钥 (CEK)
生成一个 256 位的随机 CEK。在本例中，值为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
A.3.3. 密钥加密
使用共享对称密钥和 AES 密钥封装（AES Key Wrap）算法加密 CEK，以产生 JWE
加密密钥。本示例使用下列以 JSON Web Key [JWK] 格式表示的对称密钥：
{"kty":"oct",
"k":"GawgguFyGrWKav7AX4VKUg"
}
由此产生的 JWE 加密密钥值为：
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216,
22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3,
76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
将该 JWE 加密密钥作为 BASE64URL(JWE Encrypted Key) 编码得到该值：
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
A.3.4. 初始化向量
生成一个随机的 128 位 JWE 初始化向量。在本例中，该值为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
将该 JWE 初始化向量作为 BASE64URL(JWE
Initialization Vector) 编码得到该值：
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 42]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.3.5. 附加认证数据
将附加认证数据（Additional Authenticated Data）加密参数设为
ASCII(BASE64URL(UTF8(JWE Protected Header)))。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
A.3.6. 内容加密
使用 CEK 作为加密密钥，用 AES_128_CBC_HMAC_SHA_256 算法对明文进行认证加密，
使用上述 JWE 初始化向量和附加认证数据。使用本示例中的值进行此操作的步骤在
附录 B中有详细说明。产生的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
产生的认证标签值为：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
将该 JWE 密文作为 BASE64URL(JWE Ciphertext) 编码得到该值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
将该 JWE 认证标签作为 BASE64URL(JWE Authentication
Tag) 编码得到该值：
U0m_YmjN04DJvceFICbCVQ
A.3.7. 完整表示
组装最终表示：该结果的紧凑序列化（Compact Serialization）为字符串 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag).
Jones & Hildebrand Standards Track [Page 43]
RFC 7516 JSON Web Encryption (JWE) May 2015
本例中的最终结果（为显示目的加入换行）为：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
U0m_YmjN04DJvceFICbCVQ
A.3.8. 验证
本示例说明了使用 AES 密钥封装（AES Key Wrap）进行密钥加密和使用 AES GCM 进行内容
加密的 JWE 创建过程。上述结果可用于验证这些算法的 JWE 解密实现。此外，由于 AES
密钥封装和 AES GCM 计算均为确定性的，使用这些输入执行的加密所得到的 JWE 值对于
所有加密均相同。由于计算是可重现的，这些结果也可用于验证这些算法的 JWE 加密实现。
A.4. 使用通用 JWE JSON 序列化 的示例
本节包含一个使用通用 JWE JSON 序列化语法的示例。该示例演示了将相同明文加密给
多个接收方的能力。
在本示例中存在两个接收方。用于第一个接收方的算法和密钥与
附录 A.2 中使用的相同。用于第二个接收方的算法和密钥
与 附录 A.3 中使用的相同。因此生成的 JWE 加密密钥值也相同；这些计算在此处不再重复。
明文、CEK、JWE 初始化向量和 JWE 保护头由所有接收方共享（这必须如此，因为密文和认证标签也被共享）。
Jones & Hildebrand Standards Track [Page 44]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.1. 每接收方的 JWE 非受保护头部
第一个接收方使用 RSAES-PKCS1-v1_5 算法来加密 CEK。第二个接收方使用 AES 密钥封装来加密 CEK。两个密钥均提供了 Key ID 值。用于表示这些
算法和密钥 ID 的两个 JWE 每接收方非受保护头部（JWE Per-Recipient Unprotected Header）值为：
{"alg":"RSA1_5","kid":"2011-04-29"}
和
{"alg":"A128KW","kid":"7"}
A.4.2. JWE 保护头部
使用 AES_128_CBC_HMAC_SHA_256 算法对明文执行认证加密，以产生公共的 JWE 密文和 JWE 认证标签值。表示该项的 JWE 保护头部值为：
{"enc":"A128CBC-HS256"}
将该 JWE 保护头部作为 BASE64URL(UTF8(JWE Protected
Header)) 编码得到该值：
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.4.3. JWE 共享非受保护头部
该 JWE 使用 "jku" 头参数来引用一个 JWK 集。
该项在下列 JWE 共享非受保护头部中表示为
值为:
{"jku":"https://server.example.com/keys.jwks"}
A.4.4. 完整的 JOSE 头部值
将所提供的 JWE 每接收方非受保护头部、JWE 保护头部和 JWE 共享非受保护头部值组合后，分别用于第一个和第二个接收方的 JOSE 头部值为：
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
Jones & Hildebrand Standards Track [Page 45]
RFC 7516 JSON Web Encryption (JWE) May 2015
and
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
A.4.5. 附加认证数据
将附加认证数据（Additional Authenticated Data）加密参数设为
ASCII(BASE64URL(UTF8(JWE Protected Header)))。该值为：
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73,
52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
A.4.6. 内容加密
使用 CEK 作为加密密钥，用 AES_128_CBC_HMAC_SHA_256 算法对明文进行认证加密，
使用 JWE 初始化向量和上述附加认证数据。使用附录 A.3中的值执行此操作的步骤在 附录 B 中有详细说明。产生的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
产生的认证标签值为：
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47,
207]
将该 JWE 密文作为 BASE64URL(JWE Ciphertext) 编码得到该值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
将该 JWE 认证标签作为 BASE64URL(JWE Authentication
Tag) 编码得到该值：
Mz-VPPyU4RlcuYv1IwIvzw
Jones & Hildebrand Standards Track [Page 46]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.7. 完整的 JWE JSON 序列化 表示
这些值的完整 JWE JSON 序列化如下（为显示目的在值内部加入换行）：
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
A.5. 使用扁平化（Flattened）JWE JSON 序列化的示例
本节包含一个使用扁平化 JWE JSON 序列化语法的示例。该示例演示了在扁平 JSON 结构中将明文加密给单一接收方的能力。
本示例中的值与前一节 附录 A.4 中上一个示例的第二个接收方的值相同。
Jones & Hildebrand Standards Track [Page 47]
RFC 7516 JSON Web Encryption (JWE) May 2015
这些值的完整 JWE JSON 序列化如下（为显示目的在值内部加入换行）：
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
附录 B. AES_128_CBC_HMAC_SHA_256 计算示例
本示例展示了使用来自 附录 A.3 示例中的值进行 AES_128_CBC_HMAC_SHA_256 认证加密计算的步骤。正如在 JWA 的第 5.2 节和 5.2.3 节中对该算法的定义所述，AES_CBC_HMAC_SHA2 系列算法使用分组加密标准（AES）在链式分组模式（CBC）下并使用 PKCS #7 填充来执行加密，同时使用 HMAC SHA-2 函数来执行完整性计算——在本例中为 HMAC SHA-256。
B.1. 从密钥中提取 MAC_KEY 和 ENC_KEY
本示例中使用的 256 位 AES_128_CBC_HMAC_SHA_256 密钥 K（使用 JSON 数组表示法）为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
使用此密钥的前 128 位作为 HMAC SHA-256 密钥 MAC_KEY，即：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206]
Jones & Hildebrand Standards Track [Page 48]
RFC 7516 JSON Web Encryption (JWE) May 2015
使用此密钥的后 128 位作为 AES-CBC 密钥 ENC_KEY，即：
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44,
207]
注意 MAC 密钥在输入密钥 K 中位于加密密钥之前；这一点与标识符 "AES_128_CBC_HMAC_SHA_256" 和 "A128CBC-HS256" 中算法名称的顺序相反。
B.2. 使用 ENC_KEY 对明文加密以创建密文
使用上述 ENC_KEY 以 AES-CBC 模式并采用 PKCS #7 填充对明文进行加密。该示例中的明文为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
加密结果如下，即密文输出：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
B.3. AAD 长度的 64 位大端表示
本示例中的附加认证数据（AAD）为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
该 AAD 长度为 51 字节，即 408 位。八位元组字符串 AL，即以大端 64 位无符号整数表示的 AAD 位数为：
[0, 0, 0, 0, 0, 0, 1, 152]
B.4. 初始化向量值
本示例中使用的初始化向量为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
Jones & Hildebrand Standards Track [Page 49]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.5. 构造 HMAC 计算的输入
将 AAD、初始化向量、密文和 AL 值连接起来。该连接的结果为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111,
116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24,
152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215,
104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
B.6. 计算 HMAC 值
对上述连接值计算 HMAC SHA-256。该结果 M 为：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105,
86, 229, 116]
B.7. 截断 HMAC 值以创建认证标签
将 HMAC 输出 M 的前半部分（128 位）作为认证标签输出 T。该截断值为：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
Acknowledgements
用于加密 JSON 内容的方案也由 "JSON Simple Encryption" [JSE] 和 "JavaScript Message
Security Format" [JSMS] 探讨过，这两者对本文档影响重大。本文档尝试尽可能显式地重用来自 XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] 和
RFC 5652 [RFC5652] 的相关概念，同时利用简单、紧凑的基于 JSON 的数据结构。
特别感谢 John Bradley、Eric Rescorla 和 Nat Sakimura 在讨论中提供的帮助，这些讨论有助于完善本规范的内容；感谢 Eric Rescorla 和 Joe Hildebrand 允许在本文档中重用 [JSMS] 的文本；并感谢 Eric Rescorla 合著了本规范的许多草稿。
感谢 Axel Nennker、Emmanuel Raviart、Brian Campbell 和 Edmund Jay 对本规范中示例的验证。
Jones & Hildebrand Standards Track [Page 50]
RFC 7516 JSON Web Encryption (JWE) May 2015
本规范由 JOSE 工作组起草，成员包含数十位积极且敬业的参与者。特别是，下列个人为本规范贡献了影响其内容的想法、反馈和措辞：
Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,
Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel
Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat
Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad 和 Karen O'Donoghue 主持 JOSE 工作组，Sean Turner、Stephen Farrell 和 Kathleen Moriarty 在制定本规范期间担任安全领域（Security Area）负责人。
Authors' Addresses
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joe Hildebrand
Cisco Systems, Inc.
EMail: jhildebr@cisco.com
Jones & Hildebrand Standards Track [Page 51]