[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 9864 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7518 Microsoft
Category: Standards Track May 2015
ISSN: 2070-1721
JSON Web 算法（JWA）
摘要
本规范注册了用于 JSON Web 签名（JWS）、JSON Web 加密
（JWE）以及 JSON Web 密钥（JWK）规范的密码算法和标识符。
它为这些标识符定义了若干 IANA 注册表。
本备忘录的状态
本文档是 Internet 标准轨道文档。
本文档是 Internet 工程任务组（IETF）的成果。
它代表了 IETF 社区的共识。
本文档已通过公开审查，并已获得 Internet
工程指导组（IESG）的批准发布。
有关 Internet 标准的更多信息，参见
RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误信息以及如何提供反馈的信息，
可通过以下地址获得：
http://www.rfc-editor.org/info/rfc7518。
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 Standards Track [Page 1]
RFC 7518 JSON Web Algorithms (JWA) May 2015
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 符号约定 . . . . . . . . . . . . . . . . . . . . . . . 4
2. 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 用于数字签名和 MAC 的密码算法 . . . . . . . . . . . . . 6
3.1. 用于 JWS 的 “alg”（算法）头参数取值 . . . . . . . . . 6
3.2. 使用 SHA-2 函数的 HMAC . . . . . . . . . . . . . . . . 7
3.3. 使用 RSASSA-PKCS1-v1_5 的数字签名 . . . . . . . . . . 8
3.4. 使用 ECDSA 的数字签名 . . . . . . . . . . . . . . . . 9
3.5. 使用 RSASSA-PSS 的数字签名 . . . . . . . . . . . . . . 10
3.6. 使用算法 “none” . . . . . . . . . . . . . . . . . . . 11
4. 用于密钥管理的密码算法 . . . . . . . . . . . . . . . . . 11
4.1. 用于 JWE 的 “alg”（算法）头参数取值 . . . . . . . . 12
4.2. 使用 RSAES-PKCS1-v1_5 的密钥加密 . . . . . . . . . . 13
4.3. 使用 RSAES OAEP 的密钥加密 . . . . . . . . . . . . . 14
4.4. 使用 AES 密钥封装的密钥封装 . . . . . . . . . . . . 14
4.5. 使用共享对称密钥的直接加密 . . . . . . . . . . . . 15
4.6. 使用椭圆曲线 Diffie-Hellman 的密钥协商
临时-静态（ECDH-ES） . . . . . . . . . . . . . . . . 15
4.6.1. 用于 ECDH 密钥协商的头参数 . . . . . . . . . . . 16
4.6.1.1. “epk”（临时公钥）头参数 . . . . . . . . . . . 16
4.6.1.2. “apu”（协商方 U 信息）头参数 . . . . . . . . 17
4.6.1.3. “apv”（协商方 V 信息）头参数 . . . . . . . . 17
4.6.2. ECDH 密钥协商的密钥派生 . . . . . . . . . . . . 17
4.7. 使用 AES GCM 的密钥加密 . . . . . . . . . . . . . . 18
4.7.1. 用于 AES GCM 密钥加密的头参数 . . . . . . . . 19
4.7.1.1. “iv”（初始化向量）头参数 . . . . . . . . . 19
4.7.1.2. “tag”（认证标签）头参数 . . . . . . . . . . 19
4.8. 使用 PBES2 的密钥加密 . . . . . . . . . . . . . . . 20
4.8.1. 用于 PBES2 密钥加密的头参数 . . . . . . . . . 20
4.8.1.1. “p2s”（PBES2 盐输入）头参数 . . . . . . . . 21
4.8.1.2. “p2c”（PBES2 计数）头参数 . . . . . . . . . 21
5. 用于内容加密的密码算法 . . . . . . . . . . . . . . . . . 21
5.1. 用于 JWE 的 “enc”（加密算法）头参数取值
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 算法 . . . . . . . . . . . . . . . . 22
5.2.1. 定义 AES_CBC_HMAC_SHA2 时使用的约定 . . . . . 23
5.2.2. 通用 AES_CBC_HMAC_SHA2 算法 . . . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 加密 . . . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 解密 . . . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 26
5.2.6. 使用 AES_CBC_HMAC_SHA2 的内容加密 . . . . . . 26
5.3. 使用 AES GCM 的内容加密 . . . . . . . . . . . . . . 27
6. 用于密钥的密码算法 . . . . . . . . . . . . . . . . . . . 27
6.1. “kty”（密钥类型）参数取值 . . . . . . . . . . . . 28
Jones Standards Track [Page 2]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.2. 椭圆曲线密钥的参数 . . . . . . . . . . . . . . . . . 28
6.2.1. 椭圆曲线公钥的参数 . . . . . . . . . . . . . . . . 28
6.2.1.1. “crv”（曲线）参数 . . . . . . . . . . . . . . 28
6.2.1.2. “x”（X 坐标）参数 . . . . . . . . . . . . . . 29
6.2.1.3. “y”（Y 坐标）参数 . . . . . . . . . . . . . . 29
6.2.2. 椭圆曲线私钥的参数 . . . . . . . . . . . . . . . 29
6.2.2.1. “d”（ECC 私钥）参数 . . . . . . . . . . . . . 29
6.3. RSA 密钥的参数 . . . . . . . . . . . . . . . . . . . . 30
6.3.1. RSA 公钥的参数 . . . . . . . . . . . . . . . . . . 30
6.3.1.1. “n”（模数）参数 . . . . . . . . . . . . . . . . 30
6.3.1.2. “e”（指数）参数 . . . . . . . . . . . . . . . 30
6.3.2. RSA 私钥的参数 . . . . . . . . . . . . . . . . . . 30
6.3.2.1. “d”（私有指数）参数 . . . . . . . . . . . . . 30
6.3.2.2. “p”（第一个素因子）参数 . . . . . . . . . . . 31
6.3.2.3. “q”（第二个素因子）参数 . . . . . . . . . . . 31
6.3.2.4. “dp”（第一个因子 CRT 指数）参数 . . . . . . 31
6.3.2.5. “dq”（第二个因子 CRT 指数）参数 . . . . . . . 31
6.3.2.6. “qi”（第一个 CRT 系数）参数 . . . . . . . . 31
6.3.2.7. “oth”（其他素数信息）参数 . . . . . . . . . . 31
6.4. 对称密钥的参数 . . . . . . . . . . . . . . . . . . . 32
6.4.1. “k”（密钥值）参数 . . . . . . . . . . . . . . . 32
7. IANA 注意事项 . . . . . . . . . . . . . . . . . . . . . . 32
7.1. JSON Web 签名与加密算法注册表 . . . . . . . . . . . 33
7.1.1. 注册模板 . . . . . . . . . . . . . . . . . . . . . . 34
7.1.2. 初始注册表内容 . . . . . . . . . . . . . . . . . . 35
7.2. 头参数名称注册 . . . . . . . . . . . . . . . . . . . . 42
7.2.1. 注册表内容 . . . . . . . . . . . . . . . . . . . . . 42
7.3. JSON Web 加密压缩算法注册表 . . . . . . . . . . . . . 43
7.3.1. 注册模板 . . . . . . . . . . . . . . . . . . . . . . 43
7.3.2. 初始注册表内容 . . . . . . . . . . . . . . . . . . 44
7.4. JSON Web 密钥类型注册表 . . . . . . . . . . . . . . . 44
7.4.1. 注册模板 . . . . . . . . . . . . . . . . . . . . . . 44
7.4.2. 初始注册表内容 . . . . . . . . . . . . . . . . . . 45
7.5. JSON Web 密钥参数注册 . . . . . . . . . . . . . . . . 45
7.5.1. 注册表内容 . . . . . . . . . . . . . . . . . . . . . 46
7.6. JSON Web 密钥椭圆曲线注册表 . . . . . . . . . . . . 48
7.6.1. 注册模板 . . . . . . . . . . . . . . . . . . . . . . 48
7.6.2. 初始注册表内容 . . . . . . . . . . . . . . . . . . 49
8. 安全性注意事项 . . . . . . . . . . . . . . . . . . . . . . 49
8.1. 密码算法灵活性 . . . . . . . . . . . . . . . . . . . 50
8.2. 密钥生命周期 . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 的安全性注意事项 . . . . . . . . 50
8.4. AES GCM 的安全性注意事项 . . . . . . . . . . . . . . 50
8.5. 未加保护的 JWS 的安全性注意事项 . . . . . . . . . . 51
8.6. 拒绝服务攻击 . . . . . . . . . . . . . . . . . . . . 51
8.7. 在加密密钥时重用密钥材料 . . . . . . . . . . . . . 51
8.8. 密码注意事项 . . . . . . . . . . . . . . . . . . . . 52
8.9. 密钥熵与随机值 . . . . . . . . . . . . . . . . . . . 52
Jones Standards Track [Page 3]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.10. 数字签名与 MAC 之间的差异 . . . . . . . . . . . . . 52
8.11. 使用匹配的算法强度 . . . . . . . . . . . . . . . . 53
8.12. 自适应选择密文攻击 . . . . . . . . . . . . . . . . 53
8.13. 时序攻击 . . . . . . . . . . . . . . . . . . . . . . 53
8.14. RSA 私钥表示与盲化 . . . . . . . . . . . . . . . . 53
9. 国际化注意事项 . . . . . . . . . . . . . . . . . . . . . . 53
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. 规范性参考文献 . . . . . . . . . . . . . . . . . . . 53
10.2. 资料性参考文献 . . . . . . . . . . . . . . . . . . . 56
附录 A. 算法标识符交叉引用 . . . . . . . . 59
A.1. 数字签名/MAC 算法标识符交叉引用
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2. 密钥管理算法标识符交叉引用 . . . . . . . . . . . . 61
A.3. 内容加密算法标识符交叉引用 . . . . . . . . . . . . 62
附录 B. AES_CBC_HMAC_SHA2 算法的测试用例 . . . . 62
B.1. AES_128_CBC_HMAC_SHA_256 的测试用例 . . . . . . . . 63
B.2. AES_192_CBC_HMAC_SHA_384 的测试用例 . . . . . . . . 64
B.3. AES_256_CBC_HMAC_SHA_512 的测试用例 . . . . . . . . 65
附录 C. ECDH-ES 密钥协商计算示例 . . . . . . . . 66
致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1. 引言
本规范注册了用于 JSON Web 签名（JWS）[JWS]、
JSON Web 加密（JWE）[JWE] 以及
JSON Web 密钥（JWK）[JWK] 规范的
密码算法和标识符。
本规范为这些标识符定义了若干 IANA 注册表。
所有这些规范都使用基于 JSON 的
[RFC7159] 数据结构。
本规范还描述了特定于这些算法和密钥类型的语义与操作。
将算法和标识符在此处注册，而不是在 JWS、JWE 和 JWK 规范中注册，
旨在使它们在随着时间推移对必需、推荐、可选以及弃用算法集合发生变化时
仍可保持不变。
这也使得在不更改本文档的情况下，
可以对 JWS、JWE 和 JWK 规范进行修改。
本规范定义的名称较短，
因为一个核心目标是使生成的表示保持紧凑。
1.1. 符号约定
本文档中出现的关键字 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、
“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和
“OPTIONAL”，
应按
《用于 RFC 中指示需求级别的关键字》
[RFC2119]
中的描述进行解释。
Jones Standards Track [Page 4]
RFC 7518 JSON Web Algorithms (JWA) May 2015
只有当这些术语以全大写字母形式出现时，
才应应用上述解释。
BASE64URL(OCTETS) 表示按照
[JWS] 第 2 节
对 OCTETS 进行的 base64url 编码。
UTF8(STRING) 表示 STRING 的 UTF-8
[RFC3629]
表示形式中的字节序列，
其中 STRING 是由零个或多个 Unicode
[UNICODE]
字符组成的序列。
ASCII(STRING) 表示 STRING 的 ASCII
[RFC20]
表示形式中的字节序列，
其中 STRING 是由零个或多个 ASCII
字符组成的序列。
两个值 A 和 B 的连接记作 A || B。
2. 术语
术语 “JSON Web Signature (JWS)”、“Base64url Encoding”、“Header
Parameter”、“JOSE Header”、“JWS Payload”、“JWS Protected Header”、
“JWS Signature”、“JWS Signing Input” 以及 “Unsecured JWS”
由 JWS 规范
[JWS] 定义。
术语 “JSON Web Encryption (JWE)”、“Additional Authenticated Data
(AAD)”、“Authentication Tag”、“Content Encryption Key (CEK)”、
“Direct Encryption”、“Direct Key Agreement”、“JWE Authentication Tag”、
“JWE Ciphertext”、“JWE Encrypted Key”、“JWE Initialization Vector”、
“JWE Protected Header”、“Key Agreement with Key Wrapping”、“Key
Encryption”、“Key Management Mode” 以及 “Key Wrapping”
由 JWE 规范
[JWE] 定义。
术语 “JSON Web Key (JWK)” 和 “JWK Set”
由 JWK 规范
[JWK] 定义。
术语 “Ciphertext”、“Digital Signature”、“Initialization Vector”、
“Message Authentication Code (MAC)” 以及 “Plaintext”
由
《Internet Security Glossary, Version 2》
[RFC4949]
定义。
以下术语由本规范定义：
Base64urlUInt
将正整数或零整数值表示为其无符号大端序
字节序列形式的 base64url 编码。
该字节序列 MUST 使用表示该值所需的最少字节数。
零表示为 BASE64URL（单个零值字节），即 “AA”。
Jones Standards Track [Page 5]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3. 用于数字签名与MAC的密码算法
JWS使用密码算法对JWS受保护头部和JWS载荷的内容进行数字签名或生成MAC。
3.1. JWS的"alg"（算法）头部参数取值
下表为本规范为JWS定义的一组“alg”（算法）头部参数取值，每个取值在下文有详细解释：
+--------------+-------------------------------+--------------------+
| "alg"参数值 | 数字签名或MAC算法 | 实现要求 |
+--------------+-------------------------------+--------------------+
| HS256 | HMAC（SHA-256） | 必须实现 |
| HS384 | HMAC（SHA-384） | 可选实现 |
| HS512 | HMAC（SHA-512） | 可选实现 |
| RS256 | RSASSA-PKCS1-v1_5（SHA-256） | 推荐实现 |
| RS384 | RSASSA-PKCS1-v1_5（SHA-384） | 可选实现 |
| RS512 | RSASSA-PKCS1-v1_5（SHA-512） | 可选实现 |
| ES256 | ECDSA（P-256与SHA-256） | 推荐+ |
| ES384 | ECDSA（P-384与SHA-384） | 可选实现 |
| ES512 | ECDSA（P-521与SHA-512） | 可选实现 |
| PS256 | RSASSA-PSS（SHA-256及 | 可选实现 |
| | MGF1 with SHA-256） | |
| PS384 | RSASSA-PSS（SHA-384及 | 可选实现 |
| | MGF1 with SHA-384） | |
| PS512 | RSASSA-PSS（SHA-512及 | 可选实现 |
| | MGF1 with SHA-512） | |
| none | 未执行数字签名或MAC | 可选实现 |
+--------------+-------------------------------+--------------------+
在实现要求栏中的“+”表示在本规范的将来版本中该项的要求强度可能会提高。
参见附录A.1，该表交叉参照本规范中定义的JWS数字签名及MAC“alg”（算法）值与其他标准及软件包中的等效标识符。
Jones Standards Track [Page 6]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3.2. 使用SHA-2函数的HMAC
基于散列的消息认证码（HMAC）允许使用密钥加密码散列函数生成MAC。
这可用于证明生成MAC者拥有MAC密钥。
实现和验证HMAC的算法请参考RFC 2104 [RFC2104]。
使用该算法时，必须使用与散列输出等长或更长的密钥（例如，HS256应使用256位或更长的密钥）。
（该要求依据NIST SP 800-117的第5.3.4节（HMAC密钥的安全效力），指出有效安全强度为密钥的安全强度和内部散列值位数的两倍中的最小值。）
按照RFC 2104生成HMAC SHA-256 MAC，使用SHA-256作为哈希算法“H”，用JWS签名输入为“text”值，以及共享密钥。
HMAC输出值即为JWS签名。
以下“alg”（算法）头部参数值用于指示JWS签名是通过相应算法计算出的HMAC值：
+-------------------+--------------------+
| "alg"参数值 | MAC算法 |
+-------------------+--------------------+
| HS256 | HMAC（SHA-256） |
| HS384 | HMAC（SHA-384） |
| HS512 | HMAC（SHA-512） |
+-------------------+--------------------+
JWS的HMAC SHA-256 MAC通过RFC 2104计算HMAC值进行验证，方法为：用SHA-256作为哈希算法“H”，用收到的JWS签名输入为“text”值，使用共享密钥。
然后将��算出的HMAC值与接收到的、经过base64url解码的JWS签名字节序列进行比较。必须以常数时间方式完成比较，以防止时序攻击。
或者，也可将计算出的HMAC值进行base64url编码再和收到的编码JWS签名做比较（同样需要常数时间），因为这与直接比较未经编码的值结果一致。
无论哪种方式，如果值相同，则HMAC验证通过。
Jones Standards Track [Page 7]
RFC 7518 JSON Web Algorithms (JWA) May 2015
使用HMAC SHA-384和HMAC SHA-512算法进行内容保护和验证与HMAC SHA-256方法相同——只是分别使用相应的哈希算法，以及更大的最小密钥长度和输出值（HMAC SHA-384为384位，HMAC SHA-512为512位）。
使用该算法的示例见[JWS]的附录A.1。
3.3. RSASSA-PKCS1-v1_5数字签名
本节定义了RFC 3447第8.2节 [RFC3447]中规定的RSASSA-PKCS1-v1_5数字签名算法
（通常称为PKCS #1），并使用SHA-2 [SHS]散列函数。
这些算法必须配合2048位或更长的密钥使用。
生成RSASSA-PKCS1-v1_5 SHA-256数字签名的方法如下：使用RSASSA-PKCS1-v1_5-SIGN及SHA-256哈希函数与所需私钥，对JWS签名输入进行数字签名。该签名即为JWS签名值。
以下“alg”（算法）头部参数值用于指示JWS签名是通过相应算法计算出的数字签名值：
+-------------------+---------------------------------+
| "alg"参数值 | 数字签名算法 |
+-------------------+---------------------------------+
| RS256 | RSASSA-PKCS1-v1_5（SHA-256） |
| RS384 | RSASSA-PKCS1-v1_5（SHA-384） |
| RS512 | RSASSA-PKCS1-v1_5（SHA-512） |
+-------------------+---------------------------------+
验证JWS的RSASSA-PKCS1-v1_5 SHA-256数字签名的方法为：将JWS签名输入、JWS签名值及签名者使用的私钥对应公钥传递给RSASSA-PKCS1-v1_5-VERIFY算法，以SHA-256为哈希函数。
用RSASSA-PKCS1-v1_5 SHA-384和RSASSA-PKCS1-v1_5 SHA-512算法签名与验证方法与RSASSA-PKCS1-v1_5 SHA-256完全相同，仅使用不同哈希算法。
使用该算法的示例见[JWS]的附录A.2。
Jones Standards Track [Page 8]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3.4. ECDSA数字签名
椭圆曲线数字签名算法（ECDSA）[DSS]支持椭圆曲线密码学，可在提供与RSA加密等效安全性的同时，使用更短密钥和更快处理速度。
这意味着在提供相同安全性的情况下，ECDSA数字签名长度会比RSA短很多。
本规范定义了P-256曲线结合SHA-256哈希、P-384曲线结合SHA-384哈希、P-521曲线结合SHA-512哈希的ECDSA。P-256、P-384和P-521曲线定义见[DSS]。
生成ECDSA P-256 SHA-256数字签名的方法如下：
1. 用所需私钥，使用ECDSA P-256 SHA-256，对JWS签名输入生成数字签名。输出为一对（R, S），均为256位无符号整数。
2. 将R和S各自按大端序列化，每个数组为32字节。序列化的字节序列不能因前导零而缩短。
3. 将R和S的字节序列拼接（先R后S）。许多ECDSA实现直接输出这种拼接结果。
4. 得到的64字节序列即为JWS签名值。
以下“alg”参数值用于指示JWS签名为通过相应算法计算出的数字签名值：
+-------------------+-------------------------------+
| "alg"参数值 | 数字签名算法 |
+-------------------+-------------------------------+
| ES256 | ECDSA（P-256与SHA-256） |
| ES384 | ECDSA（P-384与SHA-384） |
| ES512 | ECDSA（P-521与SHA-512） |
+-------------------+-------------------------------+
Jones Standards Track [Page 9]
RFC 7518 JSON Web Algorithms (JWA) May 2015
验证JWS的ECDSA P-256 SHA-256数字签名方法如下：
1. JWS签名值必须为64字节序列，否则校验失败。
2. 将64字节分成两个32字节序列。前者表示R，后者表示S。R和S以SEC1第2.3.7节 [SEC1]定义的整数到字节序列转换（大端序）进行表示。
3. 将JWS签名输入，R、S 及公钥(x, y)提交给ECDSA P-256 SHA-256验证器。
采用ECDSA P-384 SHA-384和ECDSA P-521 SHA-512算法的签名和验证方法与ECDSA P-256 SHA-256完全一致，仅用相应哈希算法和更长输出值。
对ECDSA P-384 SHA-384，R和S各为384位，输出为96字节；ECDSA P-521 SHA-512时，R和S各为521位，输出为132字节。
（注意，SEC1第2.3.7节中的整数到字节序列转换遇到521位整数时会在高位填补零到8的倍数，因此每个521位整数用528位即66字节表示。）
采用这些算法的示例见[JWS]的附录A.3和A.4。
3.5. RSASSA-PSS数字签名
本节定义了RSASSA-PSS数字签名算法，详见RFC 3447第8.1节 [RFC3447]，
采用MGF1掩码生成函数与SHA-2哈希函数，RSASSA-PSS哈希函数与MGF1哈希函数始终一致。盐的长度等于哈希输出长度。
其它参数依RFC 3447附录A.2.3默认值。
必须配合2048位或更长的密钥使用本算法。
生成RSASSA-PSS SHA-256数字签名步骤如下：
用所需私钥对JWS签名输入，使用RSASSA-PSS-SIGN算法、SHA-256哈希函数和SHA-256的MGF1掩码生成函数，生成数字签名。该签名即为JWS签名值。
Jones Standards Track [Page 10]
RFC 7518 JSON Web Algorithms (JWA) May 2015
以下“alg”参数值用于指示JWS签名为用相应算法计算得到的数字签名值：
+-------------------+-----------------------------------------------+
| "alg"参数值 | 数字签名算法 |
+-------------------+-----------------------------------------------+
| PS256 | RSASSA-PSS（SHA-256及MGF1（SHA-256）） |
| PS384 | RSASSA-PSS（SHA-384及MGF1（SHA-384）） |
| PS512 | RSASSA-PSS（SHA-512及MGF1（SHA-512）） |
+-------------------+-----------------------------------------------+
JWS的RSASSA-PSS SHA-256数字签名验证方法如下：
将JWS签名输入、JWS签名、签名者所用私钥的公钥提交给RSASSA-PSS-VERIFY算法，使用SHA-256为哈希函数和SHA-256的MGF1作为掩码生成函数。
采用RSASSA-PSS SHA-384与RSASSA-PSS SHA-512签名与验证方式和RSASSA-PSS SHA-256一致，仅用不同哈希算法。
3.6. 使用“none”算法
JWS也可以不提供完整性保护。此类JWS被称为不安全JWS。
不安全JWS使用“alg”取值为“none”，格式与其他JWS完全一致，但JWS签名值必须为空字节序列。
接收方必须验证JWS签名值为空字节序列。
支持不安全JWS的实现不得接受该对象为有效，除非应用明确定义某特定对象可不受完整性保护。
实现默认不得接受不安全JWS。为减缓降级攻击，应用不得全局信号表示接受不安全JWS，应优先基于每个对象单独决定是否接受。
有关此算法的安全注意事项，参见第8.5节。
4. 用于密钥管理的密码算法
JWE使用密码算法加密或确定内容加密密钥（CEK）。
Jones Standards Track [Page 11]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.1. JWE的"alg"（算法）头部参数取值
下表是本规范为JWE定义的“alg”（算法）头部参数取值集。
这些算法用于加密CEK生成JWE加密密钥，或用密钥协商共同取得CEK。
+--------------------+--------------------+--------+----------------+
| "alg"参数值 | 密钥管理算法 |更多头部 | 实现要求 |
| | |参数 | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 |（无） | 推荐- |
| RSA-OAEP | 默认参数下的RSAES |（无） | 推荐+ |
| | OAEP | | |
| RSA-OAEP-256 | 使用SHA-256与 |（无） | 可选实现 |
| | MGF1（SHA-256）的 | | |
| | RSAES OAEP | | |
| A128KW | 默认初值AES密钥包 |（无） | 推荐实现 |
| | 装（128位密钥） | | |
| A192KW | 默认初值AES密钥包 |（无） | 可选实现 |
| | 装（192位密钥） | | |
| A256KW | 默认初值AES密钥包 |（无） | 推荐实现 |
| | 装（256位密钥） | | |
| dir | 直接使用共享对称 |（无） | 推荐实现 |
| | 密钥作为CEK | | |
| ECDH-ES | 椭圆曲线Diffie- | "epk", | 推荐+ |
| | Hellman临时静态 | "apu", | |
| | 密钥协商，Concat KDF|"apv" | |
| ECDH-ES+A128KW | ECDH-ES与Concat KDF|"epk", | 推荐实现 |
| | 并用“A128KW”包封CEK| "apu", | |
| | | "apv" | |
| ECDH-ES+A192KW | ECDH-ES与Concat KDF|"epk", | 可选实现 |
| | 并用“A192KW”包封CEK| "apu", | |
| | | "apv" | |
Jones Standards Track [Page 12]
RFC 7518 JSON Web Algorithms (JWA) May 2015
| ECDH-ES+A256KW | ECDH-ES 使用 | "epk", | 推荐实现 |
| | Concat KDF 且 CEK | "apu", | |
| | 用“A256KW”包裹 | "apv" | |
| | | | |
| A128GCMKW | AES GCM 128位密钥包| "iv", | 可选实现 |
| | 装 | "tag" | |
| | | | |
| A192GCMKW | AES GCM 192位密钥包| "iv", | 可选实现 |
| | 装 | "tag" | |
| | | | |
| A256GCMKW | AES GCM 256位密钥包| "iv", | 可选实现 |
| | 装 | "tag" | |
| | | | |
| PBES2-HS256+A128KW | PBES2结合HMAC | "p2s", | 可选实现 |
| | SHA-256与A128KW包 | "p2c" | |
| | 装 | | |
| PBES2-HS384+A192KW | PBES2结合HMAC | "p2s", | 可选实现 |
| | SHA-384与A192KW包 | "p2c" | |
| | 装 | | |
| PBES2-HS512+A256KW | PBES2结合HMAC | "p2s", | 可选实现 |
| | SHA-512与A256KW包 | "p2c" | |
| | 装 | | |
+--------------------+--------------------+--------+----------------+
“更多头部参数”栏说明算法除“alg”以外还需要哪些额外头部参数。除“dir”和“ECDH-ES”外，其余算法还需产生JWE加密密钥值。
实现要求栏中“+”表示未来规范版本中该项要求很可能提高强度，“-”则可能降低。
参见附录A.2，该表交叉参照本规范中定义的JWE“alg”（算法）值与其他标准及软件包中的等效标识符。
4.2. 用RSAES-PKCS1-v1_5加密密钥
本节定义用RSAES-PKCS1-v1_5加密JWE CEK的具体细节，详见[RFC3447]。
“alg”头部参数取值“RSA1_5”用于该算法。
本算法必须使用2048位或更长的密钥。
关于该算法的示例，见[JWE]的附录A.2。
Jones Standards Track [Page 13]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.3. 用RSAES OAEP加密密钥
本节定义了使用最优非对称加密填充（OAEP）[RFC3447]对JWE CEK进行RSAES加密的细节。
OAEP 有两组参数，分别用不同的哈希函数。第一组使用RFC 3447附录A.2.1中规定的默认参数（即SHA-1哈希和
MGF1 with SHA-1掩码生成函数）。第二组参数使用SHA-256哈希和
MGF1 with SHA-256掩码生成函数。
下述"alg"（算法）头部参数用于表示JWE加密密钥是用相应算法加密CEK所得：
+-------------------+-----------------------------------------------+
| "alg"参数 | 密钥管理算法 |
+-------------------+-----------------------------------------------+
| RSA-OAEP | 使用默认参数的RSAES OAEP |
| RSA-OAEP-256 | 使用SHA-256与MGF1（SHA-256）的RSAES OAEP |
+-------------------+-----------------------------------------------+
这些算法必须配合2048位或更长密钥使用。
（该要求基于NIST SP 800-57 [NIST.800-57] 的表4（安全强度时间段）——
新用途要求112位安全性，以及同文表2（可比强度）——2048位RSA密钥对应112位安全性。）
使用默认参数的RSAES OAEP示例如[JWE]的附录A.1。
4.4. 用AES密钥包裹加密密钥
本节定义了用高级加密标准（AES）密钥包裹算法 [RFC3394] 和
该文档第2.2.3.1节默认初始值对JWE CEK加密的具体细节。
Jones Standards Track [Page 14]
RFC 7518 JSON Web Algorithms (JWA) May 2015
下述"alg"（算法）头部参数表示JWE加密密钥由相应算法与密钥长度加密CEK所得：
+-----------------+-------------------------------------------------+
| "alg"参数 | 密钥管理算法 |
| 值 | |
+-----------------+-------------------------------------------------+
| A128KW | 默认初始值AES密钥包裹，128位密钥 |
| A192KW | 默认初始值AES密钥包裹，192位密钥 |
| A256KW | 默认初始值AES密钥包裹，256位密钥 |
+-----------------+-------------------------------------------------+
使用该算法的示例见[JWE附录A.3]。
4.5. 直接用共享对称密钥加密
本节定义了无需进行密钥包裹的直接对称密钥加密细节。
此时，共享对称密钥直接作为"enc"算法的内容加密密钥（CEK）使用。
JWE加密密钥值用空字节序列。
此场景下"alg"（算法）头参数的取值为"dir"。
采用直接加密时，参考8.2节中的密钥生命周期安全建议、8.4节的AES GCM建议。
4.6. 椭圆曲线Diffie-Hellman临时静态协商密钥
（ECDH-ES）
本节定义椭圆曲线Diffie-Hellman临时静态 [RFC6090]，
结合 Concat KDF（参见[NIST.800-56A] 第5.8.1节）密钥协商的具体细节。该协商结果有两种用法：
1. 在直接密钥协商模式下，直接用作"enc"算法的CEK；
2. 在密钥协商-包裹模式下，作为对称密钥配合"A128KW"、"A192KW"或"A256KW"算法包裹CEK。
每次协商操作都必须生成新的临时公钥值。
Jones Standards Track [Page 15]
RFC 7518 JSON Web Algorithms (JWA) May 2015
在直接密钥协商模式下，Concat KDF 输出密钥长度必须与"enc"算法一致。
此时，JWE加密密钥值为空字节序列，"alg"参数取"ECDH-ES"。
在密钥协商-包裹模式下，Concat KDF 输出密钥长度必须满足指定包裹算法要求，JWE加密密钥为用协商得密钥包裹的CEK。
下述"alg"参数表示JWE加密密钥由密钥协商算法结果作为包装算法的密钥加密CEK所得：
+-----------------+-------------------------------------------------+
| "alg"参数 | 密钥管理算法 |
| 值 | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | ECDH-ES结合 Concat KDF，用"A128KW"包裹CEK |
| ECDH-ES+A192KW | ECDH-ES结合 Concat KDF，用"A192KW"包裹CEK |
| ECDH-ES+A256KW | ECDH-ES结合 Concat KDF，用"A256KW"包裹CEK |
+-----------------+-------------------------------------------------+
4.6.1. ECDH密钥协商相关头部参数
下列头部参数用于密钥协商，具体说明如下。
4.6.1.1. "epk"（临时公钥）头部参数
"epk"（临时公钥）为发起方用于密钥协商算法而生成的值。
该密钥以JSON Web Key [JWK]公钥形式表示。其内容必须仅包含公钥参数，
且应仅含能表示该密钥的最小JWK参数；包含其他JWK参数时，可校验并采用，也可忽略。
使用这些算法时，该头部参数必须存在且必须被实现正确处理。
Jones Standards Track [Page 16]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.6.1.2. "apu"（PartyUInfo 协议参与方U信息）头部参数
"apu"（PartyUInfo 协议参与方信息）用于对应密钥协商算法（如"ECDH-ES"），以base64url 编码字符串表示。
如使用，PartyUInfo值包含有关生产者的信息。
是否使用此头参数可选。使用这些算法时，该参数必须能被实现正确理解和处理。
4.6.1.3. "apv"（PartyVInfo 协议参与方V信息）头部参数
"apv"（PartyVInfo 协议参与方信息）用于对应密钥协商算法（如"ECDH-ES"），以base64url 编码字符串表示。
如使用，PartyVInfo值包含有关接收者的信息。
是否使用此头参数可选。使用这些算法时，该参数必须能被实现正确理解和处理。
4.6.2. ECDH密钥协商的密钥派生
派生过程根据ECDH算法建立的共享密钥Z所得密钥，见[NIST.800-56A]第6.2.2.2节。
密钥派生用Concat KDF，参见[NIST.800-56A]第5.8.1节，摘要算法使用SHA-256。
其参数如下：
Z
设置为共享密钥Z对应的字节序列。
keydatalen
设置为期望输出密钥的比特数。
"ECDH-ES"时为"enc"算法密钥长度；
"ECDH-ES+A128KW"、"ECDH-ES+A192KW"、"ECDH-ES+A256KW"时分别为128、192、256。
AlgorithmID
形式为Datalen || Data。Data是零个或多个字节的变长字符串，
Datalen为4字节大端整数，指Data的长度（字节数）。
直接协商时Data取"enc"头参数ASCII字节，包裹模式时Data取"alg"头参数ASCII字节。
Jones Standards Track [Page 17]
RFC 7518 JSON Web Algorithms (JWA) May 2015
PartyUInfo
形式为Datalen || Data。Data为变长字符串，Datalen为4字节大端整数，指Data长度。
存在"apu"头参数时Data为其base64url解码结果，Datalen为字节数。
否则Datalen为0，Data为空串。
PartyVInfo
形式为Datalen || Data。Data为变长字符串，Datalen为4字节大端整数，指Data长度。
存在"apv"头参数时Data为其base64url解码结果，Datalen为字节数。
否则Datalen为0，Data为空串。
SuppPubInfo
为keydatalen的4字节大端表示。
SuppPrivInfo
为空串。
应用需要定义"apu"和"apv"头部参数在本应用中的用法。如使用，这两个值必须不同。
希望遵循[NIST.800-56A]的应用应使用能标识生产者和消费者的参数值，
或以类似[RFC2631] "Diffie-Hellman密钥协商方法"的方式做派生——
此时"apu"可省略或用作512位随机值（类似于临时-静态模式的PartyAInfo），
且"apv"参数应避免出现。
此方法的密钥协商例子见附录C。
4.7. 用AES GCM加密密钥
本节定义了用高级加密标准（AES）伽罗华/计数器模式（GCM）（[AES]与[NIST.800-38D]）加密JWE内容加密密钥（CEK）的细节。
Jones Standards Track [Page 18]
RFC 7518 JSON Web Algorithms (JWA) May 2015
本算法要求使用长度为96位的初始化向量(IV)。IV以base64url编码的形式，作为“iv”(初始化向量)头参数值表示。
额外认证数据的值为一个空的八位字节串。
认证标签输出的要求大小为128位，无论密钥长度如何都必须如此。
JWE加密密钥值为密文输出。
认证标签输出以base64url编码形式作为“tag”(认证标签)头参数值表示。
下列“alg”(算法)头参数值用于指示JWE加密密钥是通过使用对应算法和密钥长度加密CEK所得的结果：
+-------------------+---------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+-------------------+---------------------------------------------+
| A128GCMKW | 使用128位密钥的AES GCM密钥封装 |
| A192GCMKW | 使用192位密钥的AES GCM密钥封装 |
| A256GCMKW | 使用256位密钥的AES GCM密钥封装 |
+-------------------+---------------------------------------------+
4.7.1. 用于AES GCM密钥加密的头参数
以下头参数用于AES GCM密钥加密。
4.7.1.1. "iv"(初始化向量)头参数
“iv”(初始化向量)头参数的值是用于密钥加密操作的96位IV值的base64url编码表示。使用这些算法时，该头参数必须存在，并且必须被实现理解并处理。
4.7.1.2. "tag"(认证标签)头参数
“tag”(认证标签)头参数的值是密钥加密操作所得的128位认证标签值的base64url编码表示。使用这些算法时，该头参数必须存在，并且必须被实现理解与处理。
Jones Standards Track [Page 19]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8. 使用PBES2进行密钥加密
本节定义了如何对JWE CEK进行基于密码的加密，首先使用[RFC2898]第6.2节规定的PBES2方案，从用户提供的密码派生出密钥加密密钥，然后用派生密钥加密JWE CEK。
这些算法在PBKDF2密钥派生中使用HMAC SHA-2算法作为伪随机函数(PRF)，加密方案使用AES密钥封装[RFC3394]。PBES2的密码输入为八位字节序列；如果待用密码以文本字符串表示，而不是八位字节序列，则必须将文本字符串进行UTF-8编码后作为八位字节序列使用。盐参数必须按下文“p2s”定义所述，从“p2s”(PBES2盐输入)头参数值与“alg”(算法)头参数值计算得到。迭代次数参数必须以“p2c”(PBES2计数)头参数值提供。这些算法分别使用HMAC SHA-256、HMAC SHA-384和HMAC SHA-512作为PRF并使用128、192和256位AES密钥封装密钥。它们的派生密钥长度分别为16、24和32个八位字节。
下列“alg”(算法)头参数值，表明JWE加密密钥是采用对应的基于密码的加密算法结果作为密钥加密密钥，对应密钥封装算法加密CEK所得的结果：
+--------------------+----------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+--------------------+----------------------------------------------+
| PBES2-HS256+A128KW | PBES2与HMAC SHA-256及“A128KW”封装 |
| | |
| PBES2-HS384+A192KW | PBES2与HMAC SHA-384及“A192KW”封装 |
| | |
| PBES2-HS512+A256KW | PBES2与HMAC SHA-512及“A256KW”封装 |
| | |
+--------------------+----------------------------------------------+
参见JWK规范附录C[JWK]，了解使用“PBES2-HS256+A128KW”进行密钥加密计算的示例。
4.8.1. PBES2密钥加密的头参数
下列头参数用于PBES2密钥加密。
Jones Standards Track [Page 20]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8.1.1. "p2s"(PBES2盐输入)头参数
“p2s”(PBES2盐输入)头参数编码了一个盐输入值，用作PBKDF2盐值的一部分。“p2s”值为BASE64URL(Salt Input)。使用这些算法时，该头参数必须存在，并且必须被实现理解并处理。
盐值增大了由给定密码能派生出的密钥空间。所用盐输入值必须包含8个或更多八位字节。每次加密操作都必须随机生成一个新的盐输入值；关于生成随机值的考量，参见RFC 4086[RFC4086]。所用的盐值为(UTF8(Alg) || 0x00 || Salt Input)，其中Alg为“alg”(算法)头参数值。
4.8.1.2. "p2c"(PBES2计数)头参数
“p2c”(PBES2计数)头参数包含PBKDF2迭代次数，以正的JSON整数形式表示。使用这些算法时，该头参数必须存在，并且必须被实现理解与处理。
迭代次数增加了计算消耗，且理想情况下能与盐带来的密钥范围共同发挥作用。建议最小迭代次数为1000。
5. 内容加密的加密算法
JWE使用加密算法对明文进行加密和完整性保护，并对额外认证数据进行完整性保护。
Jones Standards Track [Page 21]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.1. JWE使用的“enc”(加密算法)头参数值
下表展示了本规范定义的、可用于JWE的“enc”(加密算法)头参数值。
+---------------+----------------------------------+----------------+
| "enc" Param | Content Encryption Algorithm | Implementation |
| Value | | Requirements |
+---------------+----------------------------------+----------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | 必须 |
| | 认证加密算法，见第5.2.3节 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | 可选 |
| | 认证加密算法，见第5.2.4节 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | 必须 |
| | 认证加密算法，见第5.2.5节 | |
| A128GCM | 使用128位密钥的AES GCM | 推荐 |
| A192GCM | 使用192位密钥的AES GCM | 可选 |
| A256GCM | 使用256位密钥的AES GCM | 推荐 |
+---------------+----------------------------------+----------------+
所有算法还使用JWE初始化向量值，产生JWE密文及JWE认证标签值。
参见附录A.3，可对比本规范定义的JWE“enc”(加密算法)值与其他标准和软件包中等价标识符的对应关系。
5.2. AES_CBC_HMAC_SHA2算法
本节定义了一组经过认证的加密算法，这些算法由AES [AES] 分组链接(CBC)模式 [NIST.800-38A]、按[RFC5652]第6.3节执行的PKCS #7 填充操作，以及HMAC ([RFC2104]和[SHS])组成。该算法家族称为 AES_CBC_HMAC_SHA2。本节还定义了此家族的三种实现：第一种使用128位CBC密钥和HMAC SHA-256，第二种使用192位CBC密钥和HMAC SHA-384，第三种使用256位CBC密钥和HMAC SHA-512。这些算法的测试用例见附录B。
Jones Standards Track [Page 22]
RFC 7518 JSON Web Algorithms (JWA) May 2015
这些算法基于“Authenticated Encryption with AES-CBC and HMAC-SHA”[AEAD-CBC-SHA]，执行相同的加密操作，但初始化向量(IV)和认证标签值在输出表示中保持为独立字段，而非与密文拼接在一起。该选项见该规范附录B。这一算法家族是[AEAD-CBC-SHA]中算法家族的泛化，可用以实现这些算法。
5.2.1. 定义AES_CBC_HMAC_SHA2所用约定
我们采用如下记号约定。
CBC-PKCS7-ENC(X, P) 表示使用密钥X和PKCS#7填充对P进行AES-CBC加密。
MAC(Y, M) 表示使用密钥Y对消息M应用MAC。
5.2.2. 通用AES_CBC_HMAC_SHA2算法
本节以独立于AES-CBC密钥长度或散列函数的方式定义AES_CBC_HMAC_SHA2。第5.2.2.1节和5.2.2.2节定义了通用的加密与解密算法。第5.2.3节至5.2.5节指定了这些算法的具体实例。
5.2.2.1. AES_CBC_HMAC_SHA2加密
认证加密算法输入为四个八位字节串：密钥K、明文P、额外认证数据A，以及初始化向量IV。输出为认证密文E和认证标签T。明文中的数据既被加密又被认证，额外认证数据只被认证不被加密。
加密过程如下，也可采用等价步骤：
1. 从输入密钥K生成二级密钥MAC_KEY和ENC_KEY。二者均为八位字节串。
MAC_KEY由K的前MAC_KEY_LEN个八位字节组成，按顺序；
ENC_KEY由K的后ENC_KEY_LEN个八位字节组成，按顺序。
Jones Standards Track [Page 23]
RFC 7518 JSON Web Algorithms (JWA) May 2015
输入密钥K的八位字节数必须等于MAC_KEY_LEN与ENC_KEY_LEN之和。这些参数的值由第5.2.3节至5.2.5节的认证加密算法指定。需注意，MAC密钥排在加密密钥前面，这与算法标识符“AES_CBC_HMAC_SHA2”中名字的顺序相反。
2. 所使用的IV为128位值，需随机或伪随机生成。
3. 使用ENC_KEY做密钥和IV，对明文进行CBC加密及PKCS#7填充。此步骤的密文输出记作E。
4. 八位字节串AL等于A的比特数，以64位无符号大端整数表示。
5. 通过对如下数据顺序使用HMAC[RFC2104]，计算消息认证标签T：
额外认证数据A，
初始化向量IV，
上一步的密文E，
以及如上定义的AL。
MAC_KEY作为MAC的密钥。本步骤所计算MAC的输出记作M。M的前T_LEN个八位字节用作T。
6. 返回密文E和认证标签T作为认证加密的输出。
加密过程可如下图示。K、P、A、IV和E分别表示密钥、明文、额外认证数据、初始化向量和密文：
MAC_KEY = K的前MAC_KEY_LEN个八位字节
ENC_KEY = K的后ENC_KEY_LEN个八位字节
E = CBC-PKCS7-ENC(ENC_KEY, P)
M = MAC(MAC_KEY, A || IV || E || AL)
T = M的前T_LEN个八位字节
Jones Standards Track [Page 24]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.2.2.2. AES_CBC_HMAC_SHA2解密
认证解密操作有五个输入：如上定义的K、A、IV、E与T。输出仅为一个明文值P或特殊标记FAIL，后者表示输入未通过认证。认证解密算法如下，也可采用等价步骤：
1. 如第5.2.2.1节的步骤1，从输入密钥K生成MAC_KEY和ENC_KEY。
2. 通过如第5.2.2.1节的步骤5计算HMAC，校验A和E的完整性及真实性，T值与HMAC输出的前MAC_KEY长度位进行比较。如果一致，则A和E被视为有效，继续处��。否则，丢弃参加MAC校验的所有数据，认证解密操作返回失败的通知，操作终止。(防御计时攻击的安全考虑，见[JWE]第11.5节)
3. 对E进行解密，并校验与移除PKCS#7填充。IV用作初始化向量，ENC_KEY用作解密密钥。
4. 返回明文值。
5.2.3. AES_128_CBC_HMAC_SHA_256
此算法是前述通用AES_CBC_HMAC_SHA2算法的具体实现。它使用HMAC消息验证码[RFC2104]及SHA-256散列函数[SHS]进行消息认证，HMAC输出截断为128位，对应HMAC-SHA-256-128算法[RFC4868]。加密使用AES的CBC模式(见[NIST.800-38A]第6.2节)，并采用PKCS#7填充及128位IV值。
AES_CBC_HMAC_SHA2针对AES_128_CBC_HMAC_SHA_256的参数如下：
输入密钥K为32个八位字节
ENC_KEY_LEN为16个八位字节
MAC_KEY_LEN为16个八位字节
HMAC采用SHA-256散列算法
HMAC-SHA-256输出截断为T_LEN=16个八位字节，仅保留前16个八位字节
Jones Standards Track [Page 25]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.2.4. AES_192_CBC_HMAC_SHA_384
AES_192_CBC_HMAC_SHA_384 基于 AES_128_CBC_HMAC_SHA_256，
但有如下不同：
输入密钥K长度为48个八位字节，而非32。
ENC_KEY_LEN为24个八位字节，而非16。
HMAC使用SHA-384算法，而非SHA-256。
MAC_KEY_LEN为24个八位字节，而非16。
HMAC SHA-384输出截断为T_LEN=24个八位字节，而非16。
5.2.5. AES_256_CBC_HMAC_SHA_512
AES_256_CBC_HMAC_SHA_512 基于 AES_128_CBC_HMAC_SHA_256，
但有如下不同：
输入密钥 K 为 64 字节，而不是 32 字节。
ENC_KEY_LEN 为 32 字节，而不是 16 字节。
MAC_KEY_LEN 为 32 字节，而不是 16 字节。
HMAC 采用 SHA-512，而不是 SHA-256。
HMAC SHA-512 截断为 T_LEN=32 字节，而不是 16 字节。
5.2.6. 用 AES_CBC_HMAC_SHA2 进行内容加密
本节定义了使用 AES_CBC_HMAC_SHA2 算法进行认证加密的具体细节。
CEK 用作密钥 K。
下述 "enc"（加密算法）头部参数用于表示 JWE 密文和 JWE 认证标签值是用对应算法计算得出：
+---------------+---------------------------------------------------+
| "enc" 参数 | 内容加密算法 |
| 值 | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 认证加密算法，见 第5.2.3节 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 认证加密算法，见 第5.2.4节 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 认证加密算法，见 第5.2.5节 |
+---------------+---------------------------------------------------+
Jones Standards Track [Page 26]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.3. 用 AES GCM 进行内容加密
本节定义了用 AES 在伽罗瓦/计数器模式（GCM）（[AES] 和
[NIST.800-38D]）下执行认证加密的细节。
CEK 用作加密密钥。
此算法要求使用 96 位的 IV。
认证标签输出的长度必须为 128 位，与密钥长度无关。
下述 "enc"（加密算法）头部参数用于表示 JWE 密文和 JWE 认证标签值是用相应算法和密钥长度计算得出：
+-------------------+------------------------------+
| "enc" 参数 | 内容加密算法 |
+-------------------+------------------------------+
| A128GCM | AES GCM，128位密钥 |
| A192GCM | AES GCM，192位密钥 |
| A256GCM | AES GCM，256位密钥 |
+-------------------+------------------------------+
使用该算法的示例见 [JWE] 的 附录A.1。
6. 密钥的密码算法
JSON Web Key (JWK) [JWK] 是一种表示密码密钥的 JSON 数据结构。
这些密钥可以是对称的，也可以是非对称的。
它们可以包含密钥的公钥和私钥信息。
本节定义了采用本文算法的密钥参数。
Jones Standards Track [Page 27]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.1. "kty"（密钥类型）参数取值
下表为本规范为 JWK 定义的 "kty"（密钥类型）参数取值。
+-------------+--------------------------------+--------------------+
| "kty" 参数 | 密钥类型 | 实现要求 |
| 值 | | |
+-------------+--------------------------------+--------------------+
| EC | 椭圆曲线 [DSS] | 推荐+ |
| RSA | RSA [RFC3447] | 必须实现 |
| oct | 字节序列（用于表示对称密钥） | 必须实现 |
+-------------+--------------------------------+--------------------+
实现要求栏中的“+”表示该项要求强度在将来版本中很可能提高。
6.2. 椭圆曲线密钥的参数
JWK 可用于表示椭圆曲线 [DSS] 密钥。
此时 "kty" 成员值为 "EC"。
6.2.1. 椭圆曲线公钥的参数
椭圆曲线公钥通过从有限域选取的一对坐标表示，该对坐标共同定义曲线上的点。
下列成员对所有椭圆曲线公钥必须存在：
o "crv"
o "x"
对于下一节定义的三种曲线，椭圆曲线公钥还必须包含下列成员：
o "y"
6.2.1.1. "crv"（曲线）参数
"crv"（曲线）参数标识与密钥配合使用的密码曲线。
本规范采用的曲线值来自 [DSS]：
o "P-256"
o "P-384"
o "P-521"
Jones Standards Track [Page 28]
RFC 7518 JSON Web Algorithms (JWA) May 2015
这些值在 第7.6节 所定义的 IANA “JSON Web Key Elliptic Curve”
注册表中注册。其它规范可注册新的“crv”值。注册新曲线的规范必须定义用于表示所注册曲线密钥的参数。
"crv" 值区分大小写。
SEC1 [SEC1] 点压缩在这三种曲线上均不支持。
6.2.1.2. "x"（X 坐标）参数
"x"（x坐标）参数包含椭圆曲线点的 x 坐标。
其表示为该坐标字节序列的 base64url 编码，见 SEC1 第2.3.5节 [SEC1]。
该字节序列长度必须为“crv”参数所指定曲线的坐标完整字节长度。例如如果“crv”为“P-521”，则字节串为66字节。
6.2.1.3. "y"（Y 坐标）参数
"y"（y坐标）参数包含椭圆曲线点的 y 坐标。
其表示为该坐标字节序列的 base64url 编码，见 SEC1 第2.3.5节 [SEC1]。
该字节序列长度必须为“crv”参数所指定曲线的坐标完整字节长度。例如如果“crv”为“P-521”，则字节串为66字节。
6.2.2. 椭圆曲线私钥的参数
除了用于表示椭圆曲线公钥的成员外，下列成员用于表示椭圆曲线私钥时必须存在。
6.2.2.1. "d"（ECC 私钥）参数
"d"（ECC 私钥）参数包含椭圆曲线的私钥值。
它表示为该私钥值的字节序列的 base64url 编码，见 SEC1 第2.3.7节 [SEC1]。
该字节序列长度必须为 ceiling(log-base-2(n)/8) 字节（n为曲线阶）。
Jones Standards Track [Page 29]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3. RSA 密钥的参数
JWK 可用于表示 RSA [RFC3447] 密钥。
此时 "kty" 成员值为 "RSA"。
下列参数的语义与 RFC 3447 第 3.1 和 3.2 节所定义一致。
6.3.1. RSA 公钥参数
下列成员为 RSA 公钥时必须存在。
6.3.1.1. "n"（模数）参数
"n"（模数）参数包含 RSA 公钥的模数值。
表示为 Base64urlUInt 编码值。
注意，有些加密库会在模数前加上一个��余的零字节（如2048位密钥返回257字节而不是256字节），
实现时需去掉多余字节再 base64url 编码。
6.3.1.2. "e"（指数）参数
"e"（指数）参数包含 RSA 公钥的指数值。
表示为 Base64urlUInt 编码值。
例如，值65537，参与编码的字节序列为[1, 0, 1]，编码结果为 "AQAB"。
6.3.2. RSA 私钥参数
除了表示 RSA 公钥的成员外，下列成员用于表示 RSA 私钥。
"d" 参数为 RSA 私钥必须提供。其余用于优化，若 JWK 生产者提供其中任意一项，则其它都必须也提供（
除了"oth"，它只在有超过两个素数因子的情况下出现）。
6.3.2.1. "d"（私有指数）参数
"d"（私有指数）参数包含 RSA 私钥的私有指数值。
表示为 Base64urlUInt 编码值。
Jones Standards Track [Page 30]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3.2.2. "p"（第一素数因子）参数
"p"（第一素数因子）参数包含第一个素数因子。
表示为 Base64urlUInt 编码值。
6.3.2.3. "q"（第二素数因子）参数
"q"（第二素数因子）参数包含第二素数因子。
表示为 Base64urlUInt 编码值。
6.3.2.4. "dp"（第一因子的CRT指数）参数
"dp"（第一因子的CRT指数）参数包含第一因子的中国剩余定理（CRT）指数。
表示为 Base64urlUInt 编码值。
6.3.2.5. "dq"（第二因子的CRT指数）参数
"dq"（第二因子的CRT指数）参数包含第二因子的CRT指数。
表示为 Base64urlUInt 编码值。
6.3.2.6. "qi"（第一CRT系数）参数
"qi"（第一CRT系数）参数包含第二因子的CRT系数。
表示为 Base64urlUInt 编码值。
6.3.2.7. "oth"（其它素数因子信息）参数
"oth"（其它素数因子信息）参数包含关于第三及后续素数因子的数组信息（如存在）。
仅用两个素数时（常见情况）该参数必须省略。大于两个素数时，数组长度为素数数减2。
详情见 RFC 3447附录A.1.2 描述。下述参数仿此设计。
如果JWK消费者不支持带超两素数私钥，遇有"oth"参数的密钥则不得使用。
每个数组元素须为包含如下成员的对象。
6.3.2.7.1. "r"（素数因子）
"oth"成员的"r"（素数因子）参数表示后续素数因子的值。
表示为 Base64urlUInt 编码值。
Jones Standards Track [Page 31]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3.2.7.2. "d"（因子CRT指数）
"oth"成员的"d"（因子CRT指数）参数表示对应素数因子的CRT指数。
表示为 Base64urlUInt 编码值。
6.3.2.7.3. "t"（因子CRT系数）
"oth"成员的"t"（因子CRT系数）参数表示对应素数因子的CRT系数。
表示为 Base64urlUInt 编码值。
6.4. 对称密钥参数
JWK 的 "kty" 成员值为 "oct"（字节序列）时，"k"（见 第6.4.1节）用于表示对称密钥（或值为单一字节序列的其他密钥）。
应该同时有 "alg" 成员标识密钥拟使用的算法，除非应用有其他方式或约定来确定实际使用的算法。
6.4.1. "k"（密钥值）参数
"k"（密钥值）参数包含对称（或其他单值型）密钥的数值。
表示为包含密钥值的字节序列的 base64url 编码。
7. IANA 事项
本规范建立的所有注册表都采用如下注册流程。
值的注册流程为规范要求型 [RFC5226]，须先在 jose-reg-review@ietf.org 邮件列表审核三周，由一名或多名指定专家给出建议。
但为支持规范发布前分配，指定专家如满意可先批准。
发送注册请求到邮件列表时主题应有明确标识，如“Request to register algorithm: example”。
审核期内，指定专家应批准或否决请求，并告知列表及IANA。
否决时应说明理由且如有建议也应一并告之。
Jones Standards Track [Page 32]
RFC 7518 JSON Web Algorithms (JWA) May 2015
注册请求如超过21天无结论，可报告给 IESG（iesg@ietf.org 邮件列表）由其裁决。
指定专家评审标准包括：是否与现有功能重复、是否有广泛适用性或仅用于单一应用、注册描述是否清晰等。
IANA 只接受指定专家的注册表更新，应将请求导向审核邮件列表。
建议指定多名专家，能代表不同实际应用的视角，使注册决策更具广泛性。
某位专家如与具体注册有利益冲突，应尊重他人专家的决定。
7.1. JSON Web Signature 和加密算法注册表
本规范为 JWS 和 JWE 的 "alg"（算法）与 "enc"（加密算法）头部参数建立 IANA“JSON Web Signature and Encryption Algorithms”注册表。
注册表包含算法名称、算法描述、使用场景、实现要求、变更控制方以及规范引用信息。
同一算法名如作用范围不同，可多次注册，但用法集需彼此不交叉。
若注册多个使用不同密钥长度且需固定密钥长度的算法，建议在算法名中含密钥长度（如由密钥派生函数生成）。
这样方便读取 JSON 文本时做安全决策。
指定专家应合理审查注册算法是否被认为在密码学上可靠，或需标记为 Deprecated 或 Prohibited。
Jones Standards Track [Page 33]
RFC 7518 JSON Web Algorithms (JWA) May 2015
随着密码生态变化，算法的实现要求可能调整，如将算法状态变成 Deprecated，或从 Optional 升为 Recommended+/Required。
实现要求变更仅能由规范要求型流程在指定专家审核后进行，新规范应明确新的实现要求等级。
7.1.1. 注册模板
算法名称：
请求注册的名称（如"HS256"）。区分大小写的ASCII字符串。除非指定专家明确理由，否则名称不得与现有注册项仅大小写不同。
算法描述：
算法的简要描述（如“HMAC using SHA-256”）。
算法使用场景：
算法用法位置，需为"alg"或"enc"之一或两者。如仅作JWK"alg"成员，而不用作JWS/JWE，则可用"JWK"（如非认证加密算法）。其他用法需指定专家同意。
JOSE实现要求：
算法在JWS、JWE中的实现要求，只能为Required、Recommended、Optional、Deprecated、Prohibited之一，可选加后缀“+”或“-”。
“+”表示未来要求力度可能提升，“-”表示可能降低。非认证加密或其它不适合作JWS/JWE算法的标识符，必须注册为"Prohibited"。
变更控制方：
标准RFC注明“IESG”。其他情况写明责任方，其他细节（如地址、邮件、主页URI）可选。
Jones Standards Track [Page 34]
RFC 7518 JSON Web Algorithms (JWA) May 2015
规范文档：
算法参数所对应的文档引用，最好含可检索到文档副本的URI。可标注相关章节，但不是必须。
算法分析文献：
公开密码学会议、国家标准机构或其他权威分析该算法安全性的出版物引用。除非注册为Deprecated或Prohibited，指定专家可据情要求提供算法安全性证据。
经工作组及IETF审查，本文件登记的初始注册无须另行提供分析信息。
7.1.2. 初始注册表内容
o 算法名称: "HS256"
o 算法描述: HMAC using SHA-256
o 算法使用场景: "alg"
o JOSE实现要求: Required
o 变更控制方: IESG
o 规范文档: RFC 7518第3.2节
o 算法分析文献: n/a
o 算法名称: "HS384"
o 算法描述: HMAC using SHA-384
o 算法使用场景: "alg"
o JOSE实现要求: Optional
o 变更控制方: IESG
o 规范文档: RFC 7518第3.2节
o 算法分析文献: n/a
o 算法名称: "HS512"
o 算法描述: HMAC using SHA-512
o 算法使用场景: "alg"
o JOSE实现要求: Optional
o 变更控制方: IESG
o 规范文档: RFC 7518第3.2节
o 算法分析文献: n/a
Jones Standards Track [Page 35]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "RS256"
o 算法描述: 使用 SHA-256 的 RSASSA-PKCS1-v1_5
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.3 节
o 算法分析文档: n/a
o 算法名称: "RS384"
o 算法描述: 使用 SHA-384 的 RSASSA-PKCS1-v1_5
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.3 节
o 算法分析文档: n/a
o 算法名称: "RS512"
o 算法描述: 使用 SHA-512 的 RSASSA-PKCS1-v1_5
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.3 节
o 算法分析文档: n/a
o 算法名称: "ES256"
o 算法描述: 使用 P-256 和 SHA-256 的 ECDSA
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended+
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.4 节
o 算法分析文档: n/a
o 算法名称: "ES384"
o 算法描述: 使用 P-384 和 SHA-384 的 ECDSA
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.4 节
o 算法分析文档: n/a
o 算法名称: "ES512"
o 算法描述: 使用 P-521 和 SHA-512 的 ECDSA
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.4 节
o 算法分析文档: n/a
Jones Standards Track [Page 36]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "PS256"
o 算法描述: 使用 SHA-256 和 MGF1（
SHA-256）的 RSASSA-PSS
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.5 节
o 算法分析文档: n/a
o 算法名称: "PS384"
o 算法描述: 使用 SHA-384 和 MGF1（
SHA-384）的 RSASSA-PSS
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.5 节
o 算法分析文档: n/a
o 算法名称: "PS512"
o 算法描述: 使用 SHA-512 和 MGF1（
SHA-512）的 RSASSA-PSS
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.5 节
o 算法分析文档: n/a
o 算法名称: "none"
o 算法描述: 不进行数字签名或 MAC
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 3.6 节
o 算法分析文档: n/a
o 算法名称: "RSA1_5"
o 算法描述: RSAES-PKCS1-v1_5
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended-
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.2 节
o 算法分析文档: n/a
Jones Standards Track [Page 37]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "RSA-OAEP"
o 算法描述: 使用默认参数的 RSAES OAEP
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended+
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.3 节
o 算法分析文档: n/a
o 算法名称: "RSA-OAEP-256"
o 算法描述: 使用 SHA-256 和 MGF1（SHA-256）的 RSAES OAEP
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.3 节
o 算法分析文档: n/a
o 算法名称: "A128KW"
o 算法描述: 使用 128 位密钥的 AES 密钥包装
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.4 节
o 算法分析文档: n/a
o 算法名称: "A192KW"
o 算法描述: 使用 192 位密钥的 AES 密钥包装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.4 节
o 算法分析文档: n/a
o 算法名称: "A256KW"
o 算法描述: 使用 256 位密钥的 AES 密钥包装
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.4 节
o 算法分析文档: n/a
o 算法名称: "dir"
o 算法描述: 直接使用共享对称密钥
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.5 节
o 算法分析文档: n/a
Jones Standards Track [Page 38]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "ECDH-ES"
o 算法描述: 使用 Concat KDF 的 ECDH-ES
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended+
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.6 节
o 算法分析文档: n/a
o 算法名称: "ECDH-ES+A128KW"
o 算法描述: 使用 Concat KDF 的 ECDH-ES，并使用 "A128KW"
进行封装
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.6 节
o 算法分析文档: n/a
o 算法名称: "ECDH-ES+A192KW"
o 算法描述: 使用 Concat KDF 的 ECDH-ES，并使用 "A192KW"
进行封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.6 节
o 算法分析文档: n/a
o 算法名称: "ECDH-ES+A256KW"
o 算法描述: 使用 Concat KDF 的 ECDH-ES，并使用 "A256KW"
进行封装
o 算法使用位置: "alg"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.6 节
o 算法分析文档: n/a
o 算法名称: "A128GCMKW"
o 算法描述: 使用 128 位密钥的 AES GCM 密钥封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.7 节
o 算法分析文档: n/a
Jones Standards Track [Page 39]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "A192GCMKW"
o 算法描述: 使用 192 位密钥的 AES GCM 密钥封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.7 节
o 算法分析文档: n/a
o 算法名称: "A256GCMKW"
o 算法描述: 使用 256 位密钥的 AES GCM 密钥封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.7 节
o 算法分析文档: n/a
o 算法名称: "PBES2-HS256+A128KW"
o 算法描述: PBES2，配合 HMAC SHA-256 和 "A128KW"
封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.8 节
o 算法分析文档: n/a
o 算法名称: "PBES2-HS384+A192KW"
o 算法描述: PBES2，配合 HMAC SHA-384 和 "A192KW"
封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.8 节
o 算法分析文档: n/a
o 算法名称: "PBES2-HS512+A256KW"
o 算法描述: PBES2，配合 HMAC SHA-512 和 "A256KW"
封装
o 算法使用位置: "alg"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 4.8 节
o 算法分析文档: n/a
Jones Standards Track [Page 40]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o 算法名称: "A128CBC-HS256"
o 算法描述: AES_128_CBC_HMAC_SHA_256 认证加密算法
o 算法使用位置: "enc"
o JOSE 实现要求: Required
o 变更控制者: IESG
o 规范文档: RFC 7518 第 5.2.3 节
o 算法分析文档: n/a
o 算法名称: "A192CBC-HS384"
o 算法描述: AES_192_CBC_HMAC_SHA_384 认证加密算法
o 算法使用位置: "enc"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 5.2.4 节
o 算法分析文档: n/a
o 算法名称: "A256CBC-HS512"
o 算法描述: AES_256_CBC_HMAC_SHA_512 认证加密算法
o 算法使用位置: "enc"
o JOSE 实现要求: Required
o 变更控制者: IESG
o 规范文档: RFC 7518 第 5.2.5 节
o 算法分析文档: n/a
o 算法名称: "A128GCM"
o 算法描述: 使用 128 位密钥的 AES GCM
o 算法使用位置: "enc"
o JOSE 实现要求: Recommended
o 变更控制者: IESG
o 规范文档: RFC 7518 第 5.3 节
o 算法分析文档: n/a
o 算法名称: "A192GCM"
o 算法描述: 使用 192 位密钥的 AES GCM
o 算法使用位置: "enc"
o JOSE 实现要求: Optional
o 变更控制者: IESG
o 规范文档: RFC 7518 第 5.3 节
o 算法分析文档: n/a
Jones Standards Track [Page 41]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Algorithm Name: "A256GCM"
o Algorithm Description: 使用 256 位密钥的 AES GCM
o Algorithm Usage Location(s): "enc"
o JOSE Implementation Requirements: Recommended
o Change Controller: IESG
o Specification Document(s): Section 5.3 of RFC 7518
o Algorithm Analysis Documents(s): n/a
7.2. 头部参数名称注册
This section registers the Header Parameter names defined in Sections
4.6.1, 4.7.1, and 4.8.1 of this specification in the IANA "JSON Web
Signature and Encryption Header Parameters" registry established by
[JWS].
7.2.1. 注册内容
o Header Parameter Name: "epk"
o Header Parameter Description: 临时公钥
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.6.1.1 of RFC 7518
o Header Parameter Name: "apu"
o Header Parameter Description: 协议方 U 信息 (Agreement PartyUInfo)
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.6.1.2 of RFC 7518
o Header Parameter Name: "apv"
o Header Parameter Description: 协议方 V 信息 (Agreement PartyVInfo)
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.6.1.3 of RFC 7518
o Header Parameter Name: "iv"
o Header Parameter Description: 初始化向量
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.7.1.1 of RFC 7518
o Header Parameter Name: "tag"
o Header Parameter Description: 认证标签
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.7.1.2 of RFC 7518
Jones Standards Track [Page 42]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Header Parameter Name: "p2s"
o Header Parameter Description: PBES2 盐输入
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.8.1.1 of RFC 7518
o Header Parameter Name: "p2c"
o Header Parameter Description: PBES2 计数
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.8.1.2 of RFC 7518
7.3. JSON Web 加密（JWE）压缩算法注册表
本规范为 JWE 的 "zip" 成员值建立了 IANA "JSON Web Encryption
Compression Algorithms" 注册表。该注册表记录压缩算法值及其
所定义规范的参考。
7.3.1. 注册模板
Compression Algorithm Value:
请求的名称（例如，“DEF”）。因为本规范的核心目标之一是
使产生的表示尽可能紧凑，建议名称较短——除非有充分理由，
否则不应超过 8 个字符。该名称区分大小写。除非指定专家组
认为有充分理由允许例外，否则名称不得在不区分大小写的情
况下匹配其他已注册名称。
Compression Algorithm Description:
压缩算法的简要描述（例如，“DEFLATE”）。
Change Controller:
对于标准轨道 RFC，填列“IESG”。对于其他类型，给出负责
方的名称。也可包括其他细节（例如邮寄地址、电子邮件地
址、主页 URI）。
Specification Document(s):
指定参数的文档参考，最好包括可用于检索文档副本的 URI。
也可包括相关章节指示，但并非必须。
Jones Standards Track [Page 43]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.3.2. 初始注册内容
o Compression Algorithm Value: "DEF"
o Compression Algorithm Description: DEFLATE
o Change Controller: IESG
o Specification Document(s): JSON Web Encryption (JWE) [JWE]
7.4. JSON Web 密钥类型注册表
本规范为 JWK 的 "kty"（密钥类型）参数的取值建立了 IANA
"JSON Web Key Types" 注册表。该注册表记录 "kty" 值、实现要
求及其定义规范的参考。
随着密码学环境的发展，密钥类型的实现要求可能随时间变化，
例如将某种密钥类型的状态更改为弃用（Deprecated），或将某
种密钥类型的状态从可选更改为推荐+或必需。实现要求的更改只
能在指定专家审核后以“需要规范（Specification Required）”
的方式进行，新规范应定义修订后的实现要求级别。
7.4.1. 注册模板
"kty" Parameter Value:
请求的名称（例如，“EC”）。因为本规范的核心目标之一是
使产生的表示尽可能紧凑，建议名称较短——除非有充分理由，
否则不应超过 8 个字符。该名称区分大小写。除非指定专家组
认为有充分理由允许例外，否则名称不得在不区分大小写的情
况下匹配其他已注册名称。
Key Type Description:
密钥类型的简要描述（例如，“椭圆曲线”）。
Change Controller:
对于标准轨道 RFC，填列“IESG”。对于其他类型，给出负责
方的名称。也可包括其他细节（例如邮寄地址、电子邮件地
址、主页 URI）。
Jones Standards Track [Page 44]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JOSE Implementation Requirements:
针对 JWS 和 JWE 的密钥类型实现要求，取值必须为下列单词之
一：Required、Recommended、Optional、Deprecated 或 Prohibited。
可选地，该词后可跟 "+" 或 "-"。使用 "+" 表示该实现要求强度
可能在规范的未来版本中提高。使用 "-" 表示该实现要求强度
可能在规范的未来版本中降低。
Specification Document(s):
指定参数的文档参考，最好包括可用于检索文档副本的 URI。
也可包括相关章节指示，但并非必须。
7.4.2. 初始注册内容
This section registers the values defined in Section 6.1.
o "kty" Parameter Value: "EC"
o Key Type Description: 椭圆曲线
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2 of RFC 7518
o "kty" Parameter Value: "RSA"
o Key Type Description: RSA
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.3 of RFC 7518
o "kty" Parameter Value: "oct"
o Key Type Description: 八位字节序列
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.4 of RFC 7518
7.5. JSON Web 密钥参数注册
本节在由 [JWK] 建立的 IANA "JSON Web Key
Parameters" 注册表中注册本规范第 6.2、
6.3 和 6.4 节中定义的参数名称。
Jones Standards Track [Page 45]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.5.1. 注册内容
o Parameter Name: "crv"
o Parameter Description: 曲线
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Parameter Name: "x"
o Parameter Description: X 坐标
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.2 of RFC 7518
o Parameter Name: "y"
o Parameter Description: Y 坐标
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.3 of RFC 7518
o Parameter Name: "d"
o Parameter Description: ECC 私钥
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.2.2.1 of RFC 7518
o Parameter Name: "n"
o Parameter Description: 模数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public
o Change Controller: IESG
o Specification Document(s): Section 6.3.1.1 of RFC 7518
o Parameter Name: "e"
o Parameter Description: 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public
o Change Controller: IESG
o Specification Document(s): Section 6.3.1.2 of RFC 7518
Jones Standards Track [Page 46]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Parameter Name: "d"
o Parameter Description: 私有指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.1 of RFC 7518
o Parameter Name: "p"
o Parameter Description: 第一素数因子
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.2 of RFC 7518
o Parameter Name: "q"
o Parameter Description: 第二素数因子
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.3 of RFC 7518
o Parameter Name: "dp"
o Parameter Description: 第一因子 CRT 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.4 of RFC 7518
o Parameter Name: "dq"
o Parameter Description: 第二因子 CRT 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.5 of RFC 7518
o Parameter Name: "qi"
o Parameter Description: 第一 CRT 系数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.6 of RFC 7518
Jones Standards Track [Page 47]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Parameter Name: "oth"
o Parameter Description: 其他素数信息
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.3.2.7 of RFC 7518
o Parameter Name: "k"
o Parameter Description: 密钥值
o Used with "kty" Value(s): "oct"
o Parameter Information Class: Private
o Change Controller: IESG
o Specification Document(s): Section 6.4.1 of RFC 7518
7.6. JSON Web Key 椭圆曲线注册表
本节为 JWK 的 "crv" 成员值建立了 IANA "JSON Web Key Elliptic Curve"
注册表。该注册表记录曲线名称、实现要求及其定义规范的参
考。本规范在第 6.2.1.1 节 注册了
相应的参数名称。
随着密码学环境的发展，曲线的实现要求可能随时间变化，例如
将某条曲线的状态更改为弃用，或将某条曲线从可选更改为推
荐+或必需。实现要求的更改只在由指定专家审查后并以“需规
范（Specification Required）”方式进行，且新的规范应定义修
订后的实现要求级别。
7.6.1. 注册模板
Curve Name:
请求的名称（例如，“P-256”）。因为本规范的核心目标之一
是使产生的表示尽可能紧凑，建议名称较短——除非有充分理
由，否则不应超过 8 个字符。该名称区分大小写。除非指定专
家认为有充分理由允许例外，否则名称不得在不区分大小写的
情况下匹配其他已注册名称。
Curve Description:
曲线的简要描述（例如，“P-256 曲线”）。
JOSE Implementation Requirements:
针对 JWS 和 JWE 的曲线实现要求，取值必须为下列单词之
一：Required、Recommended、Optional、Deprecated 或 Prohibited。
可选地，该词后可跟 "+" 或 "-"。
Jones Standards Track [Page 48]
RFC 7518 JSON Web Algorithms (JWA) May 2015
使用 "+" 表示在规范的未来版本中，需求强度可能会被提高。
使用 "-" 表示在规范的未来版本中，需求强度可能会被降低。
Change Controller:
对于标准化的 RFC，列出 "IESG"。对于其他 RFC，给出负责方的名称。
其他详细信息（例如，邮政地址、电子邮件地址、主页 URI）也可以包含在内。
Specification Document(s):
指定参数的文档或文档的引用，最好包括可以用来检索这些文档副本的 URI。
也可以包括相关章节的指示，但不是强制性的。
7.6.2. Initial Registry Contents
o Curve Name: "P-256"
o Curve Description: P-256 Curve
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-384"
o Curve Description: P-384 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-521"
o Curve Description: P-521 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
8. Security Considerations
与任何加密应用相关的所有安全问题都必须由 JWS/JWE/JWK 实体来处理。
这些问题包括保护用户的非对称私钥和对称密钥，以及针对各种攻击采取防御措施。
[AES],
[DSS],
[JWE],
[JWK],
[JWS],
[NIST.800-38D],
[NIST.800-56A],
[NIST.800-107],
[RFC2104],
[RFC3394],
[RFC3447],
[RFC5116],
[RFC6090],
和 [SHS] 中的安全注意事项
同样适用于本规范。
Jones Standards Track [Page 49]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.1. Cryptographic Agility
实现者应意识到，随着时间推移加密算法会变得脆弱。
随着新的密码分析技术的发展和计算性能的提高，破解特定加密
算法所需的工作量将会减少。因此，实现者和部署方必须为所支
持和使用的算法集随时间变化做好准备。因此，加密算法的实
现应当是模块化的，以便能够方便地插入新算法。
8.2. Key Lifetimes
许多算法具有与密钥使用寿命和/或密钥可使用次数相关的安全
考量。在将这些算法与 JOSE 数据结构一起使用时，这些安全考
量仍然适用。有关密钥寿命的具体指导，请参见 NIST SP 800-57
[NIST.800-57]。
8.3. RSAES-PKCS1-v1_5 Security Considerations
虽然 RFC 3447 第 8 节 明确建议不
在新应用中采用 RSASSA-PKCS1-v1_5，而是建议人们过渡到 RSASSA-PSS，
但为了互操作性起见，本规范仍然包含 RSASSA-PKCS1-v1_5，因为该
算法被广泛实现。
与 RSAES-PKCS1-v1_5 一起使用的密钥必须遵循 RFC 3447 第 7.2 节 中的约束。
此外，不得使用具有较低公钥指数值的密钥，正如 "Twenty Years of Attacks on the
RSA Cryptosystem" [Boneh99] 的第 3 节 所述。
8.4. AES GCM Security Considerations
与 AES GCM 一起使用的密钥必须遵循 [NIST.800-38D] 第 8.3 节中的约束，该节指出：
"对认证加密函数的调用总次数不得超过 2^32，包括所有 IV 长度和给定密钥的所有认证加密函数实例"。
根据该规则，AES GCM 绝对不得在相同的密钥值上使用超过 2^32 次。
IV 值不得在相同的 AES GCM 密钥下重复使用。防止重复使用的一种
方法是将计数器与密钥一起存储，并在每次使用时递增该计数器。
该计数器也可用于防止超过上述 2^32 的限制。
此安全注意事项不适用于复合 AES-CBC HMAC SHA-2 或 AES 密钥包裹算法。
Jones Standards Track [Page 50]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.5. Unsecured JWS Security Considerations
未加保护的 JWS（使用 "alg" 值 "none" 的 JWS）不提供完整性保护。
因此，它们仅应在有效载荷通过数字签名或 MAC 以外的方式被保护
或者根本不需要被保护的情况下使用。
防止默认接受未加保护 JWS 的一种方法是让假想的 JWS 软件库的
"verify" 方法具有布尔参数 "acceptUnsecured"，该参数指示是否接
受 "none" 作为可接受的 "alg" 值。另一种方法是，"verify" 方法
接受一个表示应用可接受算法的列表作为参数，如果该列表中不含
"none"，则拒绝未加保护的 JWS 值。
下例说明了为何不能在全局层面接受未加保护的 JWS。假设一个应
用通过两种通道接收 JWS，(1) HTTP 和 (2) 使用客户端认证的 HTTPS。
它要求对通过 HTTP 接收的对象有 JWS 签名，但接受通过 HTTPS 的
未加保护 JWS。如果应用在全局上指示接受 "none"，那么攻击者就
可以通过 HTTP 提供一个未加保护的 JWS 并仍然使该对象成功验证。
相反，应用需要针对通过 HTTPS 接收的每个对象指明接受 "none"
（例如，对上述假想 JWS 软件库将 "acceptUnsecured" 设置为 "true"），
但不应对通过 HTTP 接收的每个对象这样做。
8.6. Denial-of-Service Attacks
验证签名的接收方和加密消息的发送方在使用比本规范规定更大的密
钥验证签名和加密消息时，需要注意加密处理的消耗。攻击者可能提
供使用会导致过度加密处理的内容，例如使用比本规范规定更大的密钥。
实现应设置并强制执行其接受的密钥大小上限。NIST SP 800-57 [NIST.800-57] 的 第 5.6.1 节
（可比算法强度）包含关于可用最大批准密钥大小的说明，可能适用。
8.7. Reusing Key Material when Encrypting Keys
不建议重复使用相同的整套密钥材料（密钥加密密钥、内容加密密钥、
初始化向量等）来加密多个 JWK 或 JWK 集对象，或对同一 JWK 或 JWK 集
对象进行多次加密。关于防止重复使用的一个建议是
Jones Standards Track [Page 51]
RFC 7518 JSON Web Algorithms (JWA) May 2015
防止重复使用的一种做法是对每次加密操作始终生成至少一块新的密钥
材料（例如，新的内容加密密钥、新的 IV，和/或新的 PBES2 Salt），这基于
本文档中以及来自 RFC 4086 [RFC4086] 的考虑。
8.8. Password Considerations
密码容易受到多种攻击。为帮助缓解部分这些限制，本文档采用了
来自 RFC 2898 [RFC2898] 的原则，
从用户提供的密码派生加密密钥。
但是，密码的强度仍然有显著影响。高熵密码对字典攻击具有更强的抵抗力。
[NIST.800-63-2] 包含估算密码熵的指南，这可以帮助应
用和用户生成更强的密码。
理想的密码应当与（或大于）派生密钥长度相当。然而，超过某一特定
算法相关大小的密码会先被哈希，这会将攻击者的有效搜索空间缩减到
哈希算法的长度。建议用于 "PBES2-HS256+A128KW" 的密码长度不应短于 16
字节且不应长于 128 字节；用于 "PBES2-HS512+A256KW" 的密码长度不应短于 32
字节且不应长于 128 字节。
仍需注意密码基加密的使用场景和方式。如果迭代计数过小，这些算法仍
可能易受基于字典的攻击；如果这些算法用于保护攻击者可以无限次尝试
绕过保护的数据（例如存储在文件系统上的受保护数据），这一点尤其令人担忧。
8.9. Key Entropy and Random Values
有关密钥熵和随机值的安全注意事项，请参见 [JWS] 的第 10.1 节。
8.10. Differences between Digital Signatures and MACs
有关数字签名与 MAC 之间差异的安全注意事项，请参见 [JWS] 的第 10.5 节。
Jones Standards Track [Page 52]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.11. Using Matching Algorithm Strengths
有关使用匹配算法强度的安全注意事项，请参见 [JWE] 的第 11.3 节。
8.12. Adaptive Chosen-Ciphertext Attacks
有关自适应选择密文攻击的安全注意事项，请参见 [JWE] 的第 11.4 节。
8.13. Timing Attacks
有关计时攻击的安全注意事项，请参见 [JWS] 的第 10.9 节以及 [JWE] 的 第 11.5 节。
8.14. RSA Private Key Representations and Blinding
有关 RSA 私钥表示和盲化的安全注意事项，请参见 [JWK] 的第 9.3 节。
9. Internationalization Considerations
从用户处获得的密码可能需要进行预处理和规范化，以考虑由不同
的输入设备、区域设置等生成的八位字节序列差异。建议应用在对
直接由用户提供的密码进行密钥派生和加密之前，执行 [PRECIS] 中概述的步骤来准备密码。
10. References
10.1. Normative References
[AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[Boneh99] "Twenty Years of Attacks on the RSA Cryptosystem", Notices
of the American Mathematical Society (AMS), Vol. 46,
No. 2, pp. 203-213, 1999, <http://crypto.stanford.edu/
~dabo/pubs/papers/RSA-survey.pdf>.
Jones Standards Track [Page 53]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[DSS] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4, July
2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<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, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[NIST.800-38A]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", NIST
Special Publication 800-38A, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[NIST.800-56A]
National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[NIST.800-57]
National Institute of Standards and Technology (NIST),
"Recommendation for Key Management - Part 1: General
(Revision 3)", NIST Special Publication 800-57, Part 1,
Revision 3, July 2012, <http://csrc.nist.gov/publications/
nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
Jones Standards Track [Page 54]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
Jones Standards Track [Page 55]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009,
<http://www.secg.org/sec1-v2.pdf>.
[SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
10.2. Informative References
[AEAD-CBC-SHA]
McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", Work in Progress,
draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[CanvasApp]
Facebook, "Canvas Applications", 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JCA] Oracle, "Java Cryptography Architecture (JCA) Reference
Guide", 2014, <http://docs.oracle.com/javase/8/docs/techno
tes/guides/security/crypto/CryptoSpec.html>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", Work in Progress,
draft-rescorla-jsms-00, March 2011.
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign 1.0",
Draft 01, September 2010, <http://jsonenc.info/jss/1.0/>.
Jones Standards Track [Page 56]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[JWE-JWK] Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK)
Objects", Work in Progress,
draft-miller-jose-jwe-protected-jwk-02, June 2013.
[MagicSignatures]
Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[NIST.800-107]
National Institute of Standards and Technology (NIST),
"Recommendation for Applications Using Approved Hash
Algorithms", NIST Special Publication 800-107, Revision 1,
August 2012, <http://csrc.nist.gov/publications/
nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-63-2]
National Institute of Standards and Technology (NIST),
"Electronic Authentication Guideline", NIST Special
Publication 800-63-2, August 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-2.pdf>.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Work in Progress,
draft-ietf-precis-saslprepbis-16, April 2015.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
Jones Standards Track [Page 57]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler,
T., Yiu, K., Datta, P., and S. Cantor, "XML Signature
Syntax and Processing Version 2.0", World Wide Web
Consortium Note NOTE-xmldsig-core2-20130411, April 2013,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[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, April 2013,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones Standards Track [Page 58]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix A. Algorithm Identifier Cross-Reference
This appendix contains tables cross-referencing the cryptographic
algorithm identifier values defined in this specification with the
equivalent identifiers used by other standards and software packages.
See XML DSIG [RFC3275], XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411], XML Encryption
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.REC-xmlenc-core1-20130411], and Java Cryptography Architecture
[JCA] for more information about the names defined by those
documents.
Jones Standards Track [Page 59]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.1. Digital Signature/MAC Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.
+-------------------------------------------------------------------+
| JWS | XML DSIG |
| | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 |
| | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 |
| | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 |
| | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 |
| | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 |
| | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 |
| | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 |
| | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 |
| | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 |
| | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 |
| | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 |
| | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
Jones Standards Track [Page 60]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.2. Key Management Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
identifiers used by other standards and software packages.
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| RSA1_5 | http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
| | RSA/ECB/PKCS1Padding | 1.2.840.113549.1.1.1 |
+-------------------------------------------------------------------+
| RSA-OAEP | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
| | RSA/ECB/OAEPWithSHA-1AndMGF1Padding | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| RSA-OAEP-256 | http://www.w3.org/2009/xmlenc11#rsa-oaep |
| | & http://www.w3.org/2009/xmlenc11#mgf1sha256 |
| | RSA/ECB/OAEPWithSHA-256AndMGF1Padding | |
| | & MGF1ParameterSpec.SHA256 | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| ECDH-ES | http://www.w3.org/2009/xmlenc11#ECDH-ES |
| | ECDH | 1.3.132.1.12 |
+-------------------------------------------------------------------+
| A128KW | http://www.w3.org/2001/04/xmlenc#kw-aes128 |
| | AESWrap | 2.16.840.1.101.3.4.1.5 |
+-------------------------------------------------------------------+
| A192KW | http://www.w3.org/2001/04/xmlenc#kw-aes192 |
| | AESWrap | 2.16.840.1.101.3.4.1.25 |
+-------------------------------------------------------------------+
| A256KW | http://www.w3.org/2001/04/xmlenc#kw-aes256 |
| | AESWrap | 2.16.840.1.101.3.4.1.45 |
+-------------------------------------------------------------------+
Jones Standards Track [Page 61]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.3. Content Encryption Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "enc"
(encryption algorithm) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and
"A256CBC-HS512", the corresponding AES-CBC algorithm identifiers are
listed.
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| A128CBC-HS256 | http://www.w3.org/2001/04/xmlenc#aes128-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.2 |
+-------------------------------------------------------------------+
| A192CBC-HS384 | http://www.w3.org/2001/04/xmlenc#aes192-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.22 |
+-------------------------------------------------------------------+
| A256CBC-HS512 | http://www.w3.org/2001/04/xmlenc#aes256-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.42 |
+-------------------------------------------------------------------+
| A128GCM | http://www.w3.org/2009/xmlenc11#aes128-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.6 |
+-------------------------------------------------------------------+
| A192GCM | http://www.w3.org/2009/xmlenc11#aes192-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.26 |
+-------------------------------------------------------------------+
| A256GCM | http://www.w3.org/2009/xmlenc11#aes256-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.46 |
+-------------------------------------------------------------------+
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 5.2. They are
also intended to correspond to test cases that may appear in a future
version of [AEAD-CBC-SHA], demonstrating that the cryptographic
computations performed are the same.
The variable names are those defined in Section 5.2. All values are
hexadecimal.
Jones Standards Track [Page 62]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256
AES_128_CBC_HMAC_SHA_256
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79
a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9
a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2
fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36
09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8
6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b
38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f
bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5
4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
M = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
e6 e5 45 82 47 65 15 f0 ad 9f 75 a2 b7 1c 73 ef
T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
Jones Standards Track [Page 63]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5
d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db
00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6
57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21
4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b
3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21
05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a
c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27
f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
M = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7 45 94 f8 86 b3 fa af d4
86 f2 5c 71 31 e3 28 1e 36 c7 a2 d1 30 af de 57
T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7
Jones Standards Track [Page 64]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2
e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b
36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1
1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3
a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e
31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
M = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07
53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c
T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
Jones Standards Track [Page 65]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix C. Example ECDH-ES Key Agreement Computation
This example uses ECDH-ES Key Agreement and the Concat KDF to derive
the CEK in the manner described in Section 4.6. In this example, the
ECDH-ES Direct Key Agreement mode ("alg" value "ECDH-ES") is used to
produce an agreed-upon key for AES GCM with a 128-bit key ("enc"
value "A128GCM").
In this example, a producer Alice is encrypting content to a consumer
Bob. The producer (Alice) generates an ephemeral key for the key
agreement computation. Alice's ephemeral key (in JWK format) used
for the key agreement computation in this example (including the
private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
}
The consumer's (Bob's) key (in JWK format) used for the key agreement
computation in this example (including the private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
Header Parameter values used in this example are as follows. The
"apu" (agreement PartyUInfo) Header Parameter value is the base64url
encoding of the UTF-8 string "Alice" and the "apv" (agreement
PartyVInfo) Header Parameter value is the base64url encoding of the
UTF-8 string "Bob". The "epk" (ephemeral public key) Header
Parameter is used to communicate the producer's (Alice's) ephemeral
public key value to the consumer (Bob).
Jones Standards Track [Page 66]
RFC 7518 JSON Web Algorithms (JWA) May 2015
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
The resulting Concat KDF [NIST.800-56A] parameter values are:
Z
This is set to the ECDH-ES key agreement output. (This value is
often not directly exposed by libraries, due to NIST security
requirements, and only serves as an input to a KDF.) In this
example, Z is following the octet sequence (using JSON array
notation):
[158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132,
38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121,
140, 254, 144, 196].
keydatalen
This value is 128 - the number of bits in the desired output key
(because "A128GCM" uses a 128-bit key).
AlgorithmID
This is set to the octets representing the 32-bit big-endian value
7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content
"A128GCM", followed, by the octets representing the ASCII string
"A128GCM" - [65, 49, 50, 56, 71, 67, 77].
PartyUInfo
This is set to the octets representing the 32-bit big-endian value
5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content
"Alice", followed, by the octets representing the UTF-8 string
"Alice" - [65, 108, 105, 99, 101].
PartyVInfo
This is set to the octets representing the 32-bit big-endian value
3 - [0, 0, 0, 3] - the number of octets in the PartyUInfo content
"Bob", followed, by the octets representing the UTF-8 string "Bob"
- [66, 111, 98].
Jones Standards Track [Page 67]
RFC 7518 JSON Web Algorithms (JWA) May 2015
SuppPubInfo
This is set to the octets representing the 32-bit big-endian value
128 - [0, 0, 0, 128] - the keydatalen value.
SuppPrivInfo
This is set to the empty octet sequence.
Concatenating the parameters AlgorithmID through SuppPubInfo results
in an OtherInfo value of:
[0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105,
99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo
value results in the Concat KDF round 1 hash input of:
[0, 0, 0, 1,
158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38,
156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140,
254, 144, 196,
0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99,
101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
The resulting derived key, which is the first 128 bits of the round 1
hash output is:
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26]
The base64url-encoded representation of this derived key is:
VqqN6vgjbSBcIijNcacQGg
Jones Standards Track [Page 68]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Acknowledgements
Solutions for signing and encrypting JSON content were previously
explored by "Magic Signatures" [MagicSignatures], "JSON Simple Sign
1.0" [JSS], "Canvas Applications" [CanvasApp], "JSON Simple
Encryption" [JSE], and "JavaScript Message Security Format" [JSMS],
all of which influenced this document.
The "Authenticated Encryption with AES-CBC and HMAC-SHA"
[AEAD-CBC-SHA] specification, upon which the AES_CBC_HMAC_SHA2
algorithms are based, was written by David A. McGrew and Kenny
Paterson. The test cases for AES_CBC_HMAC_SHA2 are based upon those
for [AEAD-CBC-SHA] by John Foley.
Matt Miller wrote "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects"
[JWE-JWK], upon which the password-based encryption content of this
document is based.
This specification is the work of the JOSE working group, which
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
that influenced this specification:
Dirk Balfanz, Richard Barnes, Carsten Bormann, John Bradley, Brian
Campbell, Alissa Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni
Even, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand,
Jeff Hodges, Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John
Panzer, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,
Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security Area Directors during the creation of this specification.
Author's Address
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Jones Standards Track [Page 69]