Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
JSON Web Encryption (JWE)
JSON Web加密（JWE）
Abstract
摘要
JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.
JSON Web加密（JWE）使用基于JSON的数据结构表示加密内容。与本规范一起使用的加密算法和标识符在单独的JSON Web算法（JWA）规范和该规范定义的IANA注册表中进行了描述。单独的JSON Web签名（JWS）规范中描述了相关的数字签名和消息认证码（MAC）功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7516.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7516.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . 8
3.1. JWE Compact Serialization Overview . . . . . . . . . . . 8
3.2. JWE JSON Serialization Overview . . . . . . . . . . . . . 9
3.3. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Registered Header Parameter Names . . . . . . . . . . . . 11
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . 12
4.1.2. "enc" (Encryption Algorithm) Header Parameter . . . . 12
4.1.3. "zip" (Compression Algorithm) Header Parameter . . . 12
4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . 13
4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
4.1.6. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13
4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 13
4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . 13
4.1.9. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter . . . . . . . . . . . . . . . . . . 14
4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 14
4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 14
4.1.13. "crit" (Critical) Header Parameter . . . . . . . . . 14
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
4.3. Private Header Parameter Names . . . . . . . . . . . . . 15
5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . 15
5.1. Message Encryption . . . . . . . . . . . . . . . . . . . 15
5.2. Message Decryption . . . . . . . . . . . . . . . . . . . 17
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 20
6. Key Identification . . . . . . . . . . . . . . . . . . . . . 20
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 20
7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . 20
7.2.1. General JWE JSON Serialization Syntax . . . . . . . . 21
7.2.2. Flattened JWE JSON Serialization Syntax . . . . . . . 23
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 24
9. Distinguishing between JWS and JWE Objects . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. JSON Web Signature and Encryption Header Parameters
Registration . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. Registry Contents . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Key Entropy and Random Values . . . . . . . . . . . . . 27
11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 27
11.3. Using Matching Algorithm Strengths . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . 8
3.1. JWE Compact Serialization Overview . . . . . . . . . . . 8
3.2. JWE JSON Serialization Overview . . . . . . . . . . . . . 9
3.3. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Registered Header Parameter Names . . . . . . . . . . . . 11
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . 12
4.1.2. "enc" (Encryption Algorithm) Header Parameter . . . . 12
4.1.3. "zip" (Compression Algorithm) Header Parameter . . . 12
4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . 13
4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
4.1.6. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13
4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 13
4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . 13
4.1.9. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter . . . . . . . . . . . . . . . . . . 14
4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 14
4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 14
4.1.13. "crit" (Critical) Header Parameter . . . . . . . . . 14
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
4.3. Private Header Parameter Names . . . . . . . . . . . . . 15
5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . 15
5.1. Message Encryption . . . . . . . . . . . . . . . . . . . 15
5.2. Message Decryption . . . . . . . . . . . . . . . . . . . 17
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 20
6. Key Identification . . . . . . . . . . . . . . . . . . . . . 20
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 20
7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . 20
7.2.1. General JWE JSON Serialization Syntax . . . . . . . . 21
7.2.2. Flattened JWE JSON Serialization Syntax . . . . . . . 23
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 24
9. Distinguishing between JWS and JWE Objects . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. JSON Web Signature and Encryption Header Parameters
Registration . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. Registry Contents . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Key Entropy and Random Values . . . . . . . . . . . . . 27
11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 27
11.3. Using Matching Algorithm Strengths . . . . . . . . . . . 28
11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . 28
11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 32
A.1. Example JWE using RSAES-OAEP and AES GCM . . . . . . . . 32
A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . 32
A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . 33
A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 34
A.1.5. Additional Authenticated Data . . . . . . . . . . . . 35
A.1.6. Content Encryption . . . . . . . . . . . . . . . . . 35
A.1.7. Complete Representation . . . . . . . . . . . . . . . 36
A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . 36
A.2. Example JWE using RSAES-PKCS1-v1_5 and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 36
A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . 37
A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . 38
A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 39
A.2.5. Additional Authenticated Data . . . . . . . . . . . . 40
A.2.6. Content Encryption . . . . . . . . . . . . . . . . . 40
A.2.7. Complete Representation . . . . . . . . . . . . . . . 40
A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . 41
A.3. Example JWE Using AES Key Wrap and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 41
A.3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 41
A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . 42
A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . 42
A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 42
A.3.5. Additional Authenticated Data . . . . . . . . . . . . 43
A.3.6. Content Encryption . . . . . . . . . . . . . . . . . 43
A.3.7. Complete Representation . . . . . . . . . . . . . . . 43
A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . 44
A.4. Example JWE Using General JWE JSON Serialization . . . . 44
A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 45
A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . 45
A.4.3. JWE Shared Unprotected Header . . . . . . . . . . . . 45
A.4.4. Complete JOSE Header Values . . . . . . . . . . . . . 45
A.4.5. Additional Authenticated Data . . . . . . . . . . . . 46
A.4.6. Content Encryption . . . . . . . . . . . . . . . . . 46
A.4.7. Complete JWE JSON Serialization Representation . . . 47
A.5. Example JWE Using Flattened JWE JSON Serialization . . . 47
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 48
B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . 48
B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . 49
B.3. 64-Bit Big-Endian Representation of AAD Length . . . . . 49
11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . 28
11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 32
A.1. Example JWE using RSAES-OAEP and AES GCM . . . . . . . . 32
A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . 32
A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . 33
A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 34
A.1.5. Additional Authenticated Data . . . . . . . . . . . . 35
A.1.6. Content Encryption . . . . . . . . . . . . . . . . . 35
A.1.7. Complete Representation . . . . . . . . . . . . . . . 36
A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . 36
A.2. Example JWE using RSAES-PKCS1-v1_5 and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 36
A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . 37
A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . 38
A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 39
A.2.5. Additional Authenticated Data . . . . . . . . . . . . 40
A.2.6. Content Encryption . . . . . . . . . . . . . . . . . 40
A.2.7. Complete Representation . . . . . . . . . . . . . . . 40
A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . 41
A.3. Example JWE Using AES Key Wrap and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 41
A.3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 41
A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . 42
A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . 42
A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 42
A.3.5. Additional Authenticated Data . . . . . . . . . . . . 43
A.3.6. Content Encryption . . . . . . . . . . . . . . . . . 43
A.3.7. Complete Representation . . . . . . . . . . . . . . . 43
A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . 44
A.4. Example JWE Using General JWE JSON Serialization . . . . 44
A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 45
A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . 45
A.4.3. JWE Shared Unprotected Header . . . . . . . . . . . . 45
A.4.4. Complete JOSE Header Values . . . . . . . . . . . . . 45
A.4.5. Additional Authenticated Data . . . . . . . . . . . . 46
A.4.6. Content Encryption . . . . . . . . . . . . . . . . . 46
A.4.7. Complete JWE JSON Serialization Representation . . . 47
A.5. Example JWE Using Flattened JWE JSON Serialization . . . 47
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 48
B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . 48
B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . 49
B.3. 64-Bit Big-Endian Representation of AAD Length . . . . . 49
B.4. Initialization Vector Value . . . . . . . . . . . . . . . 49
B.5. Create Input to HMAC Computation . . . . . . . . . . . . 50
B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . 50
B.7. Truncate HMAC Value to Create Authentication Tag . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
B.4. Initialization Vector Value . . . . . . . . . . . . . . . 49
B.5. Create Input to HMAC Computation . . . . . . . . . . . . 50
B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . 50
B.7. Truncate HMAC Value to Create Authentication Tag . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures [RFC7159]. The JWE cryptographic mechanisms encrypt and provide integrity protection for an arbitrary sequence of octets.
JSON Web Encryption（JWE）使用基于JSON的数据结构表示加密内容[RFC7159]。JWE加密机制对任意八位字节序列进行加密并提供完整性保护。
Two closely related serializations for JWEs are defined. The JWE Compact Serialization is a compact, URL-safe representation intended for space constrained environments such as HTTP Authorization headers and URI query parameters. The JWE JSON Serialization represents JWEs as JSON objects and enables the same content to be encrypted to multiple parties. Both share the same cryptographic underpinnings.
为JWEs定义了两个密切相关的序列化。JWE Compact Serialization是一种紧凑、URL安全的表示形式，适用于空间受限的环境，如HTTP授权头和URI查询参数。JWE JSON序列化将JWEs表示为JSON对象，并允许向多方加密相同的内容。两者共享相同的加密基础。
Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification and IANA registries defined by that specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) [JWS] specification.
用于本规范的加密算法和标识符在单独的JSON Web算法（JWA）[JWA]规范和该规范定义的IANA注册表中进行了描述。单独的JSON Web签名（JWS）[JWS]规范中描述了相关的数字签名和MAC功能。
Names defined by this specification are short because a core goal is for the resulting representations to be compact.
本规范定义的名称很短，因为核心目标是使结果表示紧凑。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。该解释仅适用于所有大写字母的术语。
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2 of [JWS].
根据[JWS]第2节，BASE64URL（八位字节）表示八位字节的BASE64URL编码。
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE] characters.
UTF8（字符串）表示字符串的UTF-8[RFC3629]表示形式的八位字节，其中字符串是零个或多个Unicode[Unicode]字符的序列。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.
ASCII（字符串）表示字符串的ASCII[RFC20]表示的八位字节，其中字符串是零个或多个ASCII字符的序列。
The concatenation of two values A and B is denoted as A || B.
两个值A和B的串联表示为A | | B。
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name", "Header Parameter", "JOSE Header", and "StringOrURI" are defined by the JWS specification [JWS].
术语“JSON Web签名（JWS）”、“Base64url编码”、“抗冲突名称”、“头参数”、“JOSE头”和“StringOrURI”由JWS规范[JWS]定义。
The terms "Ciphertext", "Digital Signature", "Initialization Vector (IV)", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
术语“密文”、“数字签名”、“初始化向量（IV）”、“消息认证码（MAC）”和“明文”由“互联网安全词汇表，版本2”[RFC4949]定义。
These terms are defined by this specification:
这些术语由本规范定义：
JSON Web Encryption (JWE) A data structure representing an encrypted and integrity-protected message.
JSON Web Encryption（JWE）表示加密和完整性保护消息的数据结构。
Authenticated Encryption with Associated Data (AEAD) An AEAD algorithm is one that encrypts the plaintext, allows Additional Authenticated Data to be specified, and provides an integrated content integrity check over the ciphertext and Additional Authenticated Data. AEAD algorithms accept two inputs, the plaintext and the Additional Authenticated Data value, and produce two outputs, the ciphertext and the Authentication Tag value. AES Galois/Counter Mode (GCM) is one such algorithm.
带关联数据的身份验证加密（AEAD）AEAD算法是一种加密明文、允许指定其他身份验证数据并对密文和其他身份验证数据提供集成内容完整性检查的算法。AEAD算法接受两个输入，即明文和附加认证数据值，并产生两个输出，即密文和认证标签值。AES伽罗瓦/计数器模式（GCM）就是这样一种算法。
Additional Authenticated Data (AAD) An input to an AEAD operation that is integrity protected but not encrypted.
附加身份验证数据（AAD）AEAD操作的输入，该操作受完整性保护但未加密。
Authentication Tag An output of an AEAD operation that ensures the integrity of the ciphertext and the Additional Authenticated Data. Note that some algorithms may not use an Authentication Tag, in which case this value is the empty octet sequence.
认证标签AEAD操作的输出，确保密文和附加认证数据的完整性。请注意，某些算法可能不使用身份验证标记，在这种情况下，该值是空的八位字节序列。
Content Encryption Key (CEK) A symmetric key for the AEAD algorithm used to encrypt the plaintext to produce the ciphertext and the Authentication Tag.
内容加密密钥（CEK）：AEAD算法的对称密钥，用于加密明文以生成密文和身份验证标签。
JWE Encrypted Key Encrypted Content Encryption Key value. Note that for some algorithms, the JWE Encrypted Key value is specified as being the empty octet sequence.
JWE加密密钥加密内容加密密钥值。注意，对于某些算法，JWE加密的密钥值被指定为空的八位字节序列。
JWE Initialization Vector Initialization Vector value used when encrypting the plaintext. Note that some algorithms may not use an Initialization Vector, in which case this value is the empty octet sequence.
JWE初始化向量加密明文时使用的初始化向量值。请注意，某些算法可能不使用初始化向量，在这种情况下，该值为空八位组序列。
JWE AAD Additional value to be integrity protected by the authenticated encryption operation. This can only be present when using the JWE JSON Serialization. (Note that this can also be achieved when using either the JWE Compact Serialization or the JWE JSON Serialization by including the AAD value as an integrity-protected Header Parameter value, but at the cost of the value being double base64url encoded.)
JWE是一个附加值，由经过身份验证的加密操作保护完整性。这只能在使用JWE JSON序列化时出现。（请注意，在使用JWE压缩序列化或JWE JSON序列化时，也可以通过将AAD值包含为完整性保护的头参数值来实现这一点，但代价是对该值进行双基64URL编码。）
JWE Ciphertext Ciphertext value resulting from authenticated encryption of the plaintext with Additional Authenticated Data.
JWE密文密文值，该值是通过使用附加的认证数据对明文进行认证加密而得到的。
JWE Authentication Tag Authentication Tag value resulting from authenticated encryption of the plaintext with Additional Authenticated Data.
JWE身份验证标记身份验证标记值，该值是通过使用附加身份验证数据对明文进行身份验证加密得到的。
JWE Protected Header JSON object that contains the Header Parameters that are integrity protected by the authenticated encryption operation. These parameters apply to all recipients of the JWE. For the JWE Compact Serialization, this comprises the entire JOSE Header. For the JWE JSON Serialization, this is one component of the JOSE Header.
JWE Protected Header JSON对象，该对象包含由经过身份验证的加密操作保护完整性的头参数。这些参数适用于JWE的所有收件人。对于JWE压缩序列化，它包含整个JOSE头。对于jwejson序列化，这是JOSE头的一个组件。
JWE Shared Unprotected Header JSON object that contains the Header Parameters that apply to all recipients of the JWE that are not integrity protected. This can only be present when using the JWE JSON Serialization.
JWE共享未受保护的头JSON对象，该对象包含应用于未受完整性保护的JWE的所有收件人的头参数。这只能在使用JWE JSON序列化时出现。
JWE Per-Recipient Unprotected Header JSON object that contains Header Parameters that apply to a single recipient of the JWE. These Header Parameter values are not integrity protected. This can only be present when using the JWE JSON Serialization.
JWE-Per-Recipient未受保护的标头JSON对象，该对象包含应用于JWE的单个收件人的标头参数。这些标头参数值不受完整性保护。这只能在使用JWE JSON序列化时出现。
JWE Compact Serialization A representation of the JWE as a compact, URL-safe string.
JWE压缩序列化将JWE表示为压缩的URL安全字符串。
JWE JSON Serialization A representation of the JWE as a JSON object. The JWE JSON Serialization enables the same content to be encrypted to multiple parties. This representation is neither optimized for compactness nor URL safe.
JWE JSON序列化将JWE表示为JSON对象。JWE JSON序列化允许向多方加密相同的内容。此表示既不优化紧凑性，也不优化URL安全性。
Key Management Mode A method of determining the Content Encryption Key value to use. Each algorithm used for determining the CEK value uses a specific Key Management Mode. Key Management Modes employed by this specification are Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, and Direct Encryption.
密钥管理模式确定要使用的内容加密密钥值的方法。用于确定CEK值的每个算法使用特定的密钥管理模式。本规范采用的密钥管理模式包括密钥加密、密钥包装、直接密钥协议、密钥协议与密钥包装以及直接加密。
Key Encryption A Key Management Mode in which the CEK value is encrypted to the intended recipient using an asymmetric encryption algorithm.
密钥加密一种密钥管理模式，其中使用非对称加密算法将CEK值加密给预期收件人。
Key Wrapping A Key Management Mode in which the CEK value is encrypted to the intended recipient using a symmetric key wrapping algorithm.
密钥包装一种密钥管理模式，其中使用对称密钥包装算法将CEK值加密到预期收件人。
Direct Key Agreement A Key Management Mode in which a key agreement algorithm is used to agree upon the CEK value.
直接密钥协商一种密钥管理模式，其中使用密钥协商算法来协商CEK值。
Key Agreement with Key Wrapping A Key Management Mode in which a key agreement algorithm is used to agree upon a symmetric key used to encrypt the CEK value to the intended recipient using a symmetric key wrapping algorithm.
带密钥包装的密钥协议一种密钥管理模式，其中密钥协议算法用于商定对称密钥，该对称密钥用于使用对称密钥包装算法向预期收件人加密CEK值。
Direct Encryption A Key Management Mode in which the CEK value used is the secret symmetric key value shared between the parties.
直接加密一种密钥管理模式，其中使用的CEK值是双方共享的秘密对称密钥值。
JWE represents encrypted content using JSON data structures and base64url encoding. These JSON data structures MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159]. A JWE represents these logical values (each of which is defined in Section 2):
JWE使用JSON数据结构和base64url编码表示加密内容。根据RFC 7159[RFC7159]第2节的规定，这些JSON数据结构可能在任何JSON值或结构字符之前或之后包含空格和/或换行符。JWE表示这些逻辑值（每个值在第2节中定义）：
o JOSE Header o JWE Encrypted Key o JWE Initialization Vector o JWE AAD o JWE Ciphertext o JWE Authentication Tag
o JOSE头o JWE加密密钥o JWE初始化向量o JWE AAD o JWE密文o JWE身份验证标记
For a JWE, the JOSE Header members are the union of the members of these values (each of which is defined in Section 2):
对于JWE，JOSE头成员是这些值的成员的并集（每个值在第2节中定义）：
o JWE Protected Header o JWE Shared Unprotected Header o JWE Per-Recipient Unprotected Header
o JWE受保护的标头o JWE共享未受保护的标头o每个收件人的JWE未受保护的标头
JWE utilizes authenticated encryption to ensure the confidentiality and integrity of the plaintext and the integrity of the JWE Protected Header and the JWE AAD.
JWE利用经过身份验证的加密来确保明文的机密性和完整性，以及JWE保护头和JWE AAD的完整性。
This document defines two serializations for JWEs: a compact, URL-safe serialization called the JWE Compact Serialization and a JSON serialization called the JWE JSON Serialization. In both serializations, the JWE Protected Header, JWE Encrypted Key, JWE Initialization Vector, JWE Ciphertext, and JWE Authentication Tag are base64url encoded, since JSON lacks a way to directly represent arbitrary octet sequences. When present, the JWE AAD is also base64url encoded.
本文档为JWEs定义了两种序列化：一种称为JWE紧凑序列化的紧凑的URL安全序列化和一种称为JWE JSON序列化的JSON序列化。在这两种序列化中，JWE保护头、JWE加密密钥、JWE初始化向量、JWE密文和JWE身份验证标记都是base64url编码的，因为JSON无法直接表示任意八位字节序列。存在时，JWE AAD也是base64url编码的。
In the JWE Compact Serialization, no JWE Shared Unprotected Header or JWE Per-Recipient Unprotected Header are used. In this case, the JOSE Header and the JWE Protected Header are the same.
在JWE压缩序列化中，不使用JWE共享未保护的头或JWE每个收件人未保护的头。在这种情况下，JOSE头和JWE保护头是相同的。
In the JWE Compact Serialization, a JWE is represented as the concatenation:
在JWE压缩序列化中，JWE表示为串联：
BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag)
BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| BASE64URL（JWE身份验证标记）
See Section 7.1 for more information about the JWE Compact Serialization.
有关JWE Compact序列化的更多信息，请参见第7.1节。
In the JWE JSON Serialization, one or more of the JWE Protected Header, JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected Header MUST be present. In this case, the members of the JOSE Header are the union of the members of the JWE Protected Header, JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected Header values that are present.
在JWE JSON序列化中，必须存在一个或多个JWE保护头、JWE共享未保护头和JWE每个收件人未保护头。在这种情况下，JOSE头的成员是存在的JWE受保护头、JWE共享无保护头和JWE每个收件人无保护头值的成员的联合。
In the JWE JSON Serialization, a JWE is represented as a JSON object containing some or all of these eight members:
在JWE JSON序列化中，JWE表示为一个JSON对象，其中包含以下八个成员中的一部分或全部：
"protected", with the value BASE64URL(UTF8(JWE Protected Header)) "unprotected", with the value JWE Shared Unprotected Header "header", with the value JWE Per-Recipient Unprotected Header "encrypted_key", with the value BASE64URL(JWE Encrypted Key) "iv", with the value BASE64URL(JWE Initialization Vector) "ciphertext", with the value BASE64URL(JWE Ciphertext) "tag", with the value BASE64URL(JWE Authentication Tag) "aad", with the value BASE64URL(JWE AAD)
“受保护”，值为BASE64URL（UTF8（JWE受保护标头））“未受保护”，值为JWE共享未受保护标头“标头”，值为JWE每个收件人未受保护标头“加密密钥”，值为BASE64URL（JWE加密密钥）“iv”，值为BASE64URL（JWE初始化向量）“密文”，值为BASE64URL（JWE密文）“标记”，值为BASE64URL（JWE身份验证标记）“aad”，值为BASE64URL（JWE aad）
The six base64url-encoded result strings and the two unprotected JSON object values are represented as members within a JSON object. The inclusion of some of these values is OPTIONAL. The JWE JSON Serialization can also encrypt the plaintext to multiple recipients. See Section 7.2 for more information about the JWE JSON Serialization.
六个base64url编码的结果字符串和两个未受保护的JSON对象值表示为JSON对象中的成员。包含其中一些值是可选的。JWE JSON序列化还可以将明文加密到多个收件人。有关JWE JSON序列化的更多信息，请参见第7.2节。
This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient.
这个例子加密了明文“智力的真正标志不是知识，而是想象力”。
The following example JWE Protected Header declares that:
以下示例JWE Protected Header声明：
o The Content Encryption Key is encrypted to the recipient using the RSAES-OAEP [RFC3447] algorithm to produce the JWE Encrypted Key.
o 使用RSAES-OAEP[RFC3447]算法将内容加密密钥加密给收件人，以生成JWE加密密钥。
o Authenticated encryption is performed on the plaintext using the AES GCM [AES] [NIST.800-38D] algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.
o 使用AES GCM[AES][NIST.800-38D]算法对明文执行认证加密，使用256位密钥生成密文和认证标签。
{"alg":"RSA-OAEP","enc":"A256GCM"}
{"alg":"RSA-OAEP","enc":"A256GCM"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
将此JWE保护头编码为BASE64URL（UTF8（JWE保护头））将给出以下值：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
The remaining steps to finish creating this JWE are:
完成创建此JWE的其余步骤为：
o Generate a random Content Encryption Key (CEK).
o 生成随机内容加密密钥（CEK）。
o Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.
o 使用RSAES-OAEP算法使用接收方的公钥加密CEK，以生成JWE加密密钥。
o Base64url-encode the JWE Encrypted Key.
o Base64url对JWE加密密钥进行编码。
o Generate a random JWE Initialization Vector.
o 生成一个随机的JWE初始化向量。
o Base64url-encode the JWE Initialization Vector.
o Base64url对JWE初始化向量进行编码。
o Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))).
o 让附加的身份验证数据加密参数为ASCII（BASE64URL（UTF8（JWE保护头）））。
o Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value, requesting a 128-bit Authentication Tag output.
o 使用AES GCM算法对明文执行身份验证加密，使用CEK作为加密密钥、JWE初始化向量和附加身份验证数据值，请求128位身份验证标签输出。
o Base64url-encode the ciphertext.
o Base64url对密文进行编码。
o Base64url-encode the Authentication Tag.
o Base64url对身份验证标记进行编码。
o Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
o 组装最终表示：此结果的紧凑序列化是字符串BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| | BASE64URL（JWE身份验证标记）。
The final result in this example (with line breaks for display purposes only) is:
本例中的最终结果（换行符仅用于显示）为：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg. 48V1_ALb6US04U3b. 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A. XFBoMYUZodetZdvTiFvSkQ
EYJHBGCOIJSU0ETT0FFUCISIMVUYYI6IKEYNTZHQ00IFQ。在未来的十年中，一些研究者发现了一种新的研究成果，在未来的十年中，一些研究者发现了一种新的研究成果，在这些研究中，一些研究者们在一个新的10年中，在一个新的研究中，他们在一个新的一个研究中，在一个新的研究中，他们在一个新的研究中，他们在一个新的研究中，他们在一个新的一个研究中，他们在一个新的一个新的一个研究的一个研究中，他们在一个新的一个新的一个研究中，他们在一个新的一个新的一个研究的一个新的一个新的一个新的一个新的一个研究的一个研究的一个新的一个新的研究，他们的研究，他们在未来的一个新的一个研究的一个新的第二，他们的一个研究，他们在一个研究的一个新的第六六六六六六六i 6UKLFCIPIMFIGF7IGDXKHZG。48V1_ALb6US04U3b。5eym8TW\u c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX\u EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD\u A.XFBomyuzodetzDvtivskQ
See Appendix A.1 for the complete details of computing this JWE. See Appendix A for additional examples, including examples using the JWE JSON Serialization in Sections A.4 and A.5.
有关计算该JWE的完整详细信息，请参见附录A.1。更多示例请参见附录A，包括第A.4节和第A.5节中使用JWE JSON序列化的示例。
For a JWE, the members of the JSON object(s) representing the JOSE Header describe the encryption applied to the plaintext and optionally additional properties of the JWE. The Header Parameter names within the JOSE Header MUST be unique, just as described in Section 4 of [JWS]. The rules about handling Header Parameters that are not understood by the implementation are also the same. The classes of Header Parameter names are likewise the same.
对于JWE，表示JOSE头的JSON对象的成员描述了应用于明文的加密以及JWE的可选附加属性。JOSE头中的头参数名称必须是唯一的，如[JWS]第4节所述。关于处理未被实现理解的头参数的规则也是相同的。标题参数名称的类别同样相同。
The following Header Parameter names for use in JWEs are registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS], with meanings as defined below.
以下用于JWEs的头参数名称在[JWS]建立的IANA“JSON Web签名和加密头参数”注册表中注册，其含义如下所述。
As indicated by the common registry, JWSs and JWEs share a common Header Parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
如公共注册表所示，JWSs和JWEs共享一个公共头参数空间；当一个参数由两个规范使用时，其用法必须在两个规范之间兼容。
This parameter has the same meaning, syntax, and processing rules as the "alg" Header Parameter defined in Section 4.1.1 of [JWS], except that the Header Parameter identifies the cryptographic algorithm used to encrypt or determine the value of the CEK. The encrypted content is not usable if the "alg" value does not represent a supported algorithm, or if the recipient does not have a key that can be used with that algorithm.
该参数的含义、语法和处理规则与[JWS]第4.1.1节中定义的“alg”头参数相同，只是头参数标识了用于加密或确定CEK值的加密算法。如果“alg”值不表示支持的算法，或者如果收件人没有可用于该算法的密钥，则加密内容不可用。
A list of defined "alg" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 4.1 of [JWA].
可在[JWA]建立的IANA“JSON Web签名和加密算法”注册表中找到此用途定义的“alg”值列表；本注册表的初始内容为[JWA]第4.1节中定义的值。
The "enc" (encryption algorithm) Header Parameter identifies the content encryption algorithm used to perform authenticated encryption on the plaintext to produce the ciphertext and the Authentication Tag. This algorithm MUST be an AEAD algorithm with a specified key length. The encrypted content is not usable if the "enc" value does not represent a supported algorithm. "enc" values should either be registered in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The "enc" value is a case-sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations.
“enc”（encryption algorithm）头参数标识用于对明文执行身份验证加密以生成密文和身份验证标记的内容加密算法。此算法必须是具有指定密钥长度的AEAD算法。如果“enc”值不表示支持的算法，则加密内容不可用。“enc”值应该在[JWA]建立的IANA“JSON Web签名和加密算法”注册表中注册，或者是包含防冲突名称的值。“enc”值是一个区分大小写的ASCII字符串，包含StringOrURI值。此头参数必须存在，并且必须被实现理解和处理。
A list of defined "enc" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 5.1 of [JWA].
可在[JWA]建立的IANA“JSON Web签名和加密算法”注册表中找到此用途定义的“enc”值列表；本注册表的初始内容为[JWA]第5.1节中定义的值。
The "zip" (compression algorithm) applied to the plaintext before encryption, if any. The "zip" value defined by this specification is:
加密前应用于明文的“zip”（压缩算法），如果有的话。本规范定义的“zip”值为：
o "DEF" - Compression with the DEFLATE [RFC1951] algorithm
o “DEF”-使用DEFLATE[RFC1951]算法进行压缩
Other values MAY be used. Compression algorithm values can be registered in the IANA "JSON Web Encryption Compression Algorithms" registry established by [JWA]. The "zip" value is a case-sensitive string. If no "zip" parameter is present, no compression is applied to the plaintext before encryption. When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the
可以使用其他值。压缩算法值可以在[JWA]建立的IANA“JSON Web加密压缩算法”注册表中注册。“zip”值是区分大小写的字符串。如果不存在“zip”参数，则在加密之前不会对明文应用压缩。使用时，此标头参数必须受完整性保护；因此，它必须只发生在
JWE Protected Header. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations.
JWE保护头。此标头参数的使用是可选的。实现必须理解和处理此头参数。
This parameter has the same meaning, syntax, and processing rules as the "jku" Header Parameter defined in Section 4.1.2 of [JWS], except that the JWK Set resource contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
该参数的含义、语法和处理规则与[JWS]第4.1.2节中定义的“jku”头参数相同，只是JWK集合资源包含JWE加密的公钥；这可用于确定解密JWE所需的私钥。
This parameter has the same meaning, syntax, and processing rules as the "jwk" Header Parameter defined in Section 4.1.3 of [JWS], except that the key is the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
该参数的含义、语法和处理规则与[JWS]第4.1.3节中定义的“jwk”头参数相同，但密钥是JWE加密的公钥；这可用于确定解密JWE所需的私钥。
This parameter has the same meaning, syntax, and processing rules as the "kid" Header Parameter defined in Section 4.1.4 of [JWS], except that the key hint references the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. This parameter allows originators to explicitly signal a change of key to JWE recipients.
该参数的含义、语法和处理规则与[JWS]第4.1.4节中定义的“kid”头参数相同，但密钥提示引用了JWE加密的公钥；这可用于确定解密JWE所需的私钥。此参数允许发起者向JWE收件人显式发送密钥更改信号。
This parameter has the same meaning, syntax, and processing rules as the "x5u" Header Parameter defined in Section 4.1.5 of [JWS], except that the X.509 public key certificate or certificate chain [RFC5280] contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
该参数的含义、语法和处理规则与[JWS]第4.1.5节中定义的“x5u”头参数相同，但X.509公钥证书或证书链[RFC5280]包含JWE加密到的公钥；这可用于确定解密JWE所需的私钥。
This parameter has the same meaning, syntax, and processing rules as the "x5c" Header Parameter defined in Section 4.1.6 of [JWS], except that the X.509 public key certificate or certificate chain [RFC5280] contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
该参数的含义、语法和处理规则与[JWS]第4.1.6节中定义的“x5c”头参数相同，但X.509公钥证书或证书链[RFC5280]包含JWE加密的公钥；这可用于确定解密JWE所需的私钥。
See Appendix B of [JWS] for an example "x5c" value.
关于“x5c”值的示例，请参见[JWS]的附录B。
This parameter has the same meaning, syntax, and processing rules as the "x5t" Header Parameter defined in Section 4.1.7 of [JWS], except that the certificate referenced by the thumbprint contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. Note that certificate thumbprints are also sometimes known as certificate fingerprints.
该参数的含义、语法和处理规则与[JWS]第4.1.7节中定义的“x5t”头参数相同，只是指纹引用的证书包含JWE加密的公钥；这可用于确定解密JWE所需的私钥。请注意，证书指纹有时也称为证书指纹。
4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header Parameter
4.1.10. “x5t#S256”（X.509证书SHA-256指纹）标题参数
This parameter has the same meaning, syntax, and processing rules as the "x5t#S256" Header Parameter defined in Section 4.1.8 of [JWS], except that the certificate referenced by the thumbprint contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. Note that certificate thumbprints are also sometimes known as certificate fingerprints.
该参数的含义、语法和处理规则与[JWS]第4.1.8节中定义的“x5t#S256”头参数相同，只是指纹引用的证书包含JWE加密的公钥；这可用于确定解密JWE所需的私钥。请注意，证书指纹有时也称为证书指纹。
This parameter has the same meaning, syntax, and processing rules as the "typ" Header Parameter defined in Section 4.1.9 of [JWS], except that the type is that of this complete JWE.
该参数的含义、语法和处理规则与[JWS]第4.1.9节中定义的“typ”头参数相同，只是类型与完整的JWE相同。
This parameter has the same meaning, syntax, and processing rules as the "cty" Header Parameter defined in Section 4.1.10 of [JWS], except that the type is that of the secured content (the plaintext).
该参数的含义、语法和处理规则与[JWS]第4.1.10节中定义的“cty”头参数相同，只是类型为安全内容（明文）。
This parameter has the same meaning, syntax, and processing rules as the "crit" Header Parameter defined in Section 4.1.11 of [JWS], except that Header Parameters for a JWE are being referred to, rather than Header Parameters for a JWS.
该参数与[JWS]第4.1.11节中定义的“crit”头参数具有相同的含义、语法和处理规则，只是所指的是JWE的头参数，而不是JWS的头参数。
Additional Header Parameter names can be defined by those using JWEs. However, in order to prevent collisions, any new Header Parameter name should either be registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable
使用JWEs的用户可以定义其他头参数名称。但是，为了防止冲突，任何新的头参数名称都应该在[JWS]建立的IANA“JSON Web签名和加密头参数”注册表中注册，或者是一个公共名称：一个包含抗冲突名称的值。在每种情况下，名称或值的定义者都需要采取合理的措施
precautions to make sure they are in control of the part of the namespace they use to define the Header Parameter name.
注意事项，以确保它们控制用于定义标头参数名称的命名空间部分。
New Header Parameters should be introduced sparingly, as they can result in non-interoperable JWEs.
应该谨慎地引入新的头参数，因为它们可能导致不可互操作的JWE。
A producer and consumer of a JWE may agree to use Header Parameter names that are Private Names: names that are not Registered Header Parameter names (Section 4.1) or Public Header Parameter names (Section 4.2). Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution.
JWE的生产者和消费者可能同意使用私有名称的头参数名称：未注册的头参数名称（第4.1节）或公共头参数名称（第4.2节）。与公共标头参数名称不同，私有标头参数名称会发生冲突，应谨慎使用。
The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
消息加密过程如下所示。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。
1. Determine the Key Management Mode employed by the algorithm used to determine the Content Encryption Key value. (This is the algorithm recorded in the "alg" (algorithm) Header Parameter of the resulting JWE.)
1. 确定用于确定内容加密密钥值的算法所采用的密钥管理模式。（这是结果JWE的“alg”（algorithm）头参数中记录的算法。）
2. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, generate a random CEK value. See RFC 4086 [RFC4086] for considerations on generating random values. The CEK MUST have a length equal to that required for the content encryption algorithm.
2. 当使用密钥包装、密钥加密或密钥协议与密钥包装时，生成一个随机CEK值。有关生成随机值的注意事项，请参阅RFC 4086[RFC4086]。CEK的长度必须等于内容加密算法所需的长度。
3. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to wrap the CEK.
3. 当使用直接密钥协商或带密钥包装的密钥协商时，使用密钥协商算法计算约定密钥的值。当使用直接密钥协议时，让CEK成为商定的密钥。当使用带有密钥包装的密钥协议时，将使用商定的密钥包装CEK。
4. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, encrypt the CEK to the recipient and let the result be the JWE Encrypted Key.
4. 当使用密钥包装、密钥加密或密钥协议与密钥包装时，将CEK加密给接收方，并将结果作为JWE加密密钥。
5. When Direct Key Agreement or Direct Encryption are employed, let the JWE Encrypted Key be the empty octet sequence.
5. 当采用直接密钥协商或直接加密时，让JWE加密的密钥为空八位组序列。
6. When Direct Encryption is employed, let the CEK be the shared symmetric key.
6. 当使用直接加密时，让CEK成为共享对称密钥。
7. Compute the encoded key value BASE64URL(JWE Encrypted Key).
7. 计算编码密钥值BASE64URL（JWE加密密钥）。
8. If the JWE JSON Serialization is being used, repeat this process (steps 1-7) for each recipient.
8. 如果正在使用JWE JSON序列化，请对每个收件人重复此过程（步骤1-7）。
9. Generate a random JWE Initialization Vector of the correct size for the content encryption algorithm (if required for the algorithm); otherwise, let the JWE Initialization Vector be the empty octet sequence.
9. 为内容加密算法生成大小正确的随机JWE初始化向量（如果算法需要）；否则，将JWE初始化向量设为空八位组序列。
10. Compute the encoded Initialization Vector value BASE64URL(JWE Initialization Vector).
10. 计算编码的初始化向量值BASE64URL（JWE初始化向量）。
11. If a "zip" parameter was included, compress the plaintext using the specified compression algorithm and let M be the octet sequence representing the compressed plaintext; otherwise, let M be the octet sequence representing the plaintext.
11. 如果包含“zip”参数，则使用指定的压缩算法压缩明文，并将M设为表示压缩明文的八位字节序列；否则，设M为表示明文的八位字节序列。
12. Create the JSON object(s) containing the desired set of Header Parameters, which together comprise the JOSE Header: one or more of the JWE Protected Header, the JWE Shared Unprotected Header, and the JWE Per-Recipient Unprotected Header.
12. 创建包含所需的头参数集的JSON对象，这些头参数共同组成JOSE头：一个或多个JWE受保护头、JWE共享未受保护头和JWE每个收件人未受保护头。
13. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no "protected" member is present), let this value be the empty string.
13. 计算编码的受保护标头值BASE64URL（UTF8（JWE受保护标头））。如果JWE受保护的头不存在（这只能在使用JWE JSON序列化且不存在“受保护”成员时发生），则将此值设为空字符串。
14. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).
14. 让附加的认证数据加密参数为ASCII（编码的受保护标头）。但是，如果存在JWE AAD值（只有在使用JWE JSON序列化时才会出现这种情况），则将附加的经过身份验证的数据加密参数改为ASCII（编码的受保护标头| |'。| | BASE64URL（JWE AAD））。
15. Encrypt M using the CEK, the JWE Initialization Vector, and the Additional Authenticated Data value using the specified content encryption algorithm to create the JWE Ciphertext value and the JWE Authentication Tag (which is the Authentication Tag output from the encryption operation).
15. 使用CEK、JWE初始化向量和使用指定内容加密算法的附加认证数据值加密M，以创建JWE密文值和JWE认证标记（这是加密操作输出的认证标记）。
16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).
16. 计算编码的密文值BASE64URL（JWE-ciphertext）。
17. Compute the encoded Authentication Tag value BASE64URL(JWE Authentication Tag).
17. 计算编码的身份验证标记值BASE64URL（JWE身份验证标记）。
18. If a JWE AAD value is present, compute the encoded AAD value BASE64URL(JWE AAD).
18. 如果存在JWE AAD值，则计算编码的AAD值BASE64URL（JWE AAD）。
19. Create the desired serialized output. The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The JWE JSON Serialization is described in Section 7.2.
19. 创建所需的序列化输出。此结果的紧凑序列化是字符串BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| BASE64URL（JWE身份验证标记）。第7.2节描述了JWE JSON序列化。
The message decryption process is the reverse of the encryption process. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of these steps fail, the encrypted content cannot be validated.
消息解密过程与加密过程相反。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。如果其中任何一个步骤失败，则无法验证加密内容。
When there are multiple recipients, it is an application decision which of the recipients' encrypted content must successfully validate for the JWE to be accepted. In some cases, encrypted content for all recipients must successfully validate or the JWE will be considered invalid. In other cases, only the encrypted content for a single recipient needs to be successfully validated. However, in all cases, the encrypted content for at least one recipient MUST successfully validate or the JWE MUST be considered invalid.
当有多个收件人时，应用程序决定必须成功验证哪个收件人的加密内容才能接受JWE。在某些情况下，必须成功验证所有收件人的加密内容，否则JWE将被视为无效。在其他情况下，只需成功验证单个收件人的加密内容。但是，在所有情况下，必须成功验证至少一个收件人的加密内容，否则JWE必须被视为无效。
1. Parse the JWE representation to extract the serialized values for the components of the JWE. When using the JWE Compact Serialization, these components are the base64url-encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag, and when using the JWE JSON Serialization, these components also include the base64url-encoded representation of the JWE AAD and the unencoded JWE Shared Unprotected Header and JWE Per-Recipient Unprotected Header values. When using the JWE Compact Serialization, the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag are represented as base64url-encoded values in that order, with each value being separated from the next by a single period ('.') character, resulting in exactly four delimiting period characters being used. The JWE JSON Serialization is described in Section 7.2.
1. 解析JWE表示以提取JWE组件的序列化值。当使用JWE压缩序列化时，这些组件是JWE保护头、JWE加密密钥、JWE初始化向量、JWE密文和JWE身份验证标记的base64url编码表示，当使用JWE JSON序列化时，这些组件还包括JWE AAD的base64url编码表示，以及未编码的JWE共享无保护头和JWE每个收件人无保护头值。使用JWE压缩序列化时，JWE受保护的标头、JWE加密密钥、JWE初始化向量、JWE密文和JWE身份验证标记按顺序表示为base64url编码值，每个值与下一个值之间用单个句点（'.'）字符分隔，结果正好使用了四个定界周期字符。第7.2节描述了JWE JSON序列化。
2. Base64url decode the encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, the JWE Authentication Tag, and the JWE AAD, following the restriction that no line breaks, whitespace, or other additional characters have been used.
2. Base64url解码JWE保护标头、JWE加密密钥、JWE初始化向量、JWE密文、JWE身份验证标记和JWE AAD的编码表示形式，并遵守未使用换行符、空白或其他附加字符的限制。
3. Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWE Protected Header be this JSON object.
3. 验证解码编码的JWE保护报头所产生的八位字节序列是完全有效的JSON对象的UTF-8编码表示，符合RFC 7159[RFC7159]；让JWE受保护的头是这个JSON对象。
4. If using the JWE Compact Serialization, let the JOSE Header be the JWE Protected Header. Otherwise, when using the JWE JSON Serialization, let the JOSE Header be the union of the members of the JWE Protected Header, the JWE Shared Unprotected Header and the corresponding JWE Per-Recipient Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWE JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header.
4. 如果使用JWE压缩序列化，则让JOSE头成为JWE保护头。否则，在使用JWE JSON序列化时，让JOSE头成为JWE受保护头、JWE共享未受保护头和对应的JWE每个收件人未受保护头的成员的并集，所有这些都必须是完全有效的JSON对象。在此步骤中，验证生成的JOSE标头不包含重复的标头参数名称。使用JWE JSON序列化时，此限制包括相同的头参数名称也不得出现在共同构成JOSE头的不同JSON对象值中。
5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithms being used, or by the "crit" Header Parameter value, and that the values of those parameters are also understood and supported.
5. 验证实现是否理解并能够处理其需要支持的所有字段，无论是本规范、所用算法还是“crit”头参数值要求的字段，以及这些参数的值是否也被理解和支持。
6. Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter.
6. 确定由“alg”（algorithm）头参数指定的算法所采用的密钥管理模式。
7. Verify that the JWE uses a key known to the recipient.
7. 验证JWE是否使用收件人已知的密钥。
8. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to decrypt the JWE Encrypted Key.
8. 当使用直接密钥协商或带密钥包装的密钥协商时，使用密钥协商算法计算约定密钥的值。当使用直接密钥协议时，让CEK成为商定的密钥。当使用带密钥包装的密钥协议时，将使用约定的密钥解密JWE加密密钥。
9. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content encryption algorithm. Note that when there are multiple recipients, each recipient will only be able to decrypt JWE Encrypted Key values that were encrypted to a key in that recipient's possession. It is therefore normal to only be able
9. 当使用密钥包装、密钥加密或密钥协议与密钥包装时，解密JWE加密密钥以生成CEK。CEK的长度必须等于内容加密算法所需的长度。请注意，当有多个收件人时，每个收件人将只能对加密为该收件人拥有的密钥的JWE加密密钥值进行解密。因此，只有能够
to decrypt one of the per-recipient JWE Encrypted Key values to obtain the CEK value. Also, see Section 11.5 for security considerations on mitigating timing attacks.
要解密每个收件人的一个JWE加密密钥值以获得CEK值。此外，有关缓解定时攻击的安全注意事项，请参见第11.5节。
10. When Direct Key Agreement or Direct Encryption are employed, verify that the JWE Encrypted Key value is an empty octet sequence.
10. 当使用直接密钥协议或直接加密时，请验证JWE加密的密钥值是否为空八位字节序列。
11. When Direct Encryption is employed, let the CEK be the shared symmetric key.
11. 当使用直接加密时，让CEK成为共享对称密钥。
12. Record whether the CEK could be successfully determined for this recipient or not.
12. 记录是否可以成功确定此收件人的CEK。
13. If the JWE JSON Serialization is being used, repeat this process (steps 4-12) for each recipient contained in the representation.
13. 如果正在使用JWE JSON序列化，请对表示中包含的每个收件人重复此过程（步骤4-12）。
14. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no "protected" member is present), let this value be the empty string.
14. 计算编码的受保护标头值BASE64URL（UTF8（JWE受保护标头））。如果JWE受保护的头不存在（这只能在使用JWE JSON序列化且不存在“受保护”成员时发生），则将此值设为空字符串。
15. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).
15. 让附加的认证数据加密参数为ASCII（编码的受保护标头）。但是，如果存在JWE AAD值（只有在使用JWE JSON序列化时才会出现这种情况），则将附加的经过身份验证的数据加密参数改为ASCII（编码的受保护标头| |'。| | BASE64URL（JWE AAD））。
16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect.
16. 使用指定的内容加密算法，使用CEK、JWE初始化向量、附加认证数据值和JWE认证标签（输入到计算中的认证标签）解密JWE密文，返回解密的明文，并以为算法指定的方式验证JWE身份验证标记，如果JWE身份验证标记不正确，则拒绝输入而不发出任何解密的输出。
17. If a "zip" parameter was included, uncompress the decrypted plaintext using the specified compression algorithm.
17. 如果包含“zip”参数，请使用指定的压缩算法解压缩解密的明文。
18. If there was no recipient for which all of the decryption steps succeeded, then the JWE MUST be considered invalid. Otherwise, output the plaintext. In the JWE JSON Serialization case, also return a result to the application indicating for which of the recipients the decryption succeeded and failed.
18. 如果没有成功完成所有解密步骤的收件人，那么JWE必须被视为无效。否则，输出纯文本。在JWE JSON序列化案例中，还向应用程序返回一个结果，指示解密成功和失败的收件人。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWE can be successfully decrypted, unless the algorithms used in the JWE are acceptable to the application, it SHOULD consider the JWE to be invalid.
最后，请注意，在给定上下文中可以使用哪些算法是应用程序的决定。即使JWE可以被成功解密，除非JWE中使用的算法对应用程序是可接受的，它应该考虑JWE无效。
The string comparison rules for this specification are the same as those defined in Section 5.3 of [JWS].
本规范的字符串比较规则与[JWS]第5.3节中定义的相同。
The key identification methods for this specification are the same as those defined in Section 6 of [JWS], except that the key being identified is the public key to which the JWE was encrypted.
本规范的密钥识别方法与[JWS]第6节中定义的方法相同，不同之处在于所识别的密钥是对JWE进行加密的公钥。
JWEs use one of two serializations: the JWE Compact Serialization or the JWE JSON Serialization. Applications using this specification need to specify what serialization and serialization features are used for that application. For instance, applications might specify that only the JWE JSON Serialization is used, that only JWE JSON Serialization support for a single recipient is used, or that support for multiple recipients is used. JWE implementations only need to implement the features needed for the applications they are designed to support.
JWE使用两种序列化之一：JWE压缩序列化或JWE JSON序列化。使用此规范的应用程序需要指定该应用程序使用的序列化和序列化功能。例如，应用程序可能指定只使用JWE JSON序列化，只使用对单个收件人的JWE JSON序列化支持，或者使用对多个收件人的支持。JWE实现只需要实现其设计支持的应用程序所需的功能。
The JWE Compact Serialization represents encrypted content as a compact, URL-safe string. This string is:
JWE Compact序列化将加密内容表示为紧凑的URL安全字符串。此字符串是：
BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag)
BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| BASE64URL（JWE身份验证标记）
Only one recipient is supported by the JWE Compact Serialization and it provides no syntax to represent JWE Shared Unprotected Header, JWE Per-Recipient Unprotected Header, or JWE AAD values.
JWE Compact序列化只支持一个收件人，它不提供语法来表示JWE共享的未保护标头、JWE每个收件人未保护标头或JWE AAD值。
The JWE JSON Serialization represents encrypted content as a JSON object. This representation is neither optimized for compactness nor URL safe.
JWE JSON序列化将加密内容表示为JSON对象。此表示既不优化紧凑性，也不优化URL安全性。
Two closely related syntaxes are defined for the JWE JSON Serialization: a fully general syntax, with which content can be encrypted to more than one recipient, and a flattened syntax, which is optimized for the single-recipient case.
JWE JSON序列化定义了两种密切相关的语法：一种完全通用的语法，使用它可以将内容加密到多个收件人；另一种是扁平语法，它针对单个收件人的情况进行了优化。
The following members are defined for use in top-level JSON objects used for the fully general JWE JSON Serialization syntax:
定义了以下成员，以便在用于完全通用JWE JSON序列化语法的顶级JSON对象中使用：
protected The "protected" member MUST be present and contain the value BASE64URL(UTF8(JWE Protected Header)) when the JWE Protected Header value is non-empty; otherwise, it MUST be absent. These Header Parameter values are integrity protected.
受保护当JWE受保护标头值为非空时，“受保护”成员必须存在并包含值BASE64URL（UTF8（JWE受保护标头））；否则，它必须缺席。这些标头参数值受完整性保护。
unprotected The "unprotected" member MUST be present and contain the value JWE Shared Unprotected Header when the JWE Shared Unprotected Header value is non-empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
unprotected当JWE Shared unprotected Header值为非空时，“unprotected”成员必须存在并包含值JWE Shared unprotected Header；否则，它必须缺席。此值表示为未编码的JSON对象，而不是字符串。这些标头参数值不受完整性保护。
iv The "iv" member MUST be present and contain the value BASE64URL(JWE Initialization Vector) when the JWE Initialization Vector value is non-empty; otherwise, it MUST be absent.
iv当JWE初始化向量值为非空时，“iv”成员必须存在并包含值BASE64URL（JWE初始化向量）；否则，它必须缺席。
aad The "aad" member MUST be present and contain the value BASE64URL(JWE AAD)) when the JWE AAD value is non-empty; otherwise, it MUST be absent. A JWE AAD value can be included to supply a base64url-encoded value to be integrity protected but not encrypted.
aad当JWE aad值为非空时，“aad”成员必须存在并包含值BASE64URL（JWE aad））；否则，它必须缺席。可以包含一个JWE AAD值，以提供一个base64url编码值，该值受完整性保护，但不加密。
ciphertext The "ciphertext" member MUST be present and contain the value BASE64URL(JWE Ciphertext).
ciphertext“ciphertext”成员必须存在并包含值BASE64URL（JWE ciphertext）。
tag The "tag" member MUST be present and contain the value BASE64URL(JWE Authentication Tag) when the JWE Authentication Tag value is non-empty; otherwise, it MUST be absent.
标记当JWE身份验证标记值为非空时，“标记”成员必须存在并包含值BASE64URL（JWE身份验证标记）；否则，它必须缺席。
recipients The "recipients" member value MUST be an array of JSON objects. Each object contains information specific to a single recipient. This member MUST be present with exactly one array element per
recipients“recipients”成员值必须是JSON对象数组。每个对象都包含特定于单个收件人的信息。每个成员必须正好有一个数组元素
recipient, even if some or all of the array element values are the empty JSON object "{}" (which can happen when all Header Parameter values are shared between all recipients and when no encrypted key is used, such as when doing Direct Encryption).
收件人，即使部分或全部数组元素值是空的JSON对象“{}”（当所有收件人之间共享所有头参数值并且未使用加密密钥时，例如在执行直接加密时，可能会发生这种情况）。
The following members are defined for use in the JSON objects that are elements of the "recipients" array:
定义了以下成员，以便在作为“收件人”数组元素的JSON对象中使用：
header The "header" member MUST be present and contain the value JWE Per-Recipient Unprotected Header when the JWE Per-Recipient Unprotected Header value is non-empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
header当JWE Per RECTIVER Unprotected header值为非空时，“header”成员必须存在并包含值JWE Per RECTIVER Unprotected header；否则，它必须缺席。此值表示为未编码的JSON对象，而不是字符串。这些标头参数值不受完整性保护。
encrypted_key The "encrypted_key" member MUST be present and contain the value BASE64URL(JWE Encrypted Key) when the JWE Encrypted Key value is non-empty; otherwise, it MUST be absent.
加密密钥当JWE加密密钥值为非空时，“加密密钥”成员必须存在并包含值BASE64URL（JWE加密密钥）；否则，它必须缺席。
At least one of the "header", "protected", and "unprotected" members MUST be present so that "alg" and "enc" Header Parameter values are conveyed for each recipient computation.
“header”、“protected”和“unprotected”成员中必须至少有一个存在，以便为每个收件人计算传递“alg”和“enc”header参数值。
Additional members can be present in both the JSON objects defined above; if not understood by implementations encountering them, they MUST be ignored.
在上面定义的两个JSON对象中都可以存在其他成员；如果遇到它们的实现无法理解它们，则必须忽略它们。
Some Header Parameters, including the "alg" parameter, can be shared among all recipient computations. Header Parameters in the JWE Protected Header and JWE Shared Unprotected Header values are shared among all recipients.
一些标头参数，包括“alg”参数，可以在所有收件人计算中共享。JWE受保护标头和JWE共享未受保护标头值中的标头参数在所有收件人之间共享。
The Header Parameter values used when creating or validating per-recipient ciphertext and Authentication Tag values are the union of the three sets of Header Parameter values that may be present: (1) the JWE Protected Header represented in the "protected" member, (2) the JWE Shared Unprotected Header represented in the "unprotected" member, and (3) the JWE Per-Recipient Unprotected Header represented in the "header" member of the recipient's array element. The union of these sets of Header Parameters comprises the JOSE Header. The Header Parameter names in the three locations MUST be disjoint.
创建或验证每个收件人密文和身份验证标记值时使用的头参数值是可能存在的三组头参数值的并集：（1）在“受保护”成员中表示的JWE受保护头，（2）在“未受保护”成员中表示的JWE共享未受保护头，以及（3）在收件人数组元素的“Header”成员中表示的JWE Per Recipient Unprotected标头。这些标头参数集的并集包括JOSE标头。三个位置中的标头参数名称必须不相交。
Each JWE Encrypted Key value is computed using the parameters of the corresponding JOSE Header value in the same manner as for the JWE Compact Serialization. This has the desirable property that each JWE Encrypted Key value in the "recipients" array is identical to the
每个JWE加密的密钥值都是使用相应JOSE头值的参数计算的，计算方式与JWE紧凑序列化相同。这有一个可取的属性，即“recipients”数组中的每个JWE加密密钥值都与
value that would have been computed for the same parameter in the JWE Compact Serialization. Likewise, the JWE Ciphertext and JWE Authentication Tag values match those produced for the JWE Compact Serialization, provided that the JWE Protected Header value (which represents the integrity-protected Header Parameter values) matches that used in the JWE Compact Serialization.
为JWE紧凑序列化中的相同参数计算的值。同样，JWE密文和JWE身份验证标记值与为JWE压缩序列化生成的值匹配，前提是JWE保护的头值（表示完整性保护的头参数值）与JWE压缩序列化中使用的值匹配。
All recipients use the same JWE Protected Header, JWE Initialization Vector, JWE Ciphertext, and JWE Authentication Tag values, when present, resulting in potentially significant space savings if the message is large. Therefore, all Header Parameters that specify the treatment of the plaintext value MUST be the same for all recipients. This primarily means that the "enc" (encryption algorithm) Header Parameter value in the JOSE Header for each recipient and any parameters of that algorithm MUST be the same.
所有收件人使用相同的JWE保护标头、JWE初始化向量、JWE密文和JWE身份验证标记值（如果存在），如果消息较大，则可能会显著节省空间。因此，指定明文值处理方式的所有标头参数对于所有收件人都必须相同。这主要意味着每个收件人的JOSE标头中的“enc”（加密算法）标头参数值以及该算法的任何参数必须相同。
In summary, the syntax of a JWE using the general JWE JSON Serialization is as follows:
总之，使用通用JWE JSON序列化的JWE的语法如下：
{
"protected":"<integrity-protected shared header contents>",
"unprotected":<non-integrity-protected shared header contents>,
"recipients":[
{"header":<per-recipient unprotected header 1 contents>,
"encrypted_key":"<encrypted key 1 contents>"},
...
{"header":<per-recipient unprotected header N contents>,
"encrypted_key":"<encrypted key N contents>"}],
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
{
"protected":"<integrity-protected shared header contents>",
"unprotected":<non-integrity-protected shared header contents>,
"recipients":[
{"header":<per-recipient unprotected header 1 contents>,
"encrypted_key":"<encrypted key 1 contents>"},
...
{"header":<per-recipient unprotected header N contents>,
"encrypted_key":"<encrypted key N contents>"}],
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
See Appendix A.4 for an example JWE using the general JWE JSON Serialization syntax.
有关使用通用JWE JSON序列化语法的JWE示例，请参见附录A.4。
The flattened JWE JSON Serialization syntax is based upon the general syntax, but flattens it, optimizing it for the single-recipient case. It flattens it by removing the "recipients" member and instead placing those members defined for use in the "recipients" array (the "header" and "encrypted_key" members) in the top-level JSON object (at the same level as the "ciphertext" member).
扁平化JWE JSON序列化语法基于通用语法，但将其扁平化，针对单个收件人情况对其进行优化。它通过删除“recipients”成员并将定义用于“recipients”数组的成员（“header”和“encrypted_key”成员）放在顶级JSON对象（与“ciphertext”成员处于同一级别）中，来将其展平。
The "recipients" member MUST NOT be present when using this syntax. Other than this syntax difference, JWE JSON Serialization objects using the flattened syntax are processed identically to those using the general syntax.
使用此语法时，“收件人”成员不得出现。除了这种语法差异之外，使用平坦语法的JWE JSON序列化对象的处理方式与使用常规语法的JWE JSON序列化对象的处理方式相同。
In summary, the syntax of a JWE using the flattened JWE JSON Serialization is as follows:
总之，使用平坦JWE JSON序列化的JWE的语法如下：
{
"protected":"<integrity-protected header contents>",
"unprotected":<non-integrity-protected header contents>,
"header":<more non-integrity-protected header contents>,
"encrypted_key":"<encrypted key contents>",
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
{
"protected":"<integrity-protected header contents>",
"unprotected":<non-integrity-protected header contents>,
"header":<more non-integrity-protected header contents>,
"encrypted_key":"<encrypted key contents>",
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
Note that when using the flattened syntax, just as when using the general syntax, any unprotected Header Parameter values can reside in either the "unprotected" member or the "header" member, or in both.
请注意，使用展开语法时，与使用常规语法时一样，任何未受保护的标头参数值都可以位于“未受保护”成员或“标头”成员中，或同时位于这两个成员中。
See Appendix A.5 for an example JWE using the flattened JWE JSON Serialization syntax.
有关使用扁平化JWE JSON序列化语法的JWE示例，请参见附录A.5。
The Transport Layer Security (TLS) requirements for this specification are the same as those defined in Section 8 of [JWS].
本规范的传输层安全（TLS）要求与[JWS]第8节中定义的要求相同。
There are several ways of distinguishing whether an object is a JWS or JWE. All these methods will yield the same result for all legal input values; they may yield different results for malformed inputs.
有几种方法可以区分对象是JWS还是JWE。所有这些方法将为所有合法输入值产生相同的结果；对于格式错误的输入，它们可能会产生不同的结果。
o If the object is using the JWS Compact Serialization or the JWE Compact Serialization, the number of base64url-encoded segments separated by period ('.') characters differs for JWSs and JWEs. JWSs have three segments separated by two period ('.') characters. JWEs have five segments separated by four period ('.') characters.
o 如果对象正在使用JWS紧凑序列化或JWE紧凑序列化，则JWSs和JWEs的base64url编码段的数量因句点（'.'）字符而异。JWS有三个段，由两个句点（'.'）字符分隔。JWE有五个段，由四个句号（'.'）字符分隔。
o If the object is using the JWS JSON Serialization or the JWE JSON Serialization, the members used will be different. JWSs have a "payload" member and JWEs do not. JWEs have a "ciphertext" member and JWSs do not.
o 如果对象使用JWS JSON序列化或JWE JSON序列化，则使用的成员将不同。JWS有一个“有效负载”成员，而JWE没有。JWE有一个“密文”成员，而JWSs没有。
o The JOSE Header for a JWS can be distinguished from the JOSE Header for a JWE by examining the "alg" (algorithm) Header Parameter value. If the value represents a digital signature or MAC algorithm, or is the value "none", it is for a JWS; if it represents a Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, or Direct Encryption algorithm, it is for a JWE. (Extracting the "alg" value to examine is straightforward when using the JWS Compact Serialization or the JWE Compact Serialization and may be more difficult when using the JWS JSON Serialization or the JWE JSON Serialization.)
o 通过检查“alg”（算法）头参数值，可以将JWS的JOSE头与JWE的JOSE头区分开来。如果该值表示数字签名或MAC算法，或为“无”，则表示JWS；如果它表示密钥加密、密钥包装、直接密钥协议、密钥协议与密钥包装或直接加密算法，则它适用于JWE。（在使用JWS紧凑序列化或JWE紧凑序列化时，提取要检查的“alg”值是很简单的，而在使用JWS JSON序列化或JWE JSON序列化时，提取要检查的“alg”值可能更困难。）
o The JOSE Header for a JWS can also be distinguished from the JOSE Header for a JWE by determining whether an "enc" (encryption algorithm) member exists. If the "enc" member exists, it is a JWE; otherwise, it is a JWS.
o 通过确定是否存在“enc”（加密算法）成员，还可以将JWS的JOSE头与JWE的JOSE头区分开来。如果“enc”成员存在，则为JWE；否则，它就是JWS。
This section registers the Header Parameter names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS].
本节在[JWS]建立的IANA“JSON Web签名和加密头参数”注册表中注册第4.1节中定义的头参数名称。
o Header Parameter Name: "alg" o Header Parameter Description: Algorithm o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7516
o 标题参数名称：“alg”o标题参数说明：算法o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.1节
o Header Parameter Name: "enc" o Header Parameter Description: Encryption Algorithm o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7516
o 标题参数名称：“enc”o标题参数说明：加密算法o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.2节
o Header Parameter Name: "zip" o Header Parameter Description: Compression Algorithm o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.3 of RFC 7516
o 标题参数名称：“zip”o标题参数说明：压缩算法o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.3节
o Header Parameter Name: "jku" o Header Parameter Description: JWK Set URL o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.4 of RFC 7516
o 标题参数名称：“jku”o标题参数说明：JWK设置URL o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.4节
o Header Parameter Name: "jwk" o Header Parameter Description: JSON Web Key o Header Parameter Usage Location(s): JWE
o 标头参数名称：“jwk”o标头参数说明：JSON Web键o标头参数使用位置：JWE
o Change Controller: IESG o Specification Document(s): Section 4.1.5 of RFC 7516
o 变更控制员：IESG o规范文件：RFC 7516第4.1.5节
o Header Parameter Name: "kid" o Header Parameter Description: Key ID o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.6 of RFC 7516
o 标题参数名称：“kid”o标题参数说明：密钥ID o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.6节
o Header Parameter Name: "x5u" o Header Parameter Description: X.509 URL o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7516
o 标题参数名称：“x5u”o标题参数说明：X.509 URL o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.7节
o Header Parameter Name: "x5c" o Header Parameter Description: X.509 Certificate Chain o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.8 of RFC 7516
o 标题参数名称：“x5c”o标题参数说明：X.509证书链o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.8节
o Header Parameter Name: "x5t" o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.9 of RFC 7516
o 标题参数名称：“x5t”o标题参数说明：X.509证书SHA-1指纹o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.9节
o Header Parameter Name: "x5t#S256" o Header Parameter Description: X.509 Certificate SHA-256 Thumbprint o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.10 of RFC 7516
o 标题参数名称：“x5t#S256”o标题参数说明：X.509证书SHA-256指纹o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.10节
o Header Parameter Name: "typ" o Header Parameter Description: Type o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.11 of RFC 7516
o 标题参数名称：“类型”o标题参数说明：类型o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.11节
o Header Parameter Name: "cty" o Header Parameter Description: Content Type o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.12 of RFC 7516
o 标题参数名称：“cty”o标题参数说明：内容类型o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7516第4.1.12节
o Header Parameter Name: "crit" o Header Parameter Description: Critical o Header Parameter Usage Location(s): JWE
o 标题参数名称：“crit”o标题参数说明：关键o标题参数使用位置：JWE
o Change Controller: IESG o Specification Document(s): Section 4.1.13 of RFC 7516
o 变更控制员：IESG o规范文件：RFC 7516第4.1.13节
All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
与任何加密应用程序相关的所有安全问题都必须由JWS/JWE/JWK代理解决。这些问题包括保护用户的非对称私钥和对称密钥以及对各种攻击采取对策。
All the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific.
JWS规范中的所有安全注意事项也适用于本规范。同样，XML Encryption 1.1[W3C.REC-xmlenc-core1-20130411]中的所有安全注意事项也适用，但特定于XML的除外。
See Section 10.1 of [JWS] for security considerations on key entropy and random values. In addition to the uses of random values listed there, note that random values are also used for Content Encryption Keys (CEKs) and Initialization Vectors (IVs) when performing encryption.
有关密钥熵和随机值的安全注意事项，请参见[JWS]第10.1节。除了使用此处列出的随机值外，请注意，在执行加密时，随机值还用于内容加密密钥（CEK）和初始化向量（IV）。
See Section 10.2 of [JWS] for security considerations on key protection. In addition to the keys listed there that must be protected, implementations performing encryption must protect the key encryption key and the Content Encryption Key. Compromise of the key encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the Content Encryption Key may result in disclosure of the associated encrypted content.
有关密钥保护的安全注意事项，请参见[JWS]第10.2节。除了此处列出的必须保护的密钥外，执行加密的实现还必须保护密钥加密密钥和内容加密密钥。密钥加密密钥的泄露可能会导致泄露使用该密钥保护的所有内容。类似地，内容加密密钥的泄露可能导致相关加密内容的泄露。
Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, using the same key size is recommended when AES GCM is also used. If the key encryption and content encryption algorithms are different, the effective security is determined by the weaker of the two algorithms.
匹配强度的算法应尽可能结合使用。例如，当AES密钥包装与给定的密钥大小一起使用时，如果还使用AES GCM，则建议使用相同的密钥大小。如果密钥加密和内容加密算法不同，则有效的安全性取决于两种算法中较弱的一种。
Also, see RFC 3766 [RFC3766] for information on determining strengths for public keys used for exchanging symmetric keys.
此外，有关确定用于交换对称密钥的公钥强度的信息，请参见RFC 3766[RFC3766]。
When decrypting, particular care must be taken not to allow the JWE recipient to be used as an oracle for decrypting messages. RFC 3218 [RFC3218] should be consulted for specific countermeasures to attacks on RSAES-PKCS1-v1_5. An attacker might modify the contents of the "alg" Header Parameter from "RSA-OAEP" to "RSA1_5" in order to generate a formatting error that can be detected and used to recover the CEK even if RSAES-OAEP was used to encrypt the CEK. It is therefore particularly important to report all formatting errors to the CEK, Additional Authenticated Data, or ciphertext as a single error when the encrypted content is rejected.
解密时，必须特别注意不要将JWE收件人用作oracle来解密消息。关于攻击RSAES-PKCS1-v1_5的具体对策，应咨询RFC 3218[RFC3218]。攻击者可能会将“alg”头参数的内容从“RSA-OAEP”修改为“RSA1_5”，以便生成可检测并用于恢复CEK的格式化错误，即使RSAES-OAEP用于加密CEK。因此，当加密内容被拒绝时，向CEK报告所有格式错误、附加认证数据或密文作为单个错误尤为重要。
Additionally, this type of attack can be prevented by restricting the use of a key to a limited set of algorithms -- usually one. This means, for instance, that if the key is marked as being for "RSA-OAEP" only, any attempt to decrypt a message using the "RSA1_5" algorithm with that key should fail immediately due to invalid use of the key.
此外，这种类型的攻击可以通过将密钥的使用限制在有限的一组算法（通常是一组）来防止。这意味着，例如，如果密钥被标记为仅用于“RSA-OAEP”，则由于密钥使用无效，任何使用该密钥的“RSA1_5”算法解密消息的尝试都应立即失败。
To mitigate the attacks described in RFC 3218 [RFC3218], the recipient MUST NOT distinguish between format, padding, and length errors of encrypted keys. It is strongly recommended, in the event of receiving an improperly formatted key, that the recipient substitute a randomly generated CEK and proceed to the next step, to mitigate timing attacks.
为了减轻RFC 3218[RFC3218]中描述的攻击，接收方不得区分加密密钥的格式、填充和长度错误。强烈建议在接收到格式不正确的密钥时，接收者替换随机生成的CEK并继续下一步，以减轻定时攻击。
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWA]Jones，M.，“JSON网络算法（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, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[JWK]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[JWS]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<http://www.rfc-editor.org/info/rfc7515>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC 1951，DOI 10.17487/RFC1951，1996年5月<http://www.rfc-editor.org/info/rfc1951>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[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>.
[AES]国家标准与技术研究所（NIST），“高级加密标准（AES）”，FIPS PUB 197，2001年11月<http://csrc.nist.gov/publications/ fips/fips197/fips-197.pdf>。
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple Encryption", September 2010, <http://jsonenc.info/enc/1.0/>.
[JSE]Bradley，J.和N.Sakimura（编辑），“JSON简单加密”，2010年9月<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.
[JSMS]Rescorla，E.和J.Hildebrand，“JavaScript消息安全格式”，正在进行的工作，草稿-Rescorla-JSMS-00，2011年3月。
[NIST.800-38D] National Institute of Standards and Technology (NIST), "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, November 2007, <http://csrc.nist.gov/publications/ nistpubs/800-38D/SP-800-38D.pdf>.
[NIST.800-38D]国家标准与技术研究所（NIST），“分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，NIST PUB 800-38D，2007年11月<http://csrc.nist.gov/publications/ nistpubs/800-38D/SP-800-38D.pdf>。
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, DOI 10.17487/RFC3218, January 2002, <http://www.rfc-editor.org/info/rfc3218>.
[RFC3218]Rescorla，E.“防止对加密消息语法的百万消息攻击”，RFC 3218，DOI 10.17487/RFC3218，2002年1月<http://www.rfc-editor.org/info/rfc3218>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[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>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <http://www.rfc-editor.org/info/rfc3766>.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，DOI 10.17487/RFC3766，2004年4月<http://www.rfc-editor.org/info/rfc3766>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[W3C.REC-xmlenc-core1-20130411] Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium Recommendation REC-xmlenc-core1-20130411, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
[W3C.REC-xmlenc-core1-20130411]伊斯特莱克，D.，雷格尔，J.，赫希，F.，和T.罗斯勒，“XML加密语法和处理版本1.1”，万维网联盟建议REC-xmlenc-core1-20130411，2013年4月<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
This section provides examples of JWE computations.
本节提供了JWE计算的示例。
This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using RSAES-OAEP for key encryption and AES GCM for content encryption. The representation of this plaintext (using JSON array notation) is:
本例使用RSAES-OAEP进行密钥加密，AES GCM进行内容加密，将明文加密为“智能的真正标志不是知识而是想象力”。此纯文本的表示形式（使用JSON数组表示法）为：
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
The following example JWE Protected Header declares that:
以下示例JWE Protected Header声明：
o The Content Encryption Key is encrypted to the recipient using the RSAES-OAEP algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES GCM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.
o 使用RSAES-OAEP算法向收件人加密内容加密密钥，以生成JWE加密密钥。o使用AES GCM算法对明文执行认证加密，并使用256位密钥生成密文和认证标签。
{"alg":"RSA-OAEP","enc":"A256GCM"}
{"alg":"RSA-OAEP","enc":"A256GCM"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
将此JWE保护头编码为BASE64URL（UTF8（JWE保护头））将给出以下值：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is:
生成256位随机CEK。在本例中，值（使用JSON数组表示法）为：
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252]
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252]
Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key. This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
使用RSAES-OAEP算法使用接收方的公钥加密CEK，以生成JWE加密密钥。此示例使用以下JSON Web key[JWK]格式表示的RSA密钥（值中的换行符仅用于显示）：
{"kty":"RSA", "n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw", "e":"AQAB", "d":"kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7-kpDxY4-WY5N WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9 3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-id-4OJr0h-K-VFs3VSnd VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ", "p":"1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0", "q":"wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm UDdaDYVTSNx_8Fyw1YYa9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc", "dp":"ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL hMXvo-uz-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827 rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE", "dq":"Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB UfCAiJVeESOjJDZPYHdHY8v1b-o-Z2X5tvLx-TCekf7oxyeKDUqKWjis", "qi":"VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7 AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3 eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY" }
{“kty”：“RSA”，“n”：一个研究者在一个研究小组的研究中发现了一个新的研究对象，一个研究对象是一个研究对象是一个研究对象是一个研究对象是一个研究对象，一个研究对象是一个研究对象是一个研究对象是一个研究对象，一个研究对象是一个研究对象是一个研究对象是一个研究对象是一个研究对象是一个BVVVVVVVV8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 VOJARM-L5StowjzGy-_bq6Gw，“e”：“AQAB”，“d”：2.目前，我们的研究表明，这些数据是基于一些数据的数据，例如，他们的数据是基于一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，一个数据，VILSB3LOW085-4qE3DzgrTjgyQ“，”p:“1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tzi3mgf2UFVBUODBVARQ-SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv\u hI2\u 1eTSPVZfzL0lf FN03IXQWF5MDFUYE0HZB2 VHRLN\u RKRBFDUBTJGIERBWC6CL0”，“q”：”“wLb35x7hmQWZsWJmB/vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm UDdaDYVTSNx/FYW1YYA9GRGNDEW00J28CROUEBB/JKI1OMA或V1T9AX IWKWD4GVXFIMOWR3QRL9KEBRZK2RATUBNMDZTIAWTS0G68UZHVTC”，“dp”：”ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ？OtowifvgFeqSiresXjm9gz5KL hMXvo-uz-KUJWDxS5pFQ？M0EVDO1KIRTJVW？X4nyxyxPm5NulpkCpu827 RnpzzajkPdhwagQRXgAecqH0XT4Taznjnd？ZvpamZzQ60wpmbKcue？“dq”：”DQ0GFGJ1DFGXILVQEZNUKEN0UUMSJBXKJYDC3J4ZYDBIMRAY86X0VHCJ YWCMLYG4YOC4YOC4YZA9HNVCSJQQQQQQN29TT0CJ8QQYFPZ9VNDB UfcaijveesojdjDYDHY8V1B-o-Z2X5tvLx-TCEKF7OxEKWJIS，“qi”：”VIMpMYbPf47dT1w-ZduxFPIMSSEGMOA1ZTAX7AGK-URY6R8-ZW1FxU7始终是VfQ6VFD7HQD0Y6FLUK4SLOYDB61GWANOSKGOAOV82CHQ0E3 EL4HRTZKUKVZXYJZ9JF\u XyaY14ardLSjf4L\FNY
The resulting JWE Encrypted Key value is:
生成的JWE加密密钥值为：
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203, 22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216, 82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220, 145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214, 74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182, 13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228, 173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158, 89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138, 243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6, 41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126, 215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58, 63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98, 193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215, 206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216, 104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197, 89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219, 172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134, 117, 114, 135, 206]
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203, 22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216, 82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220, 145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214, 74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182, 13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228, 173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158, 89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138, 243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6, 41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126, 215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58, 63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98, 193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215, 206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216, 104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197, 89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219, 172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134, 117, 114, 135, 206]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):
将此JWE加密密钥编码为BASE64URL（JWE加密密钥）将给出此值（换行符仅用于显示）：
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg
在未来的十年中，一些研究者发现了一种新的研究成果，在未来的十年中，一些研究者发现了一种新的研究成果，在这些研究中，一些研究者们在一个新的10年中，在一个新的研究中，他们在一个新的一个研究中，在一个新的研究中，他们在一个新的研究中，他们在一个新的研究中，他们在一个新的一个研究中，他们在一个新的一个新的一个研究的一个研究中，他们在一个新的一个新的一个研究中，他们在一个新的一个新的一个研究的一个新的一个新的一个新的一个新的一个研究的一个研究的一个新的一个新的研究，他们的研究，他们在未来的一个新的一个研究的一个新的第二，他们的一个研究，他们在一个研究的一个新的第六六六六六六六I 6UKLFCIPIMFIGF7IGDXKHZG
Generate a random 96-bit JWE Initialization Vector. In this example, the value is:
生成一个随机的96位JWE初始化向量。在本例中，值为：
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
将此JWE初始化向量编码为BASE64URL（JWE初始化向量）将给出以下值：
48V1_ALb6US04U3b
48V1_ALb6US04U3b
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
让附加的身份验证数据加密参数为ASCII（BASE64URL（UTF8（JWE保护头）））。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 128-bit Authentication Tag output. The resulting ciphertext is:
使用AES GCM算法对明文执行身份验证加密，使用CEK作为加密密钥、JWE初始化向量和上述附加身份验证数据值，请求128位身份验证标签输出。产生的密文是：
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122, 233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111, 104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32, 123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205, 160, 109, 64, 63, 192]
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122, 233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111, 104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32, 123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205, 160, 109, 64, 63, 192]
The resulting Authentication Tag value is:
生成的身份验证标记值为：
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91, 210, 145]
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91, 210, 145]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only):
将此JWE密文编码为BASE64URL（JWE密文）将给出此值（换行符仅用于显示目的）：
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A
5eym8TW\u c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX\u EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD\u A
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
将此JWE身份验证标记编码为BASE64URL（JWE身份验证标记）将给出以下值：
XFBoMYUZodetZdvTiFvSkQ
xfBomyuzodetzdvtivskq
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
组装最终表示：此结果的紧凑序列化是字符串BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| | BASE64URL（JWE身份验证标记）。
The final result in this example (with line breaks for display purposes only) is:
本例中的最终结果（换行符仅用于显示）为：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg. 48V1_ALb6US04U3b. 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A. XFBoMYUZodetZdvTiFvSkQ
EYJHBGCOIJSU0ETT0FFUCISIMVUYYI6IKEYNTZHQ00IFQ。在未来的十年中，一些研究者发现了一种新的研究成果，在未来的十年中，一些研究者发现了一种新的研究成果，在这些研究中，一些研究者们在一个新的10年中，在一个新的研究中，他们在一个新的一个研究中，在一个新的研究中，他们在一个新的研究中，他们在一个新的研究中，他们在一个新的一个研究中，他们在一个新的一个新的一个研究的一个研究中，他们在一个新的一个新的一个研究中，他们在一个新的一个新的一个研究的一个新的一个新的一个新的一个新的一个研究的一个研究的一个新的一个新的研究，他们的研究，他们在未来的一个新的一个研究的一个新的第二，他们的一个研究，他们在一个研究的一个新的第六六六六六六六i 6UKLFCIPIMFIGF7IGDXKHZG。48V1_ALb6US04U3b。5eym8TW\u c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX\u EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD\u A.XFBomyuzodetzDvtivskQ
This example illustrates the process of creating a JWE with RSAES-OAEP for key encryption and AES GCM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the RSAES-OAEP computation includes random values, the encryption results above will not be completely reproducible. However, since the AES GCM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.
此示例演示了使用RSAES-OAEP进行密钥加密和使用AES GCM进行内容加密创建JWE的过程。这些结果可用于验证这些算法的JWE解密实现。请注意，由于RSAES-OAEP计算包括随机值，因此上述加密结果将不完全可再现。但是，由于AES GCM计算是确定性的，因此对于使用这些输入执行的所有加密，JWE加密密文值都是相同的。
This example encrypts the plaintext "Live long and prosper." to the recipient using RSAES-PKCS1-v1_5 for key encryption and AES_128_CBC_HMAC_SHA_256 for content encryption. The representation of this plaintext (using JSON array notation) is:
本例使用RSAES-PKCS1-v1_5进行密钥加密，使用AES_128_CBC_HMAC_SHA_256进行内容加密，将明文“长寿且繁荣”加密给收件人。此纯文本的表示形式（使用JSON数组表示法）为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
The following example JWE Protected Header declares that:
以下示例JWE Protected Header声明：
o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the ciphertext and the Authentication Tag.
o 使用RSAES-PKCS1-v1_5算法将内容加密密钥加密给收件人，以生成JWE加密密钥。o使用AES_128_CBC_HMAC_SHA_256算法对明文执行认证加密，以生成密文和认证标签。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
将此JWE保护头编码为BASE64URL（UTF8（JWE保护头））将给出以下值：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
Generate a 256-bit random CEK. In this example, the key value is:
生成256位随机CEK。在本例中，键值为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
Encrypt the CEK with the recipient's public key using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
使用RSAES-PKCS1-v1_5算法使用接收方的公钥加密CEK，以生成JWE加密密钥。此示例使用以下JSON Web key[JWK]格式表示的RSA密钥（值中的换行符仅用于显示）：
{"kty":"RSA", "n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_ 7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU 7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw", "e":"AQAB", "d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq 1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_ 0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj -VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ", "p":"9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68 ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM", "q":"uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y BhVfuG4shsp2j7rGnIio901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN -3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0", "dp":"w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs", "dq":"o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff 7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_ odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU", "qi":"eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-Tl-m0l_eFTj2KiqwGqE9PZ B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo" }
{“kty”：“RSA”，“n”：这一研究的结果是一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的一个研究成果，一个新的一个新的一个新的研究成果，一个新的一个新的研究成果，一个新的一个新的一个新的研究成果，新的一个新的研究成果，新的一个新的一个新的研究成果，新的一个新的研究成果，新的一个新的一个新的研究成果，新的研究成果，新的一个新的研究成果，新的研究，LN-aEAw3vRw，“e”：“AQAB”，“d”：2.一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究项目，一个研究一个研究项目，一个研究项目，一个研究一个研究项目，一个研究项目，一个项目，一个项目，一个项目，一个项目，一个项目，一个项目，一个项目，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个研究，一个VGRSDWSXYPDRNINPA4JLHONDIZK2ZF2CWQ“，”p:“9GY2W6I6S6L6S6L0J0EKSBEDW9WMFGQFOEA9VEYEUUK4LWBKCOE1X4HG68 IK918DDSE9VDQSCCA3XHOAFOPJ8R9EEeIbati1VWBYNBTP87X xcPWlEP KRDWKW60TGS1和LVpMS390ZBFXT8TN biaBgelNgbC95sM”q“：“UKLCKVv_ZJMVcdIs5vVSU 6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y BHVFUG4SHSP2J7RGNIIO901RBEHO6PKWVYKPU1YHQW1JIABFW MVsN-3BQ76WLDT2SDX7Q7ZPYYHXMPS7YCZ7WGKUWNOJYELMKINS0，”dp:“W0KZBV63CVRVVX6YK3CmXO2QCM4Y8NSQ1LMMSYHG4ECL6FWBX5H9YUV NGS4ILEFK6EALLOWWWL4TXW9LSWH_zKI-hwoReoP77cOdSL4AVcra HAWLKYD2TWJE5EVGBHWTOXEE3CJBKAIK646JZXBVK-RR3pEhnCs，“dq”：o_8; u 8SEZCKO6CNLKs_btPdFiO9_KC1; uTd2LAFIVEMZ7JN1Gu Ff 7IVX3P5KUBGOVF8L-QIFLB6NQNLYSGHDH132NDIOZKH7MI7HPG-PYE_UpkDNQECHWW0J-F0JWnud6B_1DVF9MXA2QX-iGYn8OVV1Bsmp6qU，“qi:”Enho5YRBBxHGBTQRWW9QIRZSB66Trffreg厍u CcteI1aCneT0ELGhYlRlC tuktrcluepmnsnsndplolqcVznFBVDB7x-Tl-m0l厍eFTj2KiqwGqE9PZ B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-v7tbpxihvefe0nno“
The resulting JWE Encrypted Key value is:
生成的JWE加密密钥值为：
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151, 176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181, 156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156, 116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223, 226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66, 212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253, 215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128, 66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199, 54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151, 250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197, 21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102, 166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222, 150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241, 124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242, 16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244, 248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167, 101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169, 146, 114, 165, 204, 71, 136, 41, 252]
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151, 176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181, 156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156, 116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223, 226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66, 212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253, 215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128, 66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199, 54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151, 250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197, 21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102, 166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222, 150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241, 124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242, 16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244, 248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167, 101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169, 146, 114, 165, 204, 71, 136, 41, 252]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):
将此JWE加密密钥编码为BASE64URL（JWE加密密钥）将给出此值（换行符仅用于显示）：
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
Generate a random 128-bit JWE Initialization Vector. In this example, the value is:
生成一个随机的128位JWE初始化向量。在本例中，值为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
将此JWE初始化向量编码为BASE64URL（JWE初始化向量）将给出以下值：
AxY8DCtDaGlsbGljb3RoZQ
AxY8DCtDaGlsbGljb3RoZQ
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
让附加的身份验证数据加密参数为ASCII（BASE64URL（UTF8（JWE保护头）））。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from Appendix A.3 are detailed in Appendix B. The resulting ciphertext is:
使用AES_128_CBC_HMAC_SHA_256算法对明文执行身份验证加密，使用CEK作为加密密钥、JWE初始化向量和上述附加身份验证数据值。使用附录A.3中的值执行此操作的步骤在附录B中详细说明。生成的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
The resulting Authentication Tag value is:
生成的身份验证标记值为：
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100, 191]
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100, 191]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
将此JWE密文编码为BASE64URL（JWE密文）将给出以下值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
将此JWE身份验证标记编码为BASE64URL（JWE身份验证标记）将给出以下值：
9hH0vgRfYgPnAHOd8stkvw
9hH0vgRfYgPnAHOd8stkvw
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
组装最终表示：此结果的紧凑序列化是字符串BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| | BASE64URL（JWE身份验证标记）。
The final result in this example (with line breaks for display purposes only) is:
本例中的最终结果（换行符仅用于显示）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
This example illustrates the process of creating a JWE with RSAES-PKCS1-v1_5 for key encryption and AES_CBC_HMAC_SHA2 for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the RSAES-PKCS1-v1_5 computation includes random values, the encryption results above will not be completely reproducible. However, since the AES-CBC computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.
此示例演示了使用RSAES-PKCS1-v1_5进行密钥加密，使用AES_CBC_HMAC_SHA2进行内容加密的过程。这些结果可用于验证这些算法的JWE解密实现。请注意，由于RSAES-PKCS1-v1_5计算包含随机值，因此上述加密结果将无法完全再现。但是，由于AES-CBC计算是确定性的，因此对于使用这些输入执行的所有加密，JWE加密密文值都是相同的。
This example encrypts the plaintext "Live long and prosper." to the recipient using AES Key Wrap for key encryption and AES_128_CBC_HMAC_SHA_256 for content encryption. The representation of this plaintext (using JSON array notation) is:
本例使用AES密钥包裹进行密钥加密，使用AES_128_CBC_HMAC_SHA_256进行内容加密，将明文“长寿且繁荣”加密给收件人。此纯文本的表示形式（使用JSON数组表示法）为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
The following example JWE Protected Header declares that:
以下示例JWE Protected Header声明：
o The Content Encryption Key is encrypted to the recipient using the AES Key Wrap algorithm with a 128-bit key to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the ciphertext and the Authentication Tag.
o 内容加密密钥通过使用AES密钥包裹算法和128位密钥向收件人加密，以生成JWE加密密钥。o使用AES_128_CBC_HMAC_SHA_256算法对明文执行认证加密，以生成密文和认证标签。
{"alg":"A128KW","enc":"A128CBC-HS256"}
{"alg":"A128KW","enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
将此JWE保护头编码为BASE64URL（UTF8（JWE保护头））将给出以下值：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
Generate a 256-bit random CEK. In this example, the value is:
生成256位随机CEK。在本例中，值为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
Encrypt the CEK with the shared symmetric key using the AES Key Wrap algorithm to produce the JWE Encrypted Key. This example uses the symmetric key represented in JSON Web Key [JWK] format below:
使用AES密钥包裹算法使用共享对称密钥加密CEK，以生成JWE加密密钥。此示例使用JSON Web密钥[JWK]格式表示的对称密钥，如下所示：
{"kty":"oct", "k":"GawgguFyGrWKav7AX4VKUg" }
{“kty”：“oct”，“k”：“GawgguFyGrWKav7AX4VKUg”}
The resulting JWE Encrypted Key value is:
生成的JWE加密密钥值为：
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216, 22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3, 76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216, 22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3, 76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value:
将此JWE加密密钥编码为BASE64URL（JWE加密密钥）将给出以下值：
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
Generate a random 128-bit JWE Initialization Vector. In this example, the value is:
生成一个随机的128位JWE初始化向量。在本例中，值为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
将此JWE初始化向量编码为BASE64URL（JWE初始化向量）将给出以下值：
AxY8DCtDaGlsbGljb3RoZQ
AxY8DCtDaGlsbGljb3RoZQ
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
让附加的身份验证数据加密参数为ASCII（BASE64URL（UTF8（JWE保护头）））。该值为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from this example are detailed in Appendix B. The resulting ciphertext is:
使用AES_128_CBC_HMAC_SHA_256算法对明文执行身份验证加密，使用CEK作为加密密钥、JWE初始化向量和上述附加身份验证数据值。附录B中详细说明了使用本示例中的值执行此操作的步骤。生成的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
The resulting Authentication Tag value is:
生成的身份验证标记值为：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
将此JWE密文编码为BASE64URL（JWE密文）将给出以下值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
将此JWE身份验证标记编码为BASE64URL（JWE身份验证标记）将给出以下值：
U0m_YmjN04DJvceFICbCVQ
U0m_YmjN04DJvceFICbCVQ
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
组装最终表示：此结果的紧凑序列化是字符串BASE64URL（UTF8（JWE保护头））| |'。| | BASE64URL（JWE加密密钥）| |'。| | BASE64URL（JWE初始化向量）| |'。| | BASE64URL（JWE密文）| |'。| | BASE64URL（JWE身份验证标记）。
The final result in this example (with line breaks for display purposes only) is:
本例中的最终结果（换行符仅用于显示）为：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ. AxY8DCtDaGlsbGljb3RoZQ. KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY. U0m_YmjN04DJvceFICbCVQ
EYJHBGCIOIJBMTI4Q0JDLUHTMJU2in0。6KB707DM9YTIGHTLVTGWQ8MKWBOJW3OF9LOCIZKDTHZBC2ILRT1OQ。AxY8DCtDaGlsbGljb3RoZQ。KDLTTXCHHZTGUFMYGS4HFXPSURFMQCHXAI9WOGY。U0m_YmjN04DJvceFICbCVQ
This example illustrates the process of creating a JWE with AES Key Wrap for key encryption and AES GCM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Also, since both the AES Key Wrap and AES GCM computations are deterministic, the resulting JWE value will be the same for all encryptions performed using these inputs. Since the computation is reproducible, these results can also be used to validate JWE encryption implementations for these algorithms.
此示例演示了创建JWE的过程，其中AES密钥包裹用于密钥加密，AES GCM用于内容加密。这些结果可用于验证这些算法的JWE解密实现。此外，由于AES密钥包裹和AES GCM计算都是确定性的，因此使用这些输入执行的所有加密的结果JWE值都是相同的。由于计算是可重复的，这些结果也可用于验证这些算法的JWE加密实现。
This section contains an example using the general JWE JSON Serialization syntax. This example demonstrates the capability for encrypting the same plaintext to multiple recipients.
本节包含一个使用通用JWE JSON序列化语法的示例。此示例演示了将同一明文加密到多个收件人的功能。
Two recipients are present in this example. The algorithm and key used for the first recipient are the same as that used in Appendix A.2. The algorithm and key used for the second recipient are the same as that used in Appendix A.3. The resulting JWE Encrypted Key values are therefore the same; those computations are not repeated here.
本例中有两个收件人。第一个收件人使用的算法和密钥与附录A.2中使用的相同。第二个收件人使用的算法和密钥与附录A.3中使用的相同。因此，生成的JWE加密密钥值是相同的；这里不再重复这些计算。
The plaintext, the CEK, JWE Initialization Vector, and JWE Protected Header are shared by all recipients (which must be the case, since the ciphertext and Authentication Tag are also shared).
明文、CEK、JWE初始化向量和JWE保护头由所有接收者共享（必须如此，因为密文和身份验证标记也是共享的）。
The first recipient uses the RSAES-PKCS1-v1_5 algorithm to encrypt the CEK. The second uses AES Key Wrap to encrypt the CEK. Key ID values are supplied for both keys. The two JWE Per-Recipient Unprotected Header values used to represent these algorithms and key IDs are:
第一个收件人使用RSAES-PKCS1-v1_5算法对CEK进行加密。第二种方法使用AES密钥包装对CEK进行加密。两个键都提供了键ID值。用于表示这些算法和密钥ID的两个JWE Per Recipient Unprotected Header值为：
{"alg":"RSA1_5","kid":"2011-04-29"}
{"alg":"RSA1_5","kid":"2011-04-29"}
and
和
{"alg":"A128KW","kid":"7"}
{"alg":"A128KW","kid":"7"}
Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the common JWE Ciphertext and JWE Authentication Tag values. The JWE Protected Header value representing this is:
使用AES_128_CBC_HMAC_SHA_256算法对明文执行身份验证加密，以生成常见的JWE密文和JWE身份验证标记值。表示这一点的JWE受保护标头值为：
{"enc":"A128CBC-HS256"}
{"enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
将此JWE保护头编码为BASE64URL（UTF8（JWE保护头））将给出以下值：
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
This JWE uses the "jku" Header Parameter to reference a JWK Set. This is represented in the following JWE Shared Unprotected Header value as:
这个JWE使用“jku”头参数来引用JWK集。这在以下JWE共享无保护标头值中表示为：
{"jku":"https://server.example.com/keys.jwks"}
{"jku":"https://server.example.com/keys.jwks"}
Combining the JWE Per-Recipient Unprotected Header, JWE Protected Header, and JWE Shared Unprotected Header values supplied, the JOSE Header values used for the first and second recipient, respectively, are:
结合提供的JWE每个收件人未保护标头、JWE保护标头和JWE共享未保护标头值，分别用于第一个和第二个收件人的JOSE标头值为：
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
and
和
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
让附加的身份验证数据加密参数为ASCII（BASE64URL（UTF8（JWE保护头）））。该值为：
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from Appendix A.3 are detailed in Appendix B. The resulting ciphertext is:
使用AES_128_CBC_HMAC_SHA_256算法对明文执行身份验证加密，使用CEK作为加密密钥、JWE初始化向量和上述附加身份验证数据值。使用附录A.3中的值执行此操作的步骤在附录B中详细说明。生成的密文为：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
The resulting Authentication Tag value is:
生成的身份验证标记值为：
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47, 207]
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47, 207]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
将此JWE密文编码为BASE64URL（JWE密文）将给出以下值：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
将此JWE身份验证标记编码为BASE64URL（JWE身份验证标记）将给出以下值：
Mz-VPPyU4RlcuYv1IwIvzw
Mz-VPPYU4RLCUYV1WIVZW
The complete JWE JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
这些值的完整JWE JSON序列化如下（值中的换行符仅用于显示）：
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
This section contains an example using the flattened JWE JSON Serialization syntax. This example demonstrates the capability for encrypting the plaintext to a single recipient in a flattened JSON structure.
本节包含一个使用扁平化JWE JSON序列化语法的示例。此示例演示了将明文加密到扁平JSON结构中的单个收件人的功能。
The values in this example are the same as those for the second recipient of the previous example in Appendix A.4.
本示例中的值与附录A.4中前一示例中第二个收件人的值相同。
The complete JWE JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
这些值的完整JWE JSON序列化如下（值中的换行符仅用于显示）：
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation
附录B.AES_128_CBC_HMAC_SHA_256计算示例
This example shows the steps in the AES_128_CBC_HMAC_SHA_256 authenticated encryption computation using the values from the example in Appendix A.3. As described where this algorithm is defined in Sections 5.2 and 5.2.3 of JWA, the AES_CBC_HMAC_SHA2 family of algorithms are implemented using Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode with Public-Key Cryptography Standards (PKCS) #7 padding to perform the encryption and an HMAC SHA-2 function to perform the integrity calculation -- in this case, HMAC SHA-256.
此示例显示了使用附录A.3中示例中的值进行AES_128_CBC_HMAC_SHA_256认证加密计算的步骤。如JWA第5.2节和第5.2.3节中定义的算法所述，AES_CBC_HMAC_SHA2系列算法使用密码块链接（CBC）模式下的高级加密标准（AES）和公钥加密标准（PKCS）实现#7填充以执行加密，并使用HMAC SHA-2函数执行完整性计算——在本例中为HMAC SHA-256。
The 256 bit AES_128_CBC_HMAC_SHA_256 key K used in this example (using JSON array notation) is:
本例中使用的256位AES_128_CBC_HMAC_SHA_256密钥K（使用JSON数组表示法）为：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
Use the first 128 bits of this key as the HMAC SHA-256 key MAC_KEY, which is:
使用该密钥的前128位作为HMAC SHA-256密钥MAC_密钥，即：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206]
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206]
Use the last 128 bits of this key as the AES-CBC key ENC_KEY, which is:
使用此密钥的最后128位作为AES-CBC密钥ENC_密钥，即：
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
Note that the MAC key comes before the encryption key in the input key K; this is in the opposite order of the algorithm names in the identifiers "AES_128_CBC_HMAC_SHA_256" and "A128CBC-HS256".
注意，在输入密钥K中，MAC密钥在加密密钥之前；这与标识符“AES_128_CBC_HMAC_SHA_256”和“A128CBC-HS256”中的算法名称顺序相反。
Encrypt the plaintext with AES in CBC mode using PKCS #7 padding using the ENC_KEY above. The plaintext in this example is:
使用上述ENC#U密钥，在CBC模式下使用PKCS#7填充使用AES加密明文。本例中的纯文本为：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
The encryption result is as follows, which is the ciphertext output:
加密结果如下，即密文输出：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
The Additional Authenticated Data (AAD) in this example is:
本例中的附加认证数据（AAD）为：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
This AAD is 51-bytes long, which is 408-bits long. The octet string AL, which is the number of bits in AAD expressed as a big-endian 64-bit unsigned integer is:
该AAD的长度为51字节，即408位。八进制字符串AL是AAD中表示为大端64位无符号整数的位数，它是：
[0, 0, 0, 0, 0, 0, 1, 152]
[0, 0, 0, 0, 0, 0, 1, 152]
The Initialization Vector value used in this example is:
本例中使用的初始化向量值为：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
Concatenate the AAD, the Initialization Vector, the ciphertext, and the AL value. The result of this concatenation is:
连接AAD、初始化向量、密文和AL值。此连接的结果是：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
Compute the HMAC SHA-256 of the concatenated value above. This result M is:
计算上述连接值的HMAC SHA-256。这个结果M是：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105, 86, 229, 116]
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105, 86, 229, 116]
Use the first half (128 bits) of the HMAC output M as the Authentication Tag output T. This truncated value is:
使用HMAC输出M的前半部分（128位）作为身份验证标签输出T。此截断值为：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
Acknowledgements
致谢
Solutions for encrypting JSON content were also explored by "JSON Simple Encryption" [JSE] and "JavaScript Message Security Format" [JSMS], both of which significantly influenced this document. This document attempts to explicitly reuse as many of the relevant concepts from XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] and RFC 5652 [RFC5652] as possible, while utilizing simple, compact JSON-based data structures.
“JSON简单加密”[JSE]和“JavaScript消息安全格式”[JSMS]也探讨了加密JSON内容的解决方案，这两种方法都对本文档产生了重大影响。本文档试图尽可能明确地重用XML Encryption 1.1[W3C.REC-xmlenc-core1-20130411]和RFC 5652[RFC5652]中的许多相关概念，同时利用简单、紧凑的基于JSON的数据结构。
Special thanks are due to John Bradley, Eric Rescorla, and Nat Sakimura for the discussions that helped inform the content of this specification; to Eric Rescorla and Joe Hildebrand for allowing the reuse of text from [JSMS] in this document; and to Eric Rescorla for co-authoring many drafts of this specification.
特别感谢John Bradley、Eric Rescorla和Nat Sakimura为本规范内容提供信息的讨论；感谢Eric Rescorla和Joe Hildebrand允许在本文件中重用[JSMS]中的文本；并感谢Eric Rescorla共同编写了本规范的许多草案。
Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund Jay for validating the examples in this specification.
感谢Axel Nennker、Emmanuel Raviart、Brian Campbell和Edmund Jay验证了本规范中的示例。
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:
本规范是JOSE工作组的工作，该工作组包括数十名积极和专注的参与者。特别是，以下个人提供了影响本规范的想法、反馈和措辞：
Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley, Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
理查德·巴恩斯、约翰·布拉德利、布赖恩·坎贝尔、艾莉莎·库珀、布伦诺·德梅德罗斯、斯蒂芬·法雷尔、迪克·哈特、杰夫·霍奇斯、罗斯·霍斯利、埃德蒙·杰伊、斯科特·凯利、斯蒂芬·肯特、巴里·莱巴、詹姆斯·马格尔、马特·米勒、凯瑟琳·莫里亚蒂、托尼·纳达林、奈拉、阿克塞尔·内克尔、雷·波尔克、艾曼纽尔·拉维特、埃里克·雷索拉、皮特·雷斯尼克、纳特·樱村、，Jim Schaad、Hannes Tschofenig和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.
Jim Schaad和Karen O'Donoghue担任JOSE工作组主席，Sean Turner、Stephen Farrell和Kathleen Moriarty在创建本规范期间担任安全区域主管。
Authors' Addresses
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joe Hildebrand Cisco Systems, Inc.
乔·希尔德布兰德思科系统公司。
EMail: jhildebr@cisco.com
EMail: jhildebr@cisco.com