[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web 签名（JWS）
摘要
JSON Web 签名（JWS）表示使用基于 JSON 的数据结构，通过数字签名或
消息认证码（MAC）来保护的内容。用于本规范的密码算法和标识符在独立的
JSON Web 算法（JWA）规范以及该规范定义的 IANA 注册表中进行了描述。
相关的加密能力在独立的 JSON Web 加密（JWE）规范中进行了描述。
本备忘录的状态
本文档是 Internet 标准轨道文档。
本文档是 Internet 工程任务组（IETF）的成果，代表了 IETF 社区的共识。
本文档已通过公开评审，并获得 Internet 工程指导组（IESG）的批准发布。
有关 Internet 标准的更多信息，请参见
RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误信息以及如何提供反馈的信息，可通过
http://www.rfc-editor.org/info/rfc7515
获取。
Jones, et al. Standards Track [Page 1]
RFC 7515 JSON Web Signature (JWS) May 2015
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.
Table of Contents
1. 引言 ....................................................4
1.1. 记法约定 .....................................4
2. 术语 .....................................................5
3. JSON Web 签名（JWS）概述 ...............................7
3.1. JWS 紧凑序列化概述 .........................7
3.2. JWS JSON 序列化概述 ............................8
3.3. JWS 示例 ................................................8
4. JOSE 标头 .....................................................9
4.1. 已注册的标头参数名称 .........................10
4.1.1. “alg”（算法）标头参数 .................10
4.1.2. “jku”（JWK 集 URL）标头参数 ...............10
4.1.3. “jwk”（JSON Web Key）标头参数 ..............11
4.1.4. “kid”（密钥 ID）标头参数 ....................11
4.1.5. “x5u”（X.509 URL）标头参数 .................11
4.1.6. “x5c”（X.509 证书链）标头参数 ...11
4.1.7. “x5t”（X.509 证书 SHA-1 指纹）
标头参数 ...................................12
4.1.8. “x5t#S256”（X.509 证书 SHA-256
指纹）标头参数 .......................12
4.1.9. “typ”（类型）标头参数 ......................12
4.1.10. “cty”（内容类型）标头参数 .............13
4.1.11. “crit”（关键）标头参数 ................14
4.2. 公共标头参数名称 .............................14
4.3. 私有标头参数名称 ............................14
5. 生成和处理 JWS ...................................15
5.1. 消息签名或 MAC 计算 ......................15
5.2. 消息签名或 MAC 验证 .......................16
5.3. 字符串比较规则 ...................................17
6. 密钥标识 .............................................18
Jones, et al. Standards Track [Page 2]
RFC 7515 JSON Web Signature (JWS) May 2015
7. 序列化 .................................................19
7.1. JWS 紧凑序列化 .................................19
7.2. JWS JSON 序列化 ....................................19
7.2.1. 通用 JWS JSON 序列化语法 ..............20
7.2.2. 扁平化 JWS JSON 序列化语法 ............21
8. TLS 要求 ...............................................22
9. IANA 注意事项 ............................................22
9.1. JSON Web 签名与加密标头
参数注册表 .......................................23
9.1.1. 注册模板 ..............................23
9.1.2. 初始注册表内容 ..........................24
9.2. 媒体类型注册 ...................................26
9.2.1. 注册表内容 ..................................26
10. 安全注意事项 .......................................27
10.1. 密钥熵与随机值 ............................27
10.2. 密钥保护 ...........................................28
10.3. 密钥来源认证 ................................28
10.4. 密码算法灵活性 ....................................28
10.5. 数字签名与 MAC 之间的差异 ..........28
10.6. 算法验证 .....................................29
10.7. 算法保护 .....................................29
10.8. 选择明文攻击 .................................30
10.9. 定时攻击 ...........................................30
10.10. 重放保护 .......................................30
10.11. SHA-1 证书指纹 ...........................30
10.12. JSON 安全注意事项 ............................31
10.13. Unicode 比较安全注意事项 ..............31
11. 参考文献 ....................................................32
11.1. 规范性引用 .....................................32
11.2. 参考性引用 ...................................34
附录 A. JWS 示例 .........................................36
A.1. 使用 HMAC SHA-256 的 JWS 示例 ............................36
A.1.1. 编码 ..............................................36
A.1.2. 验证 ............................................38
A.2. 使用 RSASSA-PKCS1-v1_5 SHA-256 的 JWS 示例 ...............38
A.2.1. 编码 ..............................................38
A.2.2. 验证 ............................................42
A.3. 使用 ECDSA P-256 SHA-256 的 JWS 示例 .....................42
A.3.1. 编码 ..............................................42
A.3.2. 验证 ............................................44
A.4. 使用 ECDSA P-521 SHA-512 的 JWS 示例 .....................45
A.4.1. 编码 ..............................................45
A.4.2. 验证 ............................................47
A.5. 未加保护的 JWS 示例 .....................................47
A.6. 使用通用 JWS JSON 序列化的 JWS 示例 ..........48
A.6.1. 每签名受保护的 JWS 标头 ...................48
A.6.2. 每签名未受保护的 JWS 标头 .................49
A.6.3. 完整的 JOSE 标头值 ...........................49
Jones, et al. Standards Track [Page 3]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 完整的 JWS JSON 序列化表示 ........50
A.7. 使用扁平化 JWS JSON 序列化的 JWS 示例 ........51
附录 B. “x5c”（X.509 证书链）示例 ..............52
附录 C. 关于在不使用填充的情况下实现 base64url 编码的说明
..............................................54
附录 D. 关于密钥选择的说明 ...............................55
附录 E. “crit” 标头参数的负面测试用例 .......57
附录 F. 分离内容 .....................................57
致谢 ..................................................58
作者地址 ................................................58
1. 引言
JSON Web 签名（JWS）表示使用基于 JSON 的
[RFC7159] 数据结构，通过数字签名或
消息认证码（MAC）来保护的内容。JWS 的密码机制为任意
八位字节序列提供完整性保护。有关数字签名与 MAC 之间差异的讨论，
请参见 第 10.5 节。
定义了两种紧密相关的 JWS 序列化方式。JWS 紧凑序列化是一种紧凑、
URL 安全的表示形式，适用于诸如 HTTP Authorization 标头和
URI 查询参数等空间受限的环境。JWS JSON 序列化将 JWS 表示为
JSON 对象，并支持对同一内容应用多个签名和/或 MAC。
二者共享相同的密码学基础。
用于本规范的密码算法和标识符在独立的
JSON Web 算法（JWA）
[JWA] 规范以及该规范定义的 IANA 注册表中进行了描述。
相关的加密能力在独立的
JSON Web 加密（JWE）
[JWE] 规范中进行了描述。
本规范所定义的名称较短，这是因为一个核心目标是使最终表示保持紧凑。
1.1. 记法约定
本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、
“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和
“OPTIONAL” 应按照
《用于 RFC 中表示需求级别的关键词》
[RFC2119]
中的说明进行解释。仅当这些术语以全大写形式出现时，才适用该解释。
BASE64URL(OCTETS) 表示 OCTETS 的 base64url 编码，定义见
第 2 节。
Jones, et al. Standards Track [Page 4]
RFC 7515 JSON Web Signature (JWS) May 2015
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)
表示数字签名或使用 MAC 保护的消息的数据结构。
JOSE 标头
包含用于描述所采用的密码操作和参数的参数的 JSON 对象。
JOSE（JSON 对象签名与加密）标头由一组标头参数组成。
JWS 载荷
需要被保护的八位字节序列——即消息本身。
载荷可以包含任意的八位字节序列。
JWS 签名
针对 JWS 受保护标头和 JWS 载荷生成的数字签名或 MAC。
标头参数
JOSE 标头中的一个名称/值对成员。
JWS 受保护标头
包含由 JWS 签名数字签名或 MAC 操作进行完整性保护的
标头参数的 JSON 对象。
对于 JWS 紧凑序列化，它构成整个 JOSE 标头；
对于 JWS JSON 序列化，它是 JOSE 标头的一个组成部分。
JWS 未受保护标头
包含未进行完整性保护的标头参数的 JSON 对象。
仅在使用 JWS JSON 序列化时才可能存在。
Jones, et al. Standards Track [Page 5]
RFC 7515 JSON Web Signature (JWS) May 2015
Base64url 编码
使用 RFC 4648 第 5 节 [RFC4648] 中定义的
URL 和文件名安全字符集进行的 Base64 编码，并省略所有结尾的
“=” 字符（如 第 3.2 节 所允许），且不包含任何换行、
空白或其他附加字符。注意，空八位字节序列的 base64url
编码结果为空字符串。（有关在不使用填充的情况下实现 base64url
编码的说明，参见 附录 C。）
JWS 签名输入
用于数字签名或 MAC 计算的输入。其值为
ASCII(BASE64URL(UTF8(JWS 受保护标头)) || '.' ||
BASE64URL(JWS 载荷))。
JWS 紧凑序列化
将 JWS 表示为紧凑、URL 安全字符串的一种表示形式。
JWS JSON 序列化
将 JWS 表示为 JSON 对象的一种表示形式。与 JWS 紧凑序列化不同，
JWS JSON 序列化允许对同一内容应用多个数字签名和/或 MAC。
该表示形式既未针对紧凑性进行优化，也不是 URL 安全的。
未加保护的 JWS
不提供完整性保护的 JWS。未加保护的 JWS 使用
“alg” 值 “none”。
抗碰撞名称
一种命名空间中的名称，其分配方式使其与其他名称发生冲突的可能性
极低。抗碰撞命名空间的示例包括：域名、ITU-T X.660 和
X.670 建议系列中定义的对象标识符（OID），以及
通用唯一标识符（UUID）
[RFC4122]。
在使用行政委派的命名空间时，名称的定义者需要采取合理的预防措施，
以确保其控制用于定义该名称的那一部分命名空间。
StringOrURI
一个 JSON 字符串值，并附加以下要求：虽然 MAY 使用任意字符串值，
但任何包含 “:” 字符的值 MUST 是一个 URI
[RFC3986]。
StringOrURI 值作为区分大小写的字符串进行比较，不进行任何转换或规范化。
Jones, et al. Standards Track [Page 6]
RFC 7515 JSON Web Signature (JWS) May 2015
“JSON Web 加密（JWE）”、“JWE 紧凑序列化（JWE Compact Serialization）”
以及“JWE JSON 序列化（JWE JSON Serialization）”这些术语由
JWE 规范定义
[JWE]。
“数字签名（Digital Signature）”和“消息认证码（Message Authentication Code，MAC）”
这两个术语由《Internet Security Glossary, Version 2》
定义
[RFC4949]。
3. JSON Web 签名（JWS）概述
JWS 使用 JSON 数据结构和 base64url 编码来表示经过数字签名
或 MAC 保护的内容。按照
RFC 7159 第 2 节
[RFC7159]，
这些 JSON 数据结构可以在任何 JSON 值或结构字符之前或之后
包含空白字符和/或换行符。一个 JWS 表示以下这些逻辑值
（每一项均在 第 2 节 中定义）：
o JOSE 头部（JOSE Header）
o JWS 载荷（JWS Payload）
o JWS 签名（JWS Signature）
对于一个 JWS，JOSE 头部的成员是以下各值成员的并集
（每一项均在 第 2 节 中定义）：
o JWS 受保护头部（JWS Protected Header）
o JWS 非受保护头部（JWS Unprotected Header）
本文档为 JWS 定义了两种序列化形式：一种是紧凑、URL 安全的
序列化形式，称为 JWS 紧凑序列化（JWS Compact Serialization）；
另一种是称为 JWS JSON 序列化（JWS JSON Serialization）的
JSON 序列化形式。在这两种序列化中，JWS 受保护头部、JWS 载荷
以及 JWS 签名都要进行 base64url 编码，因为 JSON 本身无法
直接表示任意的八位字节序列。
3.1. JWS 紧凑序列化概述
在 JWS 紧凑序列化中，不使用 JWS 非受保护头部。
在这种情况下，JOSE 头部与 JWS 受保护头部是相同的。
在 JWS 紧凑序列化中，一个 JWS 表示为以下内容的拼接：
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
有关 JWS 紧凑序列化的更多信息，请参见
第 7.1 节。
3.2. JWS JSON 序列化概述
在 JWS JSON 序列化中，JWS 受保护头部和 JWS 非受保护头部
中的一个或两个 MUST 存在。在这种情况下，JOSE 头部的成员
是实际存在的 JWS 受保护头部和 JWS 非受保护头部成员的并集。
在 JWS JSON 序列化中，一个 JWS 表示为一个 JSON 对象，
该对象包含以下四个成员中的部分或全部：
o "protected"，其值为 BASE64URL(UTF8(JWS Protected Header))
o "header"，其值为 JWS 非受保护头部
o "payload"，其值为 BASE64URL(JWS Payload)
o "signature"，其值为 BASE64URL(JWS Signature)
这三个经过 base64url 编码的结果字符串以及 JWS 非受保护头部
的值，作为成员表示在一个 JSON 对象中。
其中某些值的包含是 OPTIONAL 的。
JWS JSON 序列化还可以表示多个签名和/或 MAC 值，
而不仅仅是一个。
有关 JWS JSON 序列化的更多信息，请参见
第 7.2 节。
3.3. JWS 示例
本节提供了一个 JWS 示例。
其计算过程在 附录 A.1 中有更详细的描述，
包括用于表示所使用的 JSON 值的精确八位字节序列以及所使用的密钥值。
以下示例中的 JWS 受保护头部声明被编码的对象是一个
JSON Web Token
[JWT]，
并且 JWS 受保护头部和 JWS 载荷使用
HMAC SHA-256
[RFC2104]
[SHS]
算法进行保护：
{"typ":"JWT",
"alg":"HS256"}
将该 JWS 受保护头部编码为
BASE64URL(UTF8(JWS Protected Header)) 后，
得到如下值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
以下 JSON 对象的 UTF-8 表示形式被用作 JWS 载荷。
（请注意，载荷可以是任意内容，并不一定是 JSON 对象的表示。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
将该 JWS 载荷编码为 BASE64URL(JWS Payload) 后，
得到如下值
（仅为显示目的加入了换行）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
使用 附录 A.1 中指定的密钥，
采用 HMAC SHA-256 算法，
对 JWS 签名输入
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))
进行 HMAC 计算，
并将结果进行 base64url 编码，
得到如下 BASE64URL(JWS Signature) 值：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按照 Header.Payload.Signature 的顺序，
在各部分之间使用句点字符（'.'）进行拼接，
即得到使用 JWS 紧凑序列化形式的完整 JWS 表示
（仅为显示目的加入了换行）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
有关更多示例，请参见 附录 A，
其中还包括在 A.6 和 A.7 节中使用 JWS JSON 序列化的示例。
4. JOSE 头部
对于一个 JWS，用于表示 JOSE 头部的 JSON 对象中的成员
描述了应用于 JWS 受保护头部和 JWS 载荷的数字签名或 MAC，
以及可选的其他 JWS 属性。
JOSE 头部中的头部参数名称 MUST 是唯一的；
JWS 解析器 MUST 要么拒绝包含重复头部参数名称的 JWS，
要么使用一个 JSON 解析器，
该解析器仅返回按字词顺序出现的最后一个重复成员名称，
如 ECMAScript 5.1
[ECMAScript]
中 第 15.12 节
（“JSON 对象”）所规定的那样。
实现 MUST 理解本规范中定义并被指定为
“MUST be understood”的特定头部参数，
并按照本规范中定义的方式对其进行处理。
本规范中定义的所有其他未被如此指定的头部参数，
在未被理解时 MUST 被忽略。
除非按照 第 4.1.11 节
被列为关键（critical）头部参数，
否则本规范未定义的所有头部参数，
在未被理解时 MUST 被忽略。
头部参数名称分为三类：
已注册头部参数名称（Registered Header Parameter names）、
公共头部参数名称（Public Header Parameter names）
以及私有头部参数名称（Private Header Parameter names）。
4.1. 已注册头部参数名称
以下用于 JWS 的头部参数名称，
已在 第 9.1 节
建立的 IANA
“JSON Web Signature and Encryption Header Parameters”
注册表中注册，
其含义如以下各小节所定义。
如该公共注册表所示，
JWS 与 JWE 共享一个公共的头部参数空间；
当某个参数同时被两个规范使用时，
其使用方式 MUST 在两个规范之间保持兼容。
4.1.1. “alg”（算法）头部参数
“alg”（algorithm）头部参数用于标识
用来保护 JWS 的密码算法。
如果 “alg” 的值不表示一个受支持的算法，
或者与对内容进行数字签名或 MAC 的一方
相关联的该算法所需的密钥不存在，
则 JWS 签名值是无效的。
“alg” 的值 SHOULD 要么是在
[JWA]
建立的 IANA
“JSON Web Signature and Encryption Algorithms”
注册表中注册的值，
要么是一个包含碰撞抗性名称
（Collision-Resistant Name）的值。
“alg” 的值是一个区分大小写的 ASCII 字符串，
其内容为一个 StringOrURI 值。
该头部参数 MUST 存在，
并且 MUST 被实现理解和处理。
可用于此目的的已定义 “alg” 值列表，
可在
[JWA]
建立的 IANA
“JSON Web Signature and Encryption Algorithms”
注册表中找到；
该注册表的初始内容是
[JWA]
第 3.1 节中定义的那些值。
4.1.2. “jku”（JWK 集 URL）头部参数
“jku”（JWK Set URL）头部参数是一个 URI
[RFC3986]，
它引用一个资源，
该资源表示一个以 JSON 编码的公钥集合，
其中的某个公钥与用于对 JWS 进行数字签名的密钥相对应。
这些密钥 MUST 被编码为一个 JWK 集
[JWK]。
用于获取该资源的协议 MUST 提供完整性保护；
用于检索 JWK 集的 HTTP GET 请求
MUST 使用传输层安全协议（Transport Layer Security）
Jones, et al. Standards Track [Page 10]
RFC 7515 JSON Web Signature (JWS) May 2015
（TLS）
[RFC2818]
[RFC5246]；
并且 MUST 按照
RFC 6125 第 6 节
[RFC6125]
对服务器的身份进行验证。
另外，请参见
第 8 节
中关于 TLS 要求的说明。
使用该头部参数是 OPTIONAL 的。
4.1.3. “jwk”（JSON Web Key）头部参数
“jwk”（JSON Web Key）头部参数是与用于对 JWS 进行数字签名的密钥
相对应的公钥。该密钥以 JSON Web Key 的形式表示
[JWK]。
使用该头部参数是 OPTIONAL 的。
4.1.4. “kid”（密钥 ID）头部参数
“kid”（key ID）头部参数是一个提示，用于指明
用于保护 JWS 的是哪一个密钥。
该参数允许生成方明确地向接收方指示密钥的变更。
“kid” 值的结构未作规定。
其值 MUST 是一个区分大小写的字符串。
使用该头部参数是 OPTIONAL 的。
当与 JWK 一起使用时，
“kid” 值用于匹配 JWK 中的 “kid” 参数值。
4.1.5. “x5u”（X.509 URL）头部参数
“x5u”（X.509 URL）头部参数是一个 URI
[RFC3986]，
它引用一个资源，
该资源用于获取与用于对 JWS 进行数字签名的密钥
相对应的 X.509 公钥证书或证书链
[RFC5280]。
被标识的资源 MUST 提供符合
RFC 5280
[RFC5280]
的证书或证书链表示，
其形式为 PEM 编码，
并且每个证书 MUST 按照
RFC 4945 第 6.1 节
[RFC4945]
中规定的方式进行分隔。
包含与用于对 JWS 进行数字签名的密钥相对应的公钥的证书
MUST 是第一个证书。
其后 MAY 跟随附加证书，
每个后续证书都是用于对前一个证书进行认证的证书。
用于获取该资源的协议 MUST 提供完整性保护；
用于检索该证书的 HTTP GET 请求 MUST 使用 TLS
[RFC2818]
[RFC5246]；
并且 MUST 按照
RFC 6125 第 6 节
[RFC6125]
对服务器身份进行验证。
另外，请参见
第 8 节
中关于 TLS 要求的说明。
使用该头部参数是 OPTIONAL 的。
4.1.6. “x5c”（X.509 证书链）头部参数
“x5c”（X.509 证书链）头部参数包含
与用于对 JWS 进行数字签名的密钥相对应的
X.509 公钥证书或证书链
[RFC5280]。
该证书或证书链表示为一个 JSON 数组，
证书值字符串。
数组中的每个字符串都是
base64 编码的
（RFC 4648 第 4 节 —— 而非 base64url 编码）
DER
[ITU.X690.2008]
PKIX 证书值。
包含与用于对 JWS 进行数字签名的密钥相对应的公钥的证书
MUST 是第一个证书。
其后 MAY 跟随附加证书，
每个后续证书都是用于对前一个证书进行认证的证书。
接收方 MUST 按照
RFC 5280
[RFC5280]
对证书链进行验证，
并且如果发生任何验证失败，
MUST 将该证书或证书链视为无效。
使用该头部参数是 OPTIONAL 的。
有关 “x5c” 值的示例，请参见
附录 B。
4.1.7. “x5t”（X.509 证书 SHA-1 指纹）头部参数
“x5t”（X.509 证书 SHA-1 指纹）头部参数是
与用于对 JWS 进行数字签名的密钥相对应的
X.509 证书
[RFC5280]
的 DER 编码的
base64url 编码的 SHA-1 指纹
（又称摘要）。
请注意，证书指纹有时也被称为证书指印
（certificate fingerprint）。
使用该头部参数是 OPTIONAL 的。
4.1.8. “x5t#S256”（X.509 证书 SHA-256 指纹）头部
参数
“x5t#S256”（X.509 证书 SHA-256 指纹）头部参数是
与用于对 JWS 进行数字签名的密钥相对应的
X.509 证书
[RFC5280]
的 DER 编码的
base64url 编码的 SHA-256 指纹
（又称摘要）。
请注意，证书指纹有时也被称为证书指印。
使用该头部参数是 OPTIONAL 的。
4.1.9. “typ”（类型）头部参数
“typ”（type）头部参数用于由 JWS 应用声明
该完整 JWS 的媒体类型
[IANA.MediaTypes]。
该参数旨在用于这样一种场景：
当一个应用数据结构中可能包含多种对象，
而该数据结构中包含一个 JWS 时，
应用可以使用该值来区分
可能存在的不同类型的对象。
当对象的类型已经已知时，
该参数通常不会被应用使用。
该参数会被 JWS 实现忽略；
对该参数的任何处理均由 JWS 应用执行。
使用该头部参数是 OPTIONAL 的。
根据 RFC 2045
[RFC2045]，
所有媒体类型值、子类型值以及参数名称
都是不区分大小写的。
然而，参数值是区分大小写的，
除非针对特定参数另有规定。
为了在常见情况下保持消息的紧凑性，
RECOMMENDED 在 “typ” 头部参数中，
当媒体类型值中未出现其他 '/' 字符时，
生成方省略媒体类型值中的
“application/” 前缀。
使用该媒体类型值的接收方 MUST 将其视为
对于任何不包含 '/' 的 “typ” 值，
都在其前面隐式地添加了 “application/”。
例如，
SHOULD 使用值为 “example” 的 “typ”
来表示媒体类型 “application/example”，
而媒体类型
“application/example;part="1/2"”
则不能被缩写为
“example;part="1/2"”。
“typ” 值 “JOSE” 可由应用用于指示
该对象是使用 JWS 紧凑序列化
或 JWE 紧凑序列化的 JWS 或 JWE。
“typ” 值 “JOSE+JSON” 可由应用用于指示
该对象是使用 JWS JSON 序列化
或 JWE JSON 序列化的 JWS 或 JWE。
应用也可以使用其他类型值。
4.1.10. “cty”（内容类型）头部参数
“cty”（content type）头部参数用于由 JWS 应用声明
被保护内容（即载荷）的媒体类型
[IANA.MediaTypes]。
该参数旨在用于这样一种场景：
当 JWS 载荷中可能包含多种对象时，
应用可以使用该值来区分
可能存在的不同类型的对象。
当对象的类型已经已知时，
该参数通常不会被应用使用。
该参数会被 JWS 实现忽略；
对该参数的任何处理均由 JWS 应用执行。
使用该头部参数是 OPTIONAL 的。
根据 RFC 2045
[RFC2045]，
所有媒体类型值、子类型值以及参数名称
都是不区分大小写的。
然而，参数值是区分大小写的，
除非针对特定参数另有规定。
为了在常见情况下保持消息的紧凑性，
RECOMMENDED 在 “cty” 头部参数中，
当媒体类型值中未出现其他 '/' 字符时，
生成方省略媒体类型值中的
“application/” 前缀。
使用该媒体类型值的接收方 MUST 将其视为
对于任何不包含 '/' 的 “cty” 值，
都在其前面隐式地添加了 “application/”。
例如，
SHOULD 使用值为 “example” 的 “cty”
来表示媒体类型 “application/example”，
而媒体类型
“application/example;part="1/2"”
则不能被缩写为
“example;part="1/2"”。
4.1.11. “crit”（关键）头部参数
“crit”（critical）头部参数表示
使用了本规范和/或
[JWA]
的扩展，
并且这些扩展 MUST 被理解和处理。
其值是一个数组，
列出了在 JOSE 头部中
使用这些扩展的头部参数名称。
如果接收方无法理解并支持
所列出的任何一个扩展头部参数，
则该 JWS 是无效的。
生成方 MUST NOT 在 “crit” 列表中
包含由本规范或
[JWA]
定义并用于 JWS 的头部参数名称、
重复的名称，
或者未作为 JOSE 头部中的头部参数名称出现的名称。
生成方 MUST NOT 使用空列表 “[]”
作为 “crit” 的值。
如果关键列表中包含任何
由本规范或
[JWA]
定义并用于 JWS 的头部参数名称，
或者违反了其他任何使用约束，
接收方 MAY 将该 JWS 视为无效。
当使用该头部参数时，
它 MUST 受到完整性保护；
因此，它 MUST 仅出现在
JWS 受保护头部中。
使用该头部参数是 OPTIONAL 的。
该头部参数 MUST 被实现理解并处理。
一个示例用法，
以及一个假设的 “exp”（过期时间）字段如下：
{"alg":"ES256",
"crit":["exp"],
"exp":1363284000
}
4.2. 公共头部参数名称
使用 JWS 的各方可以定义额外的头部参数名称。
然而，为了防止冲突，
任何新的头部参数名称
SHOULD 要么在
第 9.1 节
建立的 IANA
“JSON Web Signature and Encryption Header Parameters”
注册表中注册，
要么是一个公共名称
（即包含碰撞抗性名称的值）。
在这两种情况下，
名称或值的定义者都需要采取合理的预防措施，
以确保他们控制着
用于定义该头部参数名称的命名空间部分。
新的头部参数 SHOULD 谨慎引入，
因为它们可能导致 JWS 之间无法互操作。
4.3. 私有头部参数名称
JWS 的生成方和使用方
可以约定使用私有名称的头部参数
（即不是已注册头部参数名称
（第 4.1 节））
或公共头部参数名称
（第 4.2 节）。
与公共头部参数名称不同，
私有头部参数名称存在发生冲突的风险，
因此 SHOULD 谨慎使用。
5. 生成与使用 JWS
5.1. 消息签名或 MAC 的计算
为了创建一个 JWS，
需要执行以下步骤。
在各步骤的输入与输出之间
不存在依赖关系的情况下，
步骤的执行顺序并不重要。
1. 创建将用作 JWS 载荷的内容。
2. 计算编码后的载荷值
BASE64URL(JWS Payload)。
3. 创建包含所需头部参数集合的
JSON 对象，
这些对象共同构成 JOSE 头部
（JWS 受保护头部和/或
JWS 非受保护头部）。
4. 计算编码后的头部值
BASE64URL(UTF8(JWS Protected Header))。
如果 JWS 受保护头部不存在
（这只可能发生在使用
JWS JSON 序列化且不存在
“protected” 成员的情况下），
则该值为空字符串。
5. 按照所使用的特定算法中定义的方式，
对 JWS 签名输入
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload))
计算 JWS 签名。
“alg”（算法）头部参数
MUST 存在于 JOSE 头部中，
并且其算法值 MUST
准确地表示用于构造
JWS 签名的算法。
6. 计算编码后的签名值
BASE64URL(JWS Signature)。
7. 如果使用 JWS JSON 序列化，
则针对执行的每一次
数字签名或 MAC 操作
重复该过程（步骤 3–6）。
8. 创建所需的序列化输出。
该结果的 JWS 紧凑序列化形式为
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)。
JWS JSON 序列化形式
在 第 7.2 节
中进行了描述。
Jones, et al. Standards Track [Page 15]
RFC 7515 JSON Web Signature (JWS) May 2015
5.2. 消息签名或 MAC 验证
在验证 JWS 时，将执行以下步骤。在步骤的输入和输出之间不存在依赖关系的情况下，
步骤的顺序并不重要。如果列出的任何一个步骤失败，则签名或 MAC 将无法通过验证。
当存在多个 JWS Signature 值时，应用需要决定必须成功验证哪些 JWS Signature 值
才能接受该 JWS。在某些情况下，必须全部成功验证，否则该 JWS 将被视为无效。
在其他情况下，只需某一个特定的 JWS Signature 值成功验证即可。
然而，在所有情况下，至少必须有一个 JWS Signature 值成功验证，
否则 JWS MUST 被视为无效。
1. 解析 JWS 表示形式，以提取 JWS 各组成部分的序列化值。
在使用 JWS 紧凑序列化（JWS Compact Serialization）时，
这些组成部分是 JWS Protected Header、JWS Payload 和 JWS Signature
的 base64url 编码表示；在使用 JWS JSON 序列化（JWS JSON Serialization）时，
这些组成部分还包括未编码的 JWS Unprotected Header 值。
在使用 JWS 紧凑序列化时，JWS Protected Header、JWS Payload
和 JWS Signature 按该顺序表示为 base64url 编码的值，
每个值之间使用一个句点（'.'）字符分隔，
因此总共正好使用两个分隔句点字符。
JWS JSON 序列化在 第 7.2 节 中描述。
2. 对 JWS Protected Header 的编码表示进行 Base64url 解码，
并遵循不得使用换行符、空白字符或其他附加字符的限制。
3. 验证得到的八位字节序列是一个完全有效的、
符合 RFC 7159 [RFC7159] 的 UTF-8 编码 JSON 对象表示；
将该 JSON 对象作为 JWS Protected Header。
4. 如果使用 JWS 紧凑序列化，则将 JOSE Header 设为 JWS Protected Header。
否则，在使用 JWS JSON 序列化时，
将 JOSE Header 设为对应的 JWS Protected Header
与 JWS Unprotected Header 成员的并集，
这两者都必须是完全有效的 JSON 对象。
在此步骤中，需验证生成的 JOSE Header
不包含重复的 Header Parameter 名称。
在使用 JWS
Jones, et al. Standards Track [Page 16]
RFC 7515 JSON Web Signature (JWS) May 2015
JSON 序列化时，该限制还包括：
同一个 Header Parameter 名称 MUST NOT 同时出现在
共同组成 JOSE Header 的不同 JSON 对象值中。
5. 验证实现是否理解并且能够处理其必须支持的所有字段，
无论这些字段是由本规范、所使用的算法，
还是由 "crit" Header Parameter 值所要求的；
同时还需验证这些参数的取值也是被理解和支持的。
6. 对 JWS Payload 的编码表示进行 Base64url 解码，
并遵循不得使用换行符、空白字符或其他附加字符的限制。
7. 对 JWS Signature 的编码表示进行 Base64url 解码，
并遵循不得使用换行符、空白字符或其他附加字符的限制。
8. 按照所使用算法定义的方式，
针对 JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload))
验证 JWS Signature。
所使用的算法 MUST 由 Header Parameter "alg"（algorithm）
的值准确表示，并且该参数 MUST 存在。
有关算法验证的安全注意事项，请参见
第 10.6 节。
记录验证是否成功。
9. 如果使用的是 JWS JSON 序列化，
则对表示中包含的每一个数字签名或 MAC 值
重复该过程（步骤 4–8）。
10. 如果第 9 步中的所有验证均未成功，
则 JWS MUST 被视为无效。
否则，在 JWS JSON 序列化的情况下，
向应用返回一个结果，指明哪些验证成功、哪些失败。
在 JWS 紧凑序列化的情况下，
结果只需指示 JWS 是否成功通过验证即可。
最后需要注意的是，
在给定的上下文中可以使用哪些算法由应用自行决定。
即使某个 JWS 可以成功通过验证，
如果 JWS 中使用的算法对应用而言不可接受，
应用也 SHOULD 将该 JWS 视为无效。
5.3. 字符串比较规则
处理 JWS 不可避免地需要将已知字符串
与 JSON 对象中的成员和取值进行比较。
例如，在检查算法时，
会将 Unicode 字符串 "alg"
与 JOSE Header 中的成员名称进行比较，
以确定是否存在匹配的
Jones, et al. Standards Track [Page 17]
RFC 7515 JSON Web Signature (JWS) May 2015
Header Parameter 名称。
随后，将使用相同的过程来确定
"alg" Header Parameter 的值
是否表示一个受支持的算法。
JSON 中用于成员名称比较的规则
在 RFC 7159 的第 8.3 节
[RFC7159] 中进行了描述。
由于执行的字符串比较操作仅包括相等与不相等，
因此可以使用相同的规则
来比较成员名称和成员值与已知字符串。
除非某个成员的定义明确指出
该成员值需要使用不同的比较规则，
否则这些比较规则 MUST 用于所有 JSON 字符串比较。
本规范中定义的成员值中，
只有 "typ" 和 "cty" 不使用这些比较规则。
某些应用可能会在区分大小写的值中
包含大小写不敏感的信息，
例如在 "kid"（key ID）值中包含 DNS 名称。
在这些情况下，
如果多个参与方需要生成相同的值以便进行比较，
应用可能需要为大小写不敏感的部分
定义一种规范化的表示约定，
例如统一转换为小写。
（不过，如果所有其他参与方都逐字使用
生成方输出的值，
而不尝试将其与独立生成的值进行比较，
那么生成方所使用的大小写就无关紧要。）
另请参见 第 10.12 节 中的 JSON 安全注意事项，
以及 第 10.13 节 中的 Unicode 安全注意事项。
6. 密钥标识
JWS 的接收方必须能够确定
用于数字签名或 MAC 操作的密钥。
所使用的密钥可以通过
第 4.1 节 中描述的 Header Parameter 方法进行标识，
也可以通过本规范范围之外的方法进行标识。
具体而言，可以使用 Header Parameter
"jku"、"jwk"、"kid"、"x5u"、"x5c"、"x5t" 和 "x5t#S256"
来标识所使用的密钥。
如果这些参数所传达的信息
将被用于信任决策，
则这些 Header Parameter MUST 受到完整性保护；
然而，如果信任决策中使用的唯一信息是密钥本身，
则这些参数不必受到完整性保护，
因为以导致使用不同密钥的方式更改它们
将会导致验证失败。
除非应用使用其他方式或约定来确定所使用的密钥，
否则生成方 SHOULD 在 Header Parameter 中
包含足够的信息以标识所使用的密钥。
当所使用的算法需要密钥（除 "none" 之外的所有算法均如此），
且无法确定所使用的密钥时，
签名或 MAC 验证将失败。
用于交换任何共享对称密钥的方法
超出了本规范的范围。
另请参见 附录 D，
其中包含关于可能的密钥选择算法的说明。
7. 序列化
JWS 使用两种序列化形式之一：
JWS 紧凑序列化或 JWS JSON 序列化。
使用本规范的应用需要指定
该应用所使用的序列化形式及其特性。
例如，应用可能会指定仅使用 JWS JSON 序列化，
或仅支持单个签名或 MAC 值的 JWS JSON 序列化，
或支持多个签名和/或 MAC 值。
JWS 实现只需要实现其所支持应用所需的功能即可。
7.1. JWS 紧凑序列化
JWS 紧凑序列化将经过数字签名或 MAC 处理的内容
表示为一个紧凑、URL 安全的字符串。
该字符串为：
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
JWS 紧凑序列化仅支持一个签名/MAC，
并且不提供表示 JWS Unprotected Header 值的语法。
7.2. JWS JSON 序列化
JWS JSON 序列化将经过数字签名或 MAC 处理的内容
表示为一个 JSON 对象。
该表示形式既未针对紧凑性进行优化，
也不是 URL 安全的。
JWS JSON 序列化定义了两种密切相关的语法：
一种是完全通用的语法，
可用于对内容施加多个数字签名和/或 MAC 操作；
另一种是扁平化语法，
针对单个数字签名或 MAC 的情况进行了优化。
Jones, et al. Standards Track [Page 19]
RFC 7515 JSON Web Signature (JWS) May 2015
7.2.1. 通用 JWS JSON 序列化语法
以下成员被定义用于
通用 JWS JSON 序列化语法中
顶层 JSON 对象：
payload
"payload" 成员 MUST 存在，
并包含 BASE64URL(JWS Payload) 的值。
signatures
"signatures" 成员的值 MUST 是一个 JSON 对象数组。
每个对象表示
针对 JWS Payload 和 JWS Protected Header 的
一个签名或 MAC。
以下成员被定义用于
"signatures" 数组元素中的 JSON 对象：
protected
当 JWS Protected Header 值非空时，
"protected" 成员 MUST 存在，
并包含 BASE64URL(UTF8(JWS Protected Header)) 的值；
否则，该成员 MUST 不存在。
这些 Header Parameter 值受到完整性保护。
header
当 JWS Unprotected Header 值非空时，
"header" 成员 MUST 存在，
并包含 JWS Unprotected Header 的值；
否则，该成员 MUST 不存在。
该值以未编码的 JSON 对象表示，而不是字符串。
这些 Header Parameter 值不受完整性保护。
signature
"signature" 成员 MUST 存在，
并包含 BASE64URL(JWS Signature) 的值。
对于每一个签名/MAC 计算，
"protected" 和 "header" 成员中
至少 MUST 存在一个，
以便传达 "alg" Header Parameter 值。
在上述 JSON 对象中可以存在其他成员；
如果实现无法理解这些成员，
则 MUST 忽略它们。
在创建或验证单个签名或 MAC 值时使用的
Header Parameter 值
是可能存在的两组 Header Parameter 值的并集：
(1) 在签名/MAC 数组元素的 "protected" 成员中表示的
JWS Protected Header；
(2) 在签名/MAC 数组元素的 "header" 成员中的
JWS Unprotected Header。
Jones, et al. Standards Track [Page 20]
RFC 7515 JSON Web Signature (JWS) May 2015
这两组 Header Parameter 的并集
构成了 JOSE Header。
两个位置中的 Header Parameter 名称 MUST 是不相交的。
每一个 JWS Signature 值
都使用对应 JOSE Header 值中的参数
以与 JWS 紧凑序列化相同的方式进行计算。
这一特性使得
"signatures" 数组中表示的每一个 JWS Signature 值
都与在 JWS 紧凑序列化中、
使用相同参数计算得到的值完全一致，
前提是用于该签名/MAC 计算的
JWS Protected Header 值
（即表示受完整性保护的 Header Parameter 值）
与 JWS 紧凑序列化中使用的值相匹配。
总结而言，
使用通用 JWS JSON 序列化的 JWS 语法如下：
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
有关使用通用 JWS JSON 序列化语法的示例，
请参见 附录 A.6。
7.2.2. 扁平化 JWS JSON 序列化语法
扁平化 JWS JSON 序列化语法基于通用语法，
但对其进行了扁平化处理，
以针对单个数字签名/MAC 的情况进行优化。
其方式是移除 "signatures" 成员，
并将原本定义在 "signatures" 数组中的成员
（即 "protected"、"header" 和 "signature" 成员）
放置在顶层 JSON 对象中
（与 "payload" 成员处于同一层级）。
在使用该语法时，
MUST NOT 出现 "signatures" 成员。
除了这一语法差异之外，
使用扁平化语法的 JWS JSON 序列化对象
在处理方式上与使用通用语法的对象完全相同。
Jones, et al. Standards Track [Page 21]
RFC 7515 JSON Web Signature (JWS) May 2015
总结而言，
使用扁平化 JWS JSON 序列化的 JWS 语法如下：
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
有关使用扁平化 JWS JSON 序列化语法的示例，
请参见 附录 A.7。
8. TLS 要求
支持 "jku" 和/或 "x5u" Header Parameter 的实现
MUST 支持 TLS。
应当实现哪些 TLS 版本
会随着时间推移而变化，
并取决于实现时的广泛部署情况
以及已知的安全漏洞。
在撰写本规范时，
TLS 版本 1.2
[RFC5246]
是最新版本。
为防止信息泄露和篡改，
MUST 使用 TLS
以及提供机密性和完整性保护的密码套件
来实现机密性保护。
有关当前被认为适合使用的密码套件，
请参阅 IETF TLS 工作组的最新出版物，
包括 RFC 6176
[RFC6176]。
另请参见
《Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)》
[RFC7525]，
其中给出了
提升使用 TLS 的软件和服务安全性的建议。
在使用 TLS 时，
MUST 按照
RFC 6125 第 6 节
[RFC6125]
中描述的流程，
验证 TLS 服务器证书中编码的服务提供者身份。
9. IANA 注意事项
本规范所建立的所有注册表
均使用以下注册流程。
数值在 jose-reg-review@ietf.org 邮件列表上
经过为期三周的审查期后，
在一个或多个指定专家的建议下，
以“Specification Required”
[RFC5226] 的方式进行注册。
然而，为了允许在正式发布之前分配数值，
只要指定专家确信该规范将会发布，
便可以批准注册。
Jones, et al. Standards Track [Page 22]
RFC 7515 JSON Web Signature (JWS) May 2015
发送到邮件列表以供审查的注册请求应当使用
适当的主题（例如，“Request to register header parameter:
example”）。
在审查期内，指定专家（Designated Experts）将批准
或拒绝注册请求，并将该决定告知审查列表和 IANA。
拒绝应当包含解释，并在适用的情况下，给出
如何使请求成功的建议。
超过 21 天仍未确定的注册请求
可以提请 IESG 关注（通过
iesg@ietf.org 邮件列表）以进行裁决。
指定专家应当适用的判定标准包括：
判断所提议的注册是否重复了现有功能，
是否可能具有普遍适用性，还是
仅对单一应用有用，以及
注册说明是否清晰。
IANA 只能接受来自指定专家的注册表更新，
并且应当将所有注册请求
指引至审查邮件列表。
建议任命多名指定专家，
以便代表使用本规范的不同应用视角，
从而实现对注册决定的充分知情审查。
在某些情况下，如果某项注册决定
可能被认为会给某位专家造成利益冲突，
该专家应当将判断权交由
其他专家。
9.1. JSON Web Signature 与加密头参数注册表
本规范建立了 IANA 的
“JSON Web Signature 与
Encryption Header Parameters”注册表，
用于头参数名称。
该注册表记录头参数名称以及
定义该参数的规范的引用。
同一个头参数名称可以被多次注册，
前提是该参数在不同规范中的使用方式是兼容的。
对同一头参数名称的不同注册
通常会使用不同的
头参数使用位置（Header Parameter Usage Locations）值。
9.1.1. 注册模板
Header Parameter Name:
请求注册的名称（例如，“kid”）。
由于本规范的一个核心目标
是使生成的表示形式尽可能紧凑，
因此建议名称应当较短——
在没有充分理由的情况下，
不应超过 8 个字符。
该名称是
Jones, et al. Standards Track [Page 23]
RFC 7515 JSON Web Signature (JWS) May 2015
区分大小写的。
名称在不区分大小写的情况下
不得与其他已注册名称匹配，
除非指定专家声明
允许例外具有充分的理由。
Header Parameter Description:
对头参数的简要描述
（例如，“Key ID”）。
Header Parameter Usage Location(s):
头参数的使用位置，
应当是 “JWS” 或 “JWE”
中的一个或多个值。
Change Controller:
对于标准轨道（Standards Track）的 RFC，
列出 “IESG”。
对于其他情况，
给出负责方的名称。
也可以包含其他细节
（例如，邮政地址、电子邮件地址、
主页 URI）。
Specification Document(s):
对定义该参数的文档或文档集合的引用，
最好包括可用于获取文档副本的 URI。
也可以包含相关章节的指示，
但并非必需。
9.1.2. 初始注册表内容
本节在该注册表中
注册了
第 4.1 节
中定义的头参数名称。
o Header Parameter Name: "alg"
o Header Parameter Description: 算法
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.1 节
o Header Parameter Name: "jku"
o Header Parameter Description: JWK 集 URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.2 节
o Header Parameter Name: "jwk"
o Header Parameter Description: JSON Web Key
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.3 节
Jones, et al. Standards Track [Page 24]
RFC 7515 JSON Web Signature (JWS) May 2015
o Header Parameter Name: "kid"
o Header Parameter Description: Key ID
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.4 节
o Header Parameter Name: "x5u"
o Header Parameter Description: X.509 URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.5 节
o Header Parameter Name: "x5c"
o Header Parameter Description: X.509 证书链
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.6 节
o Header Parameter Name: "x5t"
o Header Parameter Description: X.509 证书 SHA-1 指纹
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.7 节
o Header Parameter Name: "x5t#S256"
o Header Parameter Description: X.509 证书 SHA-256 指纹
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.8 节
o Header Parameter Name: "typ"
o Header Parameter Description: 类型
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.9 节
o Header Parameter Name: "cty"
o Header Parameter Description: 内容类型
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.10 节
o Header Parameter Name: "crit"
o Header Parameter Description: 关键
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): RFC 7515 的第 4.1.11 节
Jones, et al. Standards Track [Page 25]
RFC 7515 JSON Web Signature (JWS) May 2015
9.2. 媒体类型注册
9.2.1. 注册表内容
本节按照
RFC 6838 [RFC6838]
中描述的方式，
在“Media Types”注册表
[IANA.MediaTypes]
中注册
“application/jose”媒体类型
[RFC2046]，
该媒体类型可用于指示内容
是使用 JWS 紧凑序列化
或 JWE 紧凑序列化的
JWS 或 JWE。
本节还在“Media Types”注册表中
注册了
“application/jose+json”媒体类型，
该类型可用于指示内容
是使用 JWS JSON 序列化
或 JWE JSON 序列化的
JWS 或 JWE。
o Type name: application
o Subtype name: jose
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit；application/jose 的值被编码为
一系列 base64url 编码的值
（其中一些可能是空字符串），
每个值之间由
一个句点（'.'）字符分隔。
o Security considerations: 参见
RFC 7515
的安全注意事项章节。
o Interoperability considerations: n/a
o Published specification: RFC 7515
o Applications that use this media type: OpenID Connect、Mozilla
Persona、Salesforce、Google、Android、Windows Azure、Xbox One、
Amazon Web Services，
以及众多其他使用 JWT 的应用
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? No
Jones, et al. Standards Track [Page 26]
RFC 7515 JSON Web Signature (JWS) May 2015
o Type name: application
o Subtype name: jose+json
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit；application/jose+json 的值
表示为一个 JSON 对象；JSON 对象
SHOULD 使用 UTF-8 编码。
o Security considerations: 参见
RFC 7515
的安全注意事项章节
o Interoperability considerations: n/a
o Published specification: RFC 7515
o Applications that use this media type: Nimbus JOSE + JWT 库
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? No
10. 安全注意事项
所有与任何密码学应用相关的安全问题
都必须由 JWS/JWE/JWK 代理来处理。
这些问题包括保护用户的非对称私钥
和对称秘密密钥，以及
采用针对各种攻击的对策。
“XML Signature Syntax and
Processing Version 2.0”
[W3C.NOTE-xmldsig-core2-20130411]
中的所有安全注意事项
也同样适用于本规范，
除了那些特定于 XML 的内容。
同样，
“XML Signature Best Practices”
[W3C.NOTE-xmldsig-bestpractices-20130411]
中记录的许多最佳实践
也适用于本规范，
除了那些特定于 XML 的内容。
10.1. 密钥熵与随机值
密钥的强度仅与用于生成它们的熵的数量相当。
所有密钥都应当至少使用
128 位的熵，
并且根据应用环境，
可能需要更多的熵。
Jones, et al. Standards Track [Page 27]
RFC 7515 JSON Web Signature (JWS) May 2015
实现必须随机生成公钥/私钥对、
MAC 密钥以及填充值。
使用不充分的伪随机数生成器（PRNG）
来生成密码学密钥
可能导致几乎没有安全性。
攻击者可能会发现，
重现生成这些密钥的 PRNG 环境
要比对整个密钥空间
进行暴力搜索容易得多，
因为只需搜索
由此产生的较小可能性集合。
生成高质量随机数是困难的。
RFC 4086
[RFC4086]
在这一领域提供了重要指导。
10.2. 密钥保护
实现必须保护签名者的私钥。
签名者私钥的泄露
允许攻击者冒充签名者。
实现必须保护 MAC 密钥。
MAC 密钥的泄露
可能导致对已认证内容的修改
无法被检测到。
10.3. 密钥来源认证
用于获取公钥的密钥管理技术
必须对密钥的来源进行认证；
否则，无法知道
是哪一方对消息进行了签名。
同样，
用于分发 MAC 密钥的密钥管理技术
必须提供数据来源认证；
否则，内容将以完整性形式
从未知来源被交付。
10.4. 密码算法灵活性
有关密码算法灵活性的安全注意事项，
请参见
[JWA]
的第 8.1 节。
10.5. 数字签名与 MAC 之间的差异
虽然 MAC 和数字签名
都可用于完整性检查，
但它们各自提供的安全属性
存在一些显著差异。
在设计协议以及
选择在协议中使用的算法时，
需要考虑这些差异。
签名和 MAC 都提供完整性检查——
验证消息自计算完整性值以来
是否被修改。
然而，MAC 仅在特定情况下
提供来源标识。
通常可以假设，
用于签名的私钥
只掌握在单一实体手中
（尽管在复制服务器的情况下，
该实体可能是分布式的）；
Jones, et al. Standards Track [Page 28]
RFC 7515 JSON Web Signature (JWS) May 2015
然而，MAC 密钥需要掌握在
所有使用它进行完整性计算
和检查的实体手中。
对 MAC 的验证
仅能证明消息
是由某个
知道该对称 MAC 密钥的实体生成的。
这意味着，
只有当 MAC 密钥
仅为两个实体所知，
且接收方知道
自己并未创建该消息时，
才能确定来源。
MAC 验证
不能用于向第三方
证明来源。
10.6. 算法验证
某些算法的数字签名表示形式
在签名值内部
包含所使用算法的信息。
例如，
使用 RSASSA-PKCS1-v1_5
[RFC3447]
生成的签名
会对所使用的哈希函数进行编码，
并且许多库
在验证签名时
实际上会使用
签名中指定的哈希算法。
在使用此类库时，
作为算法验证的一部分，
实现 MUST 确保
签名中编码的算法信息
与
“alg”头参数中指定的算法
相一致。
如果未这样做，
攻击者可能会声称
使用了强哈希算法，
而实际上在签名值中
使用的是弱算法。
10.7. 算法保护
在某些 JWS 的使用场景中，
存在算法替换攻击的风险，
即攻击者可以
使用现有的数字签名值
配合不同的签名算法，
使其看起来像是
签名者对其并未签署的内容
进行了签名。
这些攻击
已在密码消息语法（CMS）
的背景下
进行了详细讨论
[RFC6211]。
当以下所有条件都成立时，
就会产生这种风险：
o 签名验证方
支持多种算法。
o 给定一个现有签名，
攻击者能够找到
另一个有效负载，
使其使用不同算法
生成相同的签名值。
o 攻击者构造的有效负载
在应用上下文中是有效的。
应用可以通过多种方式
缓解算法替换攻击：
o 仅使用
不易受到替换攻击的
数字签名算法。
只有当攻击者
能够为接收方接受的哈希函数
计算原像时，
替换攻击才是可行的。
Jones, et al. Standards Track [Page 29]
RFC 7515 JSON Web Signature (JWS) May 2015
所有由 JWA 定义的签名算法
都使用 SHA-2 哈希，
截至本文撰写之时，
尚无已知的
原像攻击。
o 要求
“alg”头参数
被包含在
JWS 受保护头中。
（在使用 JWS 紧凑序列化时
总是如此，
这也是 CMS
[RFC6211]
所采用的方法。）
o 在应用有效负载中
包含一个
表示算法的字段，
并要求在验证时
将其与
“alg”头参数进行匹配。
（这是 PKIX
[RFC5280]
所采用的方法。）
10.8. 选择明文攻击
JWS 的创建者
不应允许第三方
在不添加
非第三方可控熵的情况下
向消息中插入任意内容。
10.9. 时序攻击
当密码算法的实现方式
使得成功操作
与失败操作
所需时间不同，
攻击者可能能够
利用这种时间差异
获取有关所使用密钥的信息。
因此，
必须避免此类时间差异。
10.10. 重放防护
虽然不直接属于
本规范的范围，
但需要注意的是，
使用 JWS（或 JWE）对象的应用
可以通过在 JWS（或 JWE）消息中
将唯一的消息标识符
作为受完整性保护的内容包含在内，
并要求接收方验证
该消息此前
未被接收或处理过，
从而防止重放攻击。
10.11. SHA-1 证书指纹
由于兼容性原因，
在计算
“x5t”
（X.509 证书 SHA-1 指纹）值时
使用了 SHA-1 哈希。
如果将来
出现了有效生成
SHA-1 哈希碰撞的方法，
且攻击者希望
干扰某个系统中
已知证书的使用，
则可以通过
创建另一个
具有相同 SHA-1 哈希值的证书
并将其添加到
目标受害者所使用的证书存储中
来实现这一目的。
该攻击成功的前提条件是
攻击者
对目标受害者的证书存储
具有写入权限。
Jones, et al. Standards Track [Page 30]
RFC 7515 JSON Web Signature (JWS) May 2015
或者，
可以使用
“x5t#S256”
（X.509 证书 SHA-256 指纹）
头参数
来替代
“x5t”。
然而，
在本文撰写之时，
尚未发现
有任何开发平台
支持 SHA-256 证书指纹。
10.12. JSON 安全注意事项
严格的 JSON
[RFC7159]
验证是一项安全要求。
如果接收到格式错误的 JSON，
则无法可靠地辨别
生成者的意图。
如果所使用的 JSON 解析器
不拒绝格式错误的 JSON 语法，
可能会产生
含糊且潜在可被利用的情况。
特别是，
任何不符合
RFC 7159
中定义的 JSON-text 语法的 JSON 输入，
JSON 解析器
MUST 整体予以拒绝。
“The JavaScript Object Notation (JSON) Data Interchange
Format”
的
第 4 节
[RFC7159]
指出：
“对象中的名称 SHOULD 是唯一的”，
而本规范则规定：
JOSE 头中的头参数名称
MUST 是唯一的；
JWS 解析器
MUST 要么拒绝
包含重复头参数名称的 JWS，
要么使用
仅返回
按词法顺序最后一个重复成员名称的
JSON 解析器，
如 ECMAScript 5.1
[ECMAScript]
的
第 15.12 节
（“JSON 对象”）中所规定的那样。
因此，
本规范要求
生产者将
[RFC7159] 第 4 节
中的 “SHOULD”
视为 “MUST”，
并且要求使用者
要么将其视为 “MUST”，
要么按照
ECMAScript 5.1
中规定的方式进行处理。
如果 JSON 解析器
不强制成员名称的唯一性，
或者在存在重复成员名称时
返回不可预测的值，
则可能产生
含糊且潜在可被利用的情况。
某些 JSON 解析器
可能不会拒绝
在有效输入之后
仍包含额外重要字符的输入。
例如，
输入
"{"tag":"value"}ABCD"
包含一个有效的 JSON-text 对象，
后面还跟随了
额外的字符 "ABCD"。
实现 MUST 将
包含此类输入的 JWS
视为无效。
10.13. Unicode 比较的安全注意事项
头参数名称和算法名称
是 Unicode 字符串。
出于安全原因，
在执行任何转义处理之后
（如
RFC 7159 的第 8.3 节
[RFC7159]
中所述），
必须对这些名称的表示形式
进行逐字比较。
这意味着，
例如，
这些 JSON 字符串
必须比较为相等
（"sig"，"\u0073ig"），
而以下字符串
必须都与第一组
或彼此之间
比较为不相等
（"SIG"，"Sig"，"si\u0047"）。
Jones, et al. Standards Track [Page 31]
RFC 7515 JSON Web Signature (JWS) May 2015
JSON 字符串
可以包含
Unicode 基本多文种平面
之外的字符。
例如，
高音谱号字符
（U+1D11E）
可以在 JSON 字符串中
表示为
"\uD834\uDD1E"。
理想情况下，
JWS 实现
SHOULD 确保
基本多文种平面之外的字符
能够被正确保留和比较；
或者，
如果由于
这些字符触发了
底层 JSON 实现中的限制
而无法做到这一点，
则 MUST 拒绝
包含此类字符的输入。
11. 参考文献
11.1. 规范性引用
[ECMAScript] Ecma International，《ECMAScript 语言规范，
第 5.1 版》，ECMA 262，2011 年 6 月，
<http://www.ecma-international.org/ecma-262/5.1/
ECMA-262.pdf>。
[IANA.MediaTypes]
IANA，《媒体类型》，
<http://www.iana.org/assignments/media-types>。
[ITU.X690.2008]
国际电信联盟，《信息技术——ASN.1 编码规则：
基本编码规则（BER）、
规范编码规则（CER）
和判别编码规则（DER）》，
ITU-T 建议 X.690，2008 年。
[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>。
[RFC20] Cerf, V.，《用于网络交换的 ASCII 格式》，
STD 80，RFC 20，DOI 10.17487/RFC0020，
1969 年 10 月，
<http://www.rfc-editor.org/info/rfc20>。
[RFC2045] Freed, N. 和 N. Borenstein，
《多用途互联网邮件扩展（MIME）
第一部分：互联网消息体的格式》，
RFC 2045，DOI 10.17487/RFC2045，
1996 年 11 月，
<http://www.rfc-editor.org/info/rfc2045>。
Jones, et al. Standards Track [Page 32]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC2046] Freed, N. 和 N. Borenstein，
《多用途互联网邮件扩展（MIME）
第二部分：媒体类型》，
RFC 2046，
DOI 10.17487/RFC2046，
1996 年 11 月，
<http://www.rfc-editor.org/info/rfc2046>。
[RFC2119] Bradner, S.，
《在 RFC 中用于指示
需求级别的关键字》，
BCP 14，
RFC 2119，
DOI 10.17487/RFC2119，
1997 年 3 月，
<http://www.rfc-editor.org/info/rfc2119>。
[RFC2818] Rescorla, E.，
《HTTP over TLS》，
RFC 2818，
DOI 10.17487/RFC2818，
2000 年 5 月，
<http://www.rfc-editor.org/info/rfc2818>。
[RFC3629] Yergeau, F.，
《UTF-8：ISO 10646 的一种转换格式》，
STD 63，
RFC 3629，
DOI 10.17487/RFC3629，
2003 年 11 月，
<http://www.rfc-editor.org/info/rfc3629>。
[RFC3986] Berners-Lee, T.、Fielding, R. 和 L. Masinter，
《统一资源标识符（URI）：通用语法》，
STD 66，
RFC 3986，
DOI 10.17487/RFC3986，
2005 年 1 月，
<http://www.rfc-editor.org/info/rfc3986>。
[RFC4648] Josefsson, S.，
《Base16、Base32 和 Base64 数据编码》，
RFC 4648，
DOI 10.17487/RFC4648，
2006 年 10 月，
<http://www.rfc-editor.org/info/rfc4648>。
[RFC4945] Korver, B.，
《IKEv1/ISAKMP、IKEv2
与 PKIX 的
Internet IP 安全 PKI 配置文件》，
RFC 4945，
DOI 10.17487/RFC4945，
2007 年 8 月，
<http://www.rfc-editor.org/info/rfc4945>。
[RFC4949] Shirey, R.，
《互联网安全术语表，第 2 版》，
FYI 36，
RFC 4949，
DOI 10.17487/RFC4949，
2007 年 8 月，
<http://www.rfc-editor.org/info/rfc4949>。
[RFC5246] Dierks, T. 和 E. Rescorla，
《传输层安全（TLS）协议 1.2 版》，
RFC 5246，
DOI 10.17487/RFC5246，
2008 年 8 月，
<http://www.rfc-editor.org/info/rfc5246>。
[RFC5280] Cooper, D.、Santesson, S.、Farrell, S.、
Boeyen, S.、Housley, R. 和 W. Polk，
《互联网 X.509 公钥基础设施
证书与证书吊销列表（CRL）配置文件》，
RFC 5280，
DOI 10.17487/RFC5280，
2008 年 5 月，
<http://www.rfc-editor.org/info/rfc5280>。
Jones, et al. Standards Track [Page 33]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC6125] Saint-Andre, P. 和 J. Hodges，《在传输层安全 (TLS)
上下文中，使用 X.509 (PKIX) 证书在互联网公钥基础设施中
表示和验证基于域的应用服务身份》，RFC 6125，DOI 10.17487/RFC6125，
2011 年 3 月，<http://www.rfc-editor.org/info/rfc6125>。
[RFC6176] Turner, S. 和 T. Polk，《禁止使用安全套接字层 (SSL)
2.0 版》，RFC 6176，
DOI 10.17487/RFC6176，2011 年 3 月，
<http://www.rfc-editor.org/info/rfc6176>。
[RFC7159] Bray, T.（编），《JavaScript 对象表示法 (JSON)
数据交换格式》，RFC 7159，
DOI 10.17487/RFC7159，2014 年 3 月，
<http://www.rfc-editor.org/info/rfc7159>。
[UNICODE] Unicode 联盟，《Unicode 标准》，
<http://www.unicode.org/versions/latest/>。
11.2. 参考性文献
[CanvasApp] Facebook，《Canvas 应用》，
<http://developers.facebook.com/docs/authentication/
canvas>。
[JSS] Bradley, J. 和 N. Sakimura（编），《JSON Simple Sign》，
2010 年 9 月，<http://jsonenc.info/jss/1.0/>。
[JWE] Jones, M. 和 J. Hildebrand，《JSON Web Encryption
(JWE)》，RFC 7516，DOI 10.17487/RFC7516，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7516>。
[JWT] Jones, M.、Bradley, J. 和 N. Sakimura，《JSON Web Token
(JWT)》，RFC 7519，DOI 10.17487/RFC7519，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7519>。
[MagicSignatures]
Panzer, J.（编）、Laurie, B. 和 D. Balfanz，《Magic
Signatures》，2011 年 1 月，
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>。
[RFC2104] Krawczyk, H.、Bellare, M. 和 R. Canetti，《HMAC：
用于消息认证的带密钥哈希》，RFC 2104，
DOI 10.17487/RFC2104，1997 年 2 月，
<http://www.rfc-editor.org/info/rfc2104>。
Jones, et al. Standards Track [Page 34]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC3447] Jonsson, J. 和 B. Kaliski，《公钥密码学标准
(PKCS) #1：RSA 密码学规范
2.1 版》，RFC 3447，DOI 10.17487/RFC3447，2003 年 2 月，
<http://www.rfc-editor.org/info/rfc3447>。
[RFC4086] Eastlake（第三代）, D.、Schiller, J. 和 S. Crocker，
《安全所需的随机性要求》，BCP 106，
RFC 4086，DOI 10.17487/RFC4086，2005 年 6 月，
<http://www.rfc-editor.org/info/rfc4086>。
[RFC4122] Leach, P.、Mealling, M. 和 R. Salz，《通用唯一标识符
(UUID) URN 命名空间》，RFC 4122，
DOI 10.17487/RFC4122，2005 年 7 月，
<http://www.rfc-editor.org/info/rfc4122>。
[RFC5226] Narten, T. 和 H. Alvestrand，《在 RFC 中撰写
IANA 注意事项章节的指南》，BCP 26，RFC 5226，
DOI 10.17487/RFC5226，2008 年 5 月，
<http://www.rfc-editor.org/info/rfc5226>。
[RFC6211] Schaad, J.，《加密消息语法 (CMS)
算法标识符保护属性》，RFC 6211，
DOI 10.17487/RFC6211，2011 年 4 月，
<http://www.rfc-editor.org/info/rfc6211>。
[RFC6838] Freed, N.、Klensin, J. 和 T. Hansen，《媒体类型
规范与注册流程》，BCP 13，
RFC 6838，DOI 10.17487/RFC6838，2013 年 1 月，
<http://www.rfc-editor.org/info/rfc6838>。
[RFC7525] Sheffer, Y.、Holz, R. 和 P. Saint-Andre，
《安全使用传输层安全 (TLS) 与数据报传输层安全
(DTLS) 的建议》，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7525>。
[SHS] 美国国家标准与技术研究院，《安全哈希标准
(SHS)》，FIPS PUB 180-4，2012 年 3 月，
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>。
[W3C.NOTE-xmldsig-bestpractices-20130411]
Hirsch, F. 和 P. Datta，《XML 签名最佳实践》，
万维网联盟说明文档
NOTE-xmldsig-bestpractices-20130411，2013 年 4 月，
<http://www.w3.org/TR/2013/
NOTE-xmldsig-bestpractices-20130411/>。
Jones, et al. Standards Track [Page 35]
RFC 7515 JSON Web Signature (JWS) May 2015
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D.、Reagle, J.、Solo, D.、Hirsch, F.、
Roessler, T.、Yiu, K.、Datta, P. 和 S. Cantor，
《XML 签名语法与处理 2.0 版》，万维网联盟说明文档
NOTE-xmldsig-core2-20130411，2013 年 4 月，
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>。
Jones, et al. Standards Track [Page 36]
RFC 7515 JSON Web Signature (JWS) May 2015
附录 A. JWS 示例
本节提供了若干 JWS 示例。虽然前三个示例都表示 JSON Web
Token (JWT) [JWT]，但负载可以是任意八位字节序列，
如 附录 A.4 所示。
A.1. 使用 HMAC SHA-256 的 JWS 示例
A.1.1. 编码
以下示例中的 JWS 受保护头部声明该数据结构是一个 JWT
[JWT]，并且 JWS 签名输入使用
HMAC SHA-256 算法进行保护。
{"typ":"JWT",
"alg":"HS256"}
为了消除上述 JSON 对象表示中的潜在歧义，下面还给出了
在本示例中使用的、表示 UTF8(JWS 受保护头部) 的实际
八位字节序列。（注意，歧义可能由于不同平台对换行符
的表示（CRLF 与 LF）、行首和行尾空白的不同、最后一行
是否包含终止换行符等原因而产生。在本示例所使用的表示中，
第一行没有前导或尾随空格，第一行和第二行之间使用
CRLF 换行（13, 10），第二行有一个前导空格（32）且
没有尾随空格，并且最后一行不包含终止换行符。）本示例中
表示 UTF8(JWS 受保护头部) 的八位字节（使用 JSON 数组表示法）为：
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
将该 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
得到如下值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
本示例中使用的 JWS 负载是下面 JSON 对象的 UTF-8 表示
所对应的八位字节。（注意，负载可以是任意 base64url
编码的八位字节序列，并不一定需要是 base64url
编码的 JSON 对象。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Jones, et al. Standards Track [Page 37]
RFC 7515 JSON Web Signature (JWS) May 2015
以下八位字节序列是本示例中用于上述 JSON 对象的 UTF-8
表示形式，即 JWS 负载：
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
将该 JWS 负载编码为 BASE64URL(UTF8(JWS 负载)) 得到如下值
（仅为显示目的添加了换行）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
将 BASE64URL(UTF8(JWS 受保护头部)) || '.' ||
BASE64URL(JWS 负载) 组合起来得到如下字符串
（仅为显示目的添加了换行）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得到的 JWS 签名输入值，即上述字符串的 ASCII 表示形式，
对应的八位字节序列如下（使用 JSON 数组表示法）：
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81,
105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74,
73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51,
77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67,
74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84,
107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100,
72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76,
109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73,
106, 112, 48, 99, 110, 86, 108, 102, 81]
HMAC 是使用密钥生成的。本示例使用以下以 JSON Web Key
[JWK] 格式表示的对称密钥
（值中换行仅用于显示目的）：
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
Jones, et al. Standards Track [Page 38]
RFC 7515 JSON Web Signature (JWS) May 2015
使用该密钥对 JWS 签名输入运行 HMAC SHA-256 算法会得到如下
JWS 签名八位字节序列：
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173,
187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83,
132, 141, 121]
将该 JWS 签名编码为 BASE64URL(JWS 签名) 得到如下值：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按照 Header.Payload.Signature 的顺序，并在各部分之间使用
句点（'.'）字符进行连接，可得到使用 JWS 紧凑序列化形式的
完整 JWS 表示（仅为显示目的添加了换行）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
A.1.2. 验证
由于头部参数 "alg" 为 "HS256"，因此需要验证 JWS 签名中
所包含的 HMAC SHA-256 值。
为了验证该 HMAC 值，我们重复之前的过程：使用正确的密钥
和 JWS 签名输入（即 JWS 紧凑序列化表示中直到但不包括第二个
句点字符的初始子串）作为 HMAC SHA-256 函数的输入，
然后获取输出并判断其是否与 JWS 签名匹配（该签名是从
JWS 表示中编码的值进行 base64url 解码得到的）。
如果完全匹配，则说明 HMAC 已被成功验证。
A.2. 使用 RSASSA-PKCS1-v1_5 SHA-256 的 JWS 示例
A.2.1. 编码
本示例中的 JWS 受保护头部与前一个示例在两个方面不同。
首先，由于使用了不同的算法，"alg" 的值不同。其次，仅用于
说明目的，未使用可选的 "typ"（类型）头部参数。
（这一差异与所采用的算法无关。）所使用的 JWS 受保护头部为：
Jones, et al. Standards Track [Page 39]
RFC 7515 JSON Web Signature (JWS) May 2015
{"alg":"RS256"}
本示例中表示 UTF8(JWS 受保护头部) 的八位字节
（使用 JSON 数组表示法）为：
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
将该 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
得到如下值：
eyJhbGciOiJSUzI1NiJ9
本示例中使用的 JWS 负载如下，与前一个示例相同。
因此 BASE64URL(JWS 负载) 的值也相同，这里不再重复其计算过程。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
将 BASE64URL(UTF8(JWS 受保护头部)) || '.' ||
BASE64URL(JWS 负载) 组合起来得到如下字符串
（仅为显示目的添加了换行）：
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得到的 JWS 签名输入值，即上述字符串的 ASCII 表示形式，
对应的八位字节序列如下：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
Jones, et al. Standards Track [Page 40]
RFC 7515 JSON Web Signature (JWS) May 2015
本示例使用以下以 JSON Web Key
[JWK] 格式表示的 RSA 密钥
（值中换行仅用于显示目的）：
{"kty":"RSA",
"n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
}
Jones, et al. Standards Track [Page 41]
RFC 7515 JSON Web Signature (JWS) May 2015
随后将 RSA 私钥传递给 RSA 签名函数，同时该函数还接收
哈希类型 SHA-256 以及 JWS 签名输入作为输入。
数字签名的结果是一个八位字节序列，表示一个大端序整数。
在本示例中，其值为：
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69,
243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125,
131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81,
102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69,
229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219,
61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7,
16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31,
190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244,
74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1,
48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129,
253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239,
177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202,
173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157,
105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69,
34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202,
234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90,
193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238,
251, 71]
将签名编码为 BASE64URL(JWS 签名) 会生成如下值
（仅为显示目的添加了换行）：
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Jones, et al. Standards Track [Page 42]
RFC 7515 JSON Web Signature (JWS) May 2015
按照 Header.Payload.Signature 的顺序，并在各部分之间使用
句点（'.'）字符进行连接，可得到使用 JWS 紧凑序列化形式的
完整 JWS 表示（仅为显示目的添加了换行）：
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
A.2.2. 验证
由于头部参数 "alg" 为 "RS256"，因此需要验证 JWS 签名中
所包含的 RSASSA-PKCS1-v1_5 SHA-256 数字签名。
验证 JWS 签名的过程与前一个示例略有不同。我们将公钥 (n, e)、
JWS 签名（即从 JWS 表示中编码的值进行 base64url 解码得到的
字节序列），以及 JWS 签名输入（即 JWS 紧凑序列化表示中直到
但不包括第二个句点字符的初始子串）传递给一个配置为使用
SHA-256 哈希函数的 RSASSA-PKCS1-v1_5 签名验证器。
A.3. 使用 ECDSA P-256 SHA-256 的 JWS 示例
A.3.1. 编码
本示例中的 JWS 受保护头部与前一个示例不同，因为使用了
不同的算法。所使用的 JWS 受保护头部为：
{"alg":"ES256"}
本示例中表示 UTF8(JWS 受保护头部) 的八位字节
（使用 JSON 数组表示法）为：
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Jones, et al. Standards Track [Page 43]
RFC 7515 JSON Web Signature (JWS) May 2015
将此 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部)) 会得到以下值：
eyJhbGciOiJFUzI1NiJ9
本示例中使用的 JWS 载荷如下所示，与前面的示例相同。
因此，BASE64URL(JWS 载荷) 的值也将相同，这里不再重复其计算。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
将 BASE64URL(UTF8(JWS 受保护头部))、'.' 和
BASE64URL(JWS 载荷) 组合在一起，可得到如下字符串（仅为显示目的而插入换行）：
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得到的 JWS 签名输入值（即上述字符串的 ASCII 表示）
是以下八位字节序列：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
本示例使用了以下以 JSON Web Key
[JWK] 格式表示的椭圆曲线密钥：
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
随后，将椭圆曲线数字签名算法（ECDSA）的私有部分 d
传递给 ECDSA 签名函数。该函数还将曲线类型 P-256、
哈希类型 SHA-256，以及 JWS 签名输入作为输入。
数字签名的结果是椭圆曲线
Jones, et al. Standards Track [Page 44]
RFC 7515 JSON Web Signature (JWS) May 2015
（EC）点 (R, S)，其中 R 和 S 为无符号整数。
在本示例中，R 和 S 的值以表示大端整数的八位字节序列形式给出，如下所示：
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
JWS 签名的值为 R || S。
将签名编码为 BASE64URL(JWS 签名) 会生成以下值
（仅为显示目的而插入换行）：
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
按照 Header.Payload.Signature 的顺序，并在各部分之间使用句点（'.'）字符
进行连接，可得到使用 JWS 紧凑序列化形式的完整 JWS 表示
（仅为显示目的而插入换行）：
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
A.3.2. 验证
由于 "alg" 头参数为 "ES256"，因此我们需要验证
JWS 签名中包含的 ECDSA P-256 SHA-256 数字签名。
JWS 签名的验证方式与前面的示例略有不同。
我们需要将 JWS 签名的 64 个成员的八位字节序列
（即从 JWS 表示中进行 base64url 解码得到的值）
拆分为两个 32 字节的序列，第一个表示 R，第二个表示 S。
然后，我们将公钥 (x, y)、签名 (R, S)，以及 JWS 签名输入
（即 JWS 紧凑序列化表示中直到但不包括第二个句点字符为止的初始子字符串）
Jones, et al. Standards Track [Page 45]
RFC 7515 JSON Web Signature (JWS) May 2015
传递给一个已配置为使用 P-256 曲线和 SHA-256 哈希函数的
ECDSA 签名验证器。
A.4. 使用 ECDSA P-521 SHA-512 的 JWS 示例
A.4.1. 编码
本示例中的 JWS 受保护头部与前一个示例不同，
因为使用了不同的 ECDSA 曲线和哈希函数。
使用的 JWS 受保护头部为：
{"alg":"ES512"}
本示例中 UTF8(JWS 受保护头部) 所表示的八位字节
（使用 JSON 数组表示法）如下所示：
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
将此 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
会得到以下值：
eyJhbGciOiJFUzUxMiJ9
本示例中使用的 JWS 载荷是 ASCII 字符串 "Payload"。
该字符串的表示形式为以下八位字节序列：
[80, 97, 121, 108, 111, 97, 100]
将此 JWS 载荷编码为 BASE64URL(JWS 载荷) 会得到以下值：
UGF5bG9hZA
将 BASE64URL(UTF8(JWS 受保护头部))、'.' 和
BASE64URL(JWS 载荷) 组合在一起，会得到以下字符串：
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
得到的 JWS 签名输入值（即上述字符串的 ASCII 表示）
是以下八位字节序列：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85,
120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
Jones, et al. Standards Track [Page 46]
RFC 7515 JSON Web Signature (JWS) May 2015
本示例使用了以下以 JSON Web Key
[JWK] 格式表示的椭圆曲线密钥
（值中的换行仅为显示目的）：
{"kty":"EC",
"crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C"
}
随后，将 ECDSA 的私有部分 d 传递给 ECDSA 签名函数，
该函数还将曲线类型 P-521、哈希类型 SHA-512，
以及 JWS 签名输入作为输入。
数字签名的结果是 EC 点 (R, S)，其中 R 和 S 为无符号整数。
在本示例中，R 和 S 的值以表示大端整数的八位字节序列形式给出，如下所示：
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+
JWS 签名的值为 R || S。
将签名编码为 BASE64URL(JWS 签名) 会生成以下值
（仅为显示目的而插入换行）：
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Jones, et al. Standards Track [Page 47]
RFC 7515 JSON Web Signature (JWS) May 2015
按照 Header.Payload.Signature 的顺序，并在各部分之间使用句点（'.'）字符
进行连接，可得到使用 JWS 紧凑序列化形式的完整 JWS 表示
（仅为显示目的而插入换行）：
eyJhbGciOiJFUzUxMiJ9
.
UGF5bG9hZA
.
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
A.4.2. 验证
由于 "alg" 头参数为 "ES512"，因此我们需要验证
JWS 签名中包含的 ECDSA P-521 SHA-512 数字签名。
对该 JWS 签名的验证过程与前一个示例非常相似。
我们需要将 JWS 签名的 132 个成员的八位字节序列
拆分为两个 66 字节的序列，第一个表示 R，第二个表示 S。
然后，我们将公钥 (x, y)、签名 (R, S)，以及 JWS 签名输入
传递给一个已配置为使用 P-521 曲线和 SHA-512 哈希函数的
ECDSA 签名验证器。
A.5. 未加密的 JWS 示例
以下示例中的 JWS 受保护头部声明该编码对象是一个未加密的 JWS：
{"alg":"none"}
将此 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
会得到以下值：
eyJhbGciOiJub25lIn0
本示例中使用的 JWS 载荷如下所示，与前面的示例相同。
因此，BASE64URL(JWS 载荷) 的值也将相同，这里不再重复其计算。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWS 签名为空的八位字节字符串，
且 BASE64URL(JWS 签名) 也是空字符串。
Jones, et al. Standards Track [Page 48]
RFC 7515 JSON Web Signature (JWS) May 2015
按照 Header.Payload.Signature 的顺序，并在各部分之间使用句点（'.'）字符
进行连接，可得到使用 JWS 紧凑序列化形式的完整 JWS 表示
（仅为显示目的而插入换行）：
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
A.6. 使用通用 JWS JSON 序列化的 JWS 示例
本节包含一个使用通用 JWS JSON 序列化语法的示例。
该示例演示了为同一载荷传递多个数字签名和/或 MAC 的能力。
本示例中使用的 JWS 载荷与
附录 A.2 和 附录 A.3 中的示例所使用的载荷相同
（仅为显示目的而插入换行）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
本示例中使用了两个数字签名：
第一个使用 RSASSA-PKCS1-v1_5 SHA-256，第二个使用 ECDSA P-256 SHA-256。
对于第一个，其 JWS 受保护头部和密钥与 附录 A.2 中的相同，
因此会得到相同的 JWS 签名值；其计算过程在此不再重复。
对于第二个，其 JWS 受保护头部和密钥与 附录 A.3 中的相同，
因此也会得到相同的 JWS 签名值；其计算过程在此不再重复。
A.6.1. 每个签名的 JWS 受保护头部
第一个签名使用的 JWS 受保护头部值为：
{"alg":"RS256"}
将此 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
会得到以下值：
eyJhbGciOiJSUzI1NiJ9
第二个签名使用的 JWS 受保护头部值为：
{"alg":"ES256"}
Jones, et al. Standards Track [Page 49]
RFC 7515 JSON Web Signature (JWS) May 2015
将此 JWS 受保护头部编码为 BASE64URL(UTF8(JWS 受保护头部))
会得到以下值：
eyJhbGciOiJFUzI1NiJ9
A.6.2. 每个签名的 JWS 未受保护头部
使用每个签名的头参数为两个密钥提供了 Key ID 值。
用于表示这些 Key ID 的两个 JWS 未受保护头部值为：
{"kid":"2010-12-29"}
以及
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. 完整的 JOSE 头部值
将提供的 JWS 受保护头部和 JWS 未受保护头部值组合后，
用于第一个和第二个签名的 JOSE 头部值分别为：
{"alg":"RS256",
"kid":"2010-12-29"}
以及
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
Jones, et al. Standards Track [Page 50]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 完整的 JWS JSON 序列化表示
这些值对应的完整 JWS JSON 序列化如下所示
（值中的换行仅用于展示目的）：
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
Jones, et al. Standards Track [Page 51]
RFC 7515 JSON Web Signature (JWS) May 2015
A.7. 使用扁平化 JWS JSON 序列化的 JWS 示例
本节包含一个使用扁平化 JWS JSON 序列化语法的示例。
该示例展示了在扁平化 JSON 结构中传递单个数字签名
或 MAC 的能力。
本示例中的值与前一个示例
附录 A.6 中第二个签名的值相同。
这些值对应的完整 JWS JSON 序列化如下所示
（值中的换行仅用于展示目的）：
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
Jones, et al. Standards Track [Page 52]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix B. “x5c”（X.509 证书链）示例
下面的 JSON 数组是一个证书链示例，
可根据 第 4.1.6 节 作为
“x5c”（X.509 证书链）头参数的值使用
（值中的换行仅用于展示目的）：
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
"MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
Jones, et al. Standards Track [Page 53]
RFC 7515 JSON Web Signature (JWS) May 2015
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
Jones, et al. Standards Track [Page 54]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix C. 关于实现不带填充的 base64url 编码的说明
本附录描述了如何基于带填充的标准 base64
编码和解码函数，实现不带填充的 base64url
编码和解码函数。
为了具体说明，下面给出了实现这些函数的
C# 示例代码。类似的代码也可用于其他语言。
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // 常规 base64 编码器
s = s.Split('=')[0]; // 移除末尾的 '='
s = s.Replace('+', '-'); // 编码中的第 62 个字符
s = s.Replace('/', '_'); // 编码中的第 63 个字符
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 编码中的第 62 个字符
s = s.Replace('_', '/'); // 编码中的第 63 个字符
switch (s.Length % 4) // 使用末尾的 '=' 进行填充
{
case 0: break; // 本情况无需填充字符
case 2: s += "=="; break; // 两个填充字符
case 3: s += "="; break; // 一个填充字符
default: throw new System.Exception(
"非法的 base64url 字符串！");
}
return Convert.FromBase64String(s); // 标准 base64 解码器
}
如上述示例代码所示，需要在末尾添加的
'=' 填充字符数量，是将不带填充的
base64url 编码字符串转换为带填充形式时，
由编码字符串长度确定的一个确定性函数。
具体来说，如果长度 mod 4 为 0，则不添加填充；
如果长度 mod 4 为 2，则添加两个 '=' 填充字符；
如果长度 mod 4 为 3，则添加一个 '=' 填充字符；
如果长度 mod 4 为 1，则输入是畸形的。
Jones, et al. Standards Track [Page 55]
RFC 7515 JSON Web Signature (JWS) May 2015
下面给出了未编码值与编码值之间的对应示例。
下方的八位字节序列会被编码为其下方所示的字符串，
并且在解码后，会再现该八位字节序列。
3 236 255 224 193
A-z_4ME
Appendix D. 关于密钥选择的说明
本附录描述了一组可能的算法，
用于选择用于验证 JWS 的数字签名或 MAC 的密钥，
或用于解密 JWE 的密钥。
该指南描述的是一族可能的算法，而不是单一算法，
因为在不同的上下文中，并非所有密钥来源都会被使用，
它们可能以不同的顺序尝试，
并且有时并不会尝试所有收集到的密钥；
因此，在不同的应用上下文中，将使用不同的算法。
下面的步骤仅用于说明目的；
具体应用可以并且很可能会使用不同的算法，
或以不同的顺序执行其中的一些步骤。
具体应用通常会有一种更为简单的方式来确定要使用的密钥，
因为可能会为该应用的使用场景定义一两种密钥选择方法。
本附录补充了 第 6 节 中
关于密钥位置的规范性信息。
这些算法包括以下步骤。
请注意，这些步骤可以以任何顺序执行，
并且不需要被视为彼此独立。
例如，密钥一旦被找到就可以立即尝试，
而不必在尝试之前收集所有密钥。
1. 收集可能适用的密钥集合。密钥来源可能包括：
* 应用所使用的应用协议提供的密钥。
* 由 “jku”（JWK 集 URL）头参数引用的密钥。
* 由 “jwk”（JSON Web Key）头参数提供的密钥。
* 由 “x5u”（X.509 URL）头参数引用的密钥。
* 由 “x5c”（X.509 证书链）头参数提供的密钥。
* 应用可用的其他适用密钥。
Jones, et al. Standards Track [Page 56]
RFC 7515 JSON Web Signature (JWS) May 2015
从不同密钥来源收集和尝试密钥的顺序
通常取决于具体应用。
例如，通常会先尝试来自某一组位置
（如本地缓存）的所有密钥，
然后再从其他位置收集并尝试密钥。
2. 对收集到的密钥集合进行过滤。
例如，某些应用只会使用由
“kid”（密钥 ID）或
“x5t”（X.509 证书 SHA-1 指纹）
参数引用的密钥。
如果应用使用 JWK 的
“alg”（算法）、“use”（公钥用途）
或 “key_ops”（密钥操作）参数，
则具有这些参数不适当值的密钥将被排除。
此外，密钥还可能以特定于应用的方式，
根据某些其他成员值被包含或排除。
对于某些应用，不会应用任何过滤。
3. 对收集到的密钥集合进行排序。
例如，由
“kid”（密钥 ID）或
“x5t”（X.509 证书 SHA-1 指纹）
参数引用的密钥，
可能会在既不包含这些值的密钥之前尝试。
同样，具有某些成员值的密钥，
可能会在具有其他成员值的密钥之前尝试。
对于某些应用，不会应用任何排序。
4. 对密钥作出信任决策。
使用不满足应用信任标准的密钥生成的签名，
将不会被接受。
此类标准可能包括（但不限于）：
密钥的来源、
从 URL 获取密钥时 TLS 证书是否有效、
X.509 证书中的密钥是否由有效的证书链支持，
以及应用已知的其他信息。
5. 使用部分或全部已收集、并可能经过过滤和/
或排序的密钥，
尝试对 JWS 进行签名或 MAC 验证，
或对 JWE 进行解密。
可能会对尝试的密钥数量施加限制。
该过程通常会在成功验证或解密后终止。
请注意，对于某些应用来说，
在对密钥作出信任决策之前执行签名或 MAC 验证
是合理的，
因为验证失败的密钥无需进行信任决策。
Jones, et al. Standards Track [Page 57]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix E. “crit” 头参数的负面测试用例
符合规范的实现必须拒绝包含其不理解
或无法处理的关键扩展的输入。
以下 JWS 必须被所有实现拒绝，
因为它使用了一个它们无法理解的
扩展头参数名称
“http://example.invalid/
UNDEFINED”。
任何其他类似的输入，
只要将值
“http://example.invalid/UNDEFINED”
替换为实现无法理解的任何其他头参数名称，
也都必须被拒绝。
该 JWS 的受保护头值为：
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
必须被拒绝的完整 JWS 如下所示
（换行仅用于展示目的）：
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU
ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
RkFJTA.
Appendix F. 分离的内容
在某些上下文中，
对未包含在 JWS 本身中的内容进行完整性保护
是有用的。
实现这一点的一种方式是，
按照常规方式创建一个 JWS，
使用该内容的表示作为载荷，
然后从 JWS 中删除载荷表示，
并将这个修改后的对象发送给接收方，
而不是发送 JWS 本身。
在使用 JWS 紧凑序列化时，
删除操作是通过将第二个字段
（即包含 BASE64URL(JWS Payload) 的字段）
的值替换为空字符串来完成的；
在使用 JWS JSON 序列化时，
删除操作是通过删除 “payload” 成员来完成的。
该方法假定接收方能够重建
JWS 中所使用的精确载荷。
为了使用该修改后的对象，
接收方会将载荷表示重新插入到修改后的对象中，
并以常规方式使用生成的 JWS。
请注意，该方法不需要 JWS 库的任何支持，
因为应用可以通过修改
标准 JWS 库的输入和输出
来使用该方法。
Jones, et al. Standards Track [Page 58]
RFC 7515 JSON Web Signature (JWS) May 2015
致谢
在此之前，已经有多种用于签署 JSON 内容的解决方案，
包括 Magic Signatures [MagicSignatures]、
JSON Simple Sign [JSS]、
以及 Canvas Applications
[CanvasApp]，
它们都对本文档产生了影响。
感谢 Axel Nennker 对 JWS 和 JWE 规范的
早期实现和反馈。
本规范是 JOSE 工作组的成果，
该工作组包括数十位积极而敬业的参与者。
尤其要感谢以下个人所贡献的想法、反馈和措辞，
它们对本规范产生了影响：
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben
Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony
Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel
Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes
Tschofenig, and Sean Turner.
Jim Schaad 和 Karen O'Donoghue 担任 JOSE 工作组主席，
Sean Turner、Stephen Farrell 和 Kathleen Moriarty
在本规范制定期间担任安全领域主管。
作者地址
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Jones, et al. Standards Track [Page 59]