跳到主要内容

5. Producing and Consuming JWSs

5. Producing and Consuming JWSs (生成和消费 JWS)

5.1 Message Signature or MAC Computation (消息签名或 MAC 计算)

要创建 JWS, 执行以下步骤. 在各步骤的输入和输出之间不存在依赖关系的情况下, 步骤顺序并不重要.

  1. 创建将用作 JWS Payload 的内容.

  2. 计算编码后的 payload 值 BASE64URL(JWS Payload).

  3. 创建包含所需 Header Parameter 集合的 JSON 对象, 这些对象共同组成 JOSE Header (JWS Protected Header 和/或 JWS Unprotected Header).

  4. 计算编码后的 header 值 BASE64URL(UTF8(JWS Protected Header)). 如果不存在 JWS Protected Header (这只能在使用 JWS JSON Serialization 且不存在 "protected" 成员时发生), 则令该值为空字符串.

  5. 按照正在使用的特定算法所定义的方式, 基于 JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) 计算 JWS Signature. "alg" (algorithm) Header Parameter MUST 存在于 JOSE Header 中, 且其算法值必须准确表示用于构造 JWS Signature 的算法.

  6. 计算编码后的 signature 值 BASE64URL(JWS Signature).

  7. 如果正在使用 JWS JSON Serialization, 则对正在执行的每个数字签名或 MAC 操作重复此过程 (步骤 3-6).

  8. 创建所需的序列化输出. 此结果的 JWS Compact Serialization 为 BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature). JWS JSON Serialization 在第 7.2 节中描述.

5.2 Message Signature or MAC Validation (消息签名或 MAC 验证)

验证 JWS 时, 执行以下步骤. 在各步骤的输入和输出之间不存在依赖关系的情况下, 步骤顺序并不重要. 如果列出的任何步骤失败, 则无法验证签名或 MAC.

当存在多个 JWS Signature 值时, 必须成功验证哪些 JWS Signature 值才接受该 JWS, 由应用决定. 在某些情况下, 所有值都必须成功验证, 否则该 JWS 将被视为无效. 在其他情况下, 只需要某个特定的 JWS Signature 值成功验证. 但是, 在所有情况下, 至少一个 JWS Signature 值 MUST 成功验证, 否则该 JWS MUST 被视为无效.

  1. 解析 JWS 表示, 以提取 JWS 各组成部分的序列化值. 使用 JWS Compact Serialization 时, 这些组成部分是 JWS Protected Header, JWS Payload 和 JWS Signature 的 base64url 编码表示; 使用 JWS JSON Serialization 时, 这些组成部分还包括未编码的 JWS Unprotected Header 值. 使用 JWS Compact Serialization 时, JWS Protected Header, JWS Payload 和 JWS Signature 按此顺序表示为 base64url 编码值, 每个值与下一个值之间由单个句点 ('.') 字符分隔, 因而正好使用两个分隔句点字符. JWS JSON Serialization 在第 7.2 节中描述.

  2. 对 JWS Protected Header 的编码表示进行 base64url 解码, 同时遵守不得使用换行符, 空白或其他附加字符的限制.

  3. 验证所得八位字节序列是完全有效且符合 RFC 7159 [RFC7159] 的 JSON 对象的 UTF-8 编码表示; 令 JWS Protected Header 为该 JSON 对象.

  4. 如果使用 JWS Compact Serialization, 则令 JOSE Header 为 JWS Protected Header. 否则, 当使用 JWS JSON Serialization 时, 令 JOSE Header 为相应 JWS Protected Header 和 JWS Unprotected Header 成员的并集, 且这些对象都必须是完全有效的 JSON 对象. 在此步骤中, 验证所得 JOSE Header 不包含重复的 Header Parameter 名称. 使用 JWS JSON Serialization 时, 此限制还包括同一个 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 由必须存在的 "alg" (algorithm) Header Parameter 值准确表示. 有关算法验证的安全考虑, 请参见第 10.6 节. 记录验证是否成功.

  9. 如果正在使用 JWS JSON Serialization, 则对表示中包含的每个数字签名或 MAC 值重复此过程 (步骤 4-8).

  10. 如果第 9 步中的验证均未成功, 则 JWS MUST 被视为无效. 否则, 在 JWS JSON Serialization 情况下, 向应用返回一个结果, 指明哪些验证成功以及哪些验证失败. 在 JWS Compact Serialization 情况下, 结果可以只指明 JWS 是否已成功验证.

最后, 注意在给定上下文中可以使用哪些算法由应用决定. 即使某个 JWS 可以成功验证, 除非 JWS 中使用的算法可被应用接受, 否则应用 SHOULD 将该 JWS 视为无效.

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

处理 JWS 不可避免地需要将已知字符串与 JSON 对象中的成员和值进行比较. 例如, 在检查算法是什么时, 会将 Unicode 字符串 "alg" 与 JOSE Header 中的成员名进行比较, 以查看是否存在匹配的 Header Parameter 名称. 随后使用同一过程确定 "alg" Header Parameter 的值是否表示受支持的算法.

执行成员名比较的 JSON 规则在 RFC 7159 [RFC7159] 第 8.3 节中描述. 由于执行的字符串比较操作只有相等和不相等, 因此可使用同样的规则将成员名和成员值与已知字符串进行比较.

这些比较规则 MUST 用于所有 JSON 字符串比较, 除非成员定义明确指出该成员值要使用不同的比较规则. 本规范中定义的成员值中, 只有 "typ" 和 "cty" 不使用这些比较规则.

某些应用可能会在区分大小写的值中包含不区分大小写的信息, 例如将 DNS 名称作为 "kid" (key ID) 值的一部分. 在这些情况下, 如果可能有多个参与方需要生成相同的值以便进行比较, 应用可能需要为表示不区分大小写部分时所使用的规范大小写定义约定, 例如将其转换为小写. (但是, 如果所有其他参与方都逐字消费生产方发出的任何值, 而不尝试将其与独立生成的值进行比较, 则生产方使用的大小写并不重要.)

另请参见第 10.12 节中的 JSON 安全考虑和第 10.13 节中的 Unicode 安全考虑.