Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7518 Microsoft
Category: Standards Track May 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7518 Microsoft
Category: Standards Track May 2015
ISSN: 2070-1721
JSON Web Algorithms (JWA)
JSON Web算法（JWA）
Abstract
摘要
This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.
本规范注册了用于JSON Web签名（JWS）、JSON Web加密（JWE）和JSON Web密钥（JWK）规范的加密算法和标识符。它为这些标识符定义了几个IANA注册表。
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/rfc7518.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7518.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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. Cryptographic Algorithms for Digital Signatures and MACs . . 6
3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 6
3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7
3.3. Digital Signature with RSASSA-PKCS1-v1_5 . . . . . . . . 8
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . 9
3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 10
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . 11
4. Cryptographic Algorithms for Key Management . . . . . . . . . 11
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12
4.2. Key Encryption with RSAES-PKCS1-v1_5 . . . . . . . . . . 13
4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . 14
4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . 14
4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 15
4.6. Key Agreement with Elliptic Curve Diffie-Hellman
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . 15
4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 16
4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 16
4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 17
4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 17
4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 17
4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 18
4.7.1. Header Parameters Used for AES GCM Key Encryption . . 19
4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 19
4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 19
4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 20
4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 20
4.8.1.1. "p2s" (PBES2 Salt Input) Header Parameter . . . . 21
4.8.1.2. "p2c" (PBES2 Count) Header Parameter . . . . . . 21
5. Cryptographic Algorithms for Content Encryption . . . . . . . 21
5.1. "enc" (Encryption Algorithm) Header Parameter Values for
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . 22
5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . 23
5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 26
5.2.6. Content Encryption with AES_CBC_HMAC_SHA2 . . . . . . 26
5.3. Content Encryption with AES GCM . . . . . . . . . . . . . 27
6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 27
6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Cryptographic Algorithms for Digital Signatures and MACs . . 6
3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 6
3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7
3.3. Digital Signature with RSASSA-PKCS1-v1_5 . . . . . . . . 8
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . 9
3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 10
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . 11
4. Cryptographic Algorithms for Key Management . . . . . . . . . 11
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12
4.2. Key Encryption with RSAES-PKCS1-v1_5 . . . . . . . . . . 13
4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . 14
4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . 14
4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 15
4.6. Key Agreement with Elliptic Curve Diffie-Hellman
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . 15
4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 16
4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 16
4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 17
4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 17
4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 17
4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 18
4.7.1. Header Parameters Used for AES GCM Key Encryption . . 19
4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 19
4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 19
4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 20
4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 20
4.8.1.1. "p2s" (PBES2 Salt Input) Header Parameter . . . . 21
4.8.1.2. "p2c" (PBES2 Count) Header Parameter . . . . . . 21
5. Cryptographic Algorithms for Content Encryption . . . . . . . 21
5.1. "enc" (Encryption Algorithm) Header Parameter Values for
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . 22
5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . 23
5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 26
5.2.6. Content Encryption with AES_CBC_HMAC_SHA2 . . . . . . 26
5.3. Content Encryption with AES GCM . . . . . . . . . . . . . 27
6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 27
6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28
6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . 28
6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28
6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 28
6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . 29
6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . 29
6.2.2. Parameters for Elliptic Curve Private Keys . . . . . 29
6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29
6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30
6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . 30
6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30
6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . 30
6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 30
6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . 30
6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . 31
6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31
6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . 31
6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31
6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . 31
6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 31
6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32
6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. JSON Web Signature and Encryption Algorithms Registry . . 33
7.1.1. Registration Template . . . . . . . . . . . . . . . . 34
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35
7.2. Header Parameter Names Registration . . . . . . . . . . . 42
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 42
7.3. JSON Web Encryption Compression Algorithms Registry . . . 43
7.3.1. Registration Template . . . . . . . . . . . . . . . . 43
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 44
7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 44
7.4.1. Registration Template . . . . . . . . . . . . . . . . 44
7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 45
7.5. JSON Web Key Parameters Registration . . . . . . . . . . 45
7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 46
7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . 48
7.6.1. Registration Template . . . . . . . . . . . . . . . . 48
7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 50
8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . 50
8.4. AES GCM Security Considerations . . . . . . . . . . . . . 50
8.5. Unsecured JWS Security Considerations . . . . . . . . . . 51
8.6. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 51
8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 51
8.8. Password Considerations . . . . . . . . . . . . . . . . . 52
8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 52
6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . 28
6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28
6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 28
6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . 29
6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . 29
6.2.2. Parameters for Elliptic Curve Private Keys . . . . . 29
6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29
6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30
6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . 30
6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30
6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . 30
6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 30
6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . 30
6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . 31
6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31
6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . 31
6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31
6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . 31
6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 31
6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32
6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. JSON Web Signature and Encryption Algorithms Registry . . 33
7.1.1. Registration Template . . . . . . . . . . . . . . . . 34
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35
7.2. Header Parameter Names Registration . . . . . . . . . . . 42
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 42
7.3. JSON Web Encryption Compression Algorithms Registry . . . 43
7.3.1. Registration Template . . . . . . . . . . . . . . . . 43
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 44
7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 44
7.4.1. Registration Template . . . . . . . . . . . . . . . . 44
7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 45
7.5. JSON Web Key Parameters Registration . . . . . . . . . . 45
7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 46
7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . 48
7.6.1. Registration Template . . . . . . . . . . . . . . . . 48
7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 50
8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . 50
8.4. AES GCM Security Considerations . . . . . . . . . . . . . 50
8.5. Unsecured JWS Security Considerations . . . . . . . . . . 51
8.6. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 51
8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 51
8.8. Password Considerations . . . . . . . . . . . . . . . . . 52
8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 52
8.10. Differences between Digital Signatures and MACs . . . . . 52
8.11. Using Matching Algorithm Strengths . . . . . . . . . . . 53
8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . 53
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 53
8.14. RSA Private Key Representations and Blinding . . . . . . 53
9. Internationalization Considerations . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 59
A.1. Digital Signature/MAC Algorithm Identifier Cross-
Reference . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2. Key Management Algorithm Identifier Cross-Reference . . . 61
A.3. Content Encryption Algorithm Identifier Cross-Reference . 62
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . 62
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 63
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 64
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 65
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . 66
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 69
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69
8.10. Differences between Digital Signatures and MACs . . . . . 52
8.11. Using Matching Algorithm Strengths . . . . . . . . . . . 53
8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . 53
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 53
8.14. RSA Private Key Representations and Blinding . . . . . . 53
9. Internationalization Considerations . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 59
A.1. Digital Signature/MAC Algorithm Identifier Cross-
Reference . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2. Key Management Algorithm Identifier Cross-Reference . . . 61
A.3. Content Encryption Algorithm Identifier Cross-Reference . 62
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . 62
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 63
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 64
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 65
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . 66
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 69
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69
This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) [JWK] specifications. It defines several IANA registries for these identifiers. All these specifications utilize JSON-based [RFC7159] data structures. This specification also describes the semantics and operations that are specific to these algorithms and key types.
本规范注册了用于JSON Web签名（JWS）[JWS]、JSON Web加密（JWE）[JWE]和JSON Web密钥（JWK）[JWK]规范的加密算法和标识符。它为这些标识符定义了几个IANA注册表。所有这些规范都使用基于JSON的[RFC7159]数据结构。本规范还描述了特定于这些算法和密钥类型的语义和操作。
Registering the algorithms and identifiers here, rather than in the JWS, JWE, and JWK specifications, is intended to allow them to remain unchanged in the face of changes in the set of Required, Recommended, Optional, and Deprecated algorithms over time. This also allows changes to the JWS, JWE, and JWK specifications without changing this document.
在这里注册算法和标识符，而不是在JWS、JWE和JWK规范中注册，目的是允许它们在所需、推荐、可选和不推荐的算法集随时间变化时保持不变。这还允许在不更改本文档的情况下更改JWS、JWE和JWK规范。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。
The interpretation should only be applied when the terms appear in all capital letters.
该解释仅适用于所有大写字母的术语。
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", "Header Parameter", "JOSE Header", "JWS Payload", "JWS Protected Header", "JWS Signature", "JWS Signing Input", and "Unsecured JWS" are defined by the JWS specification [JWS].
术语“JSON Web签名（JWS）”、“Base64url编码”、“头参数”、“JOSE头”、“JWS有效负载”、“JWS保护头”、“JWS签名”、“JWS签名输入”和“不安全JWS”由JWS规范[JWS]定义。
The terms "JSON Web Encryption (JWE)", "Additional Authenticated Data (AAD)", "Authentication Tag", "Content Encryption Key (CEK)", "Direct Encryption", "Direct Key Agreement", "JWE Authentication Tag", "JWE Ciphertext", "JWE Encrypted Key", "JWE Initialization Vector", "JWE Protected Header", "Key Agreement with Key Wrapping", "Key Encryption", "Key Management Mode", and "Key Wrapping" are defined by the JWE specification [JWE].
术语“JSON Web加密（JWE）”、“附加认证数据（AAD）”、“认证标签”、“内容加密密钥（CEK）”、“直接加密”、“直接密钥协议”、“JWE认证标签”、“JWE密文”、“JWE加密密钥”、“JWE初始化向量”、“JWE保护头”、“带密钥包装的密钥协议”、“密钥加密”，“密钥管理模式”和“密钥包装”由JWE规范[JWE]定义。
The terms "JSON Web Key (JWK)" and "JWK Set" are defined by the JWK specification [JWK].
术语“JSON Web密钥（JWK）”和“JWK集”由JWK规范[JWK]定义。
The terms "Ciphertext", "Digital Signature", "Initialization Vector", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
术语“密文”、“数字签名”、“初始化向量”、“消息认证码（MAC）”和“明文”由“互联网安全词汇表，版本2”[RFC4949]定义。
This term is defined by this specification:
本规范对该术语进行了定义：
Base64urlUInt The representation of a positive or zero integer value as the base64url encoding of the value's unsigned big-endian representation as an octet sequence. The octet sequence MUST utilize the minimum number of octets needed to represent the value. Zero is represented as BASE64URL(single zero-valued octet), which is "AA".
Base64urlUInt正整数值或零整数值的表示形式，该值的无符号大端表示形式的base64url编码形式为八位字节序列。八位字节序列必须使用表示该值所需的最小八位字节数。零表示为BASE64URL（单零值八位字节），即“AA”。
JWS uses cryptographic algorithms to digitally sign or create a MAC of the contents of the JWS Protected Header and the JWS Payload.
JWS使用加密算法对受JWS保护的标头和JWS有效负载的内容进行数字签名或创建MAC。
The table below is the set of "alg" (algorithm) Header Parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections:
下表是本规范定义的用于JWS的“alg”（算法）头参数值集，以下各节将对每个值进行更详细的解释：
+--------------+-------------------------------+--------------------+
| "alg" Param | Digital Signature or MAC | Implementation |
| Value | Algorithm | Requirements |
+--------------+-------------------------------+--------------------+
| HS256 | HMAC using SHA-256 | Required |
| HS384 | HMAC using SHA-384 | Optional |
| HS512 | HMAC using SHA-512 | Optional |
| RS256 | RSASSA-PKCS1-v1_5 using | Recommended |
| | SHA-256 | |
| RS384 | RSASSA-PKCS1-v1_5 using | Optional |
| | SHA-384 | |
| RS512 | RSASSA-PKCS1-v1_5 using | Optional |
| | SHA-512 | |
| ES256 | ECDSA using P-256 and SHA-256 | Recommended+ |
| ES384 | ECDSA using P-384 and SHA-384 | Optional |
| ES512 | ECDSA using P-521 and SHA-512 | Optional |
| PS256 | RSASSA-PSS using SHA-256 and | Optional |
| | MGF1 with SHA-256 | |
| PS384 | RSASSA-PSS using SHA-384 and | Optional |
| | MGF1 with SHA-384 | |
| PS512 | RSASSA-PSS using SHA-512 and | Optional |
| | MGF1 with SHA-512 | |
| none | No digital signature or MAC | Optional |
| | performed | |
+--------------+-------------------------------+--------------------+
+--------------+-------------------------------+--------------------+
| "alg" Param | Digital Signature or MAC | Implementation |
| Value | Algorithm | Requirements |
+--------------+-------------------------------+--------------------+
| HS256 | HMAC using SHA-256 | Required |
| HS384 | HMAC using SHA-384 | Optional |
| HS512 | HMAC using SHA-512 | Optional |
| RS256 | RSASSA-PKCS1-v1_5 using | Recommended |
| | SHA-256 | |
| RS384 | RSASSA-PKCS1-v1_5 using | Optional |
| | SHA-384 | |
| RS512 | RSASSA-PKCS1-v1_5 using | Optional |
| | SHA-512 | |
| ES256 | ECDSA using P-256 and SHA-256 | Recommended+ |
| ES384 | ECDSA using P-384 and SHA-384 | Optional |
| ES512 | ECDSA using P-521 and SHA-512 | Optional |
| PS256 | RSASSA-PSS using SHA-256 and | Optional |
| | MGF1 with SHA-256 | |
| PS384 | RSASSA-PSS using SHA-384 and | Optional |
| | MGF1 with SHA-384 | |
| PS512 | RSASSA-PSS using SHA-512 and | Optional |
| | MGF1 with SHA-512 | |
| none | No digital signature or MAC | Optional |
| | performed | |
+--------------+-------------------------------+--------------------+
The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification.
在“实现需求”列中使用“+”表示在规范的未来版本中需求强度可能会增加。
See Appendix A.1 for a table cross-referencing the JWS digital signature and MAC "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
见附录A.1，该表交叉引用了本规范中定义的JWS数字签名和MAC“alg”（算法）值以及其他标准和软件包使用的等效标识符。
Hash-based Message Authentication Codes (HMACs) enable one to use a secret plus a cryptographic hash function to generate a MAC. This can be used to demonstrate that whoever generated the MAC was in possession of the MAC key. The algorithm for implementing and validating HMACs is provided in RFC 2104 [RFC2104].
基于散列的消息认证码（HMAC）使人们能够使用一个秘密加上一个加密散列函数来生成MAC。这可以用来证明生成MAC的人拥有MAC密钥。RFC 2104[RFC2104]中提供了实现和验证HMACs的算法。
A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. (This requirement is based on Section 5.3.4 (Security Effect of the HMAC Key) of NIST SP 800-117 [NIST.800-107], which states that the effective security strength is the minimum of the security strength of the key and two times the size of the internal hash value.)
此算法必须使用与哈希输出大小相同（例如，“HS256”为256位）或更大的密钥。（该要求基于NIST SP 800-117[NIST.800-107]第5.3.4节（HMAC密钥的安全效应），该节规定有效安全强度为密钥安全强度的最小值和内部哈希值大小的两倍。）
The HMAC SHA-256 MAC is generated per RFC 2104, using SHA-256 as the hash algorithm "H", using the JWS Signing Input as the "text" value, and using the shared key. The HMAC output value is the JWS Signature.
HMAC SHA-256 MAC根据RFC 2104生成，使用SHA-256作为散列算法“H”，使用JWS签名输入作为“文本”值，并使用共享密钥。HMAC输出值是JWS签名。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is an HMAC value computed using the corresponding algorithm:
以下“alg”（算法）头参数值用于指示JWS签名是使用相应算法计算的HMAC值：
+-------------------+--------------------+
| "alg" Param Value | MAC Algorithm |
+-------------------+--------------------+
| HS256 | HMAC using SHA-256 |
| HS384 | HMAC using SHA-384 |
| HS512 | HMAC using SHA-512 |
+-------------------+--------------------+
+-------------------+--------------------+
| "alg" Param Value | MAC Algorithm |
+-------------------+--------------------+
| HS256 | HMAC using SHA-256 |
| HS384 | HMAC using SHA-384 |
| HS512 | HMAC using SHA-512 |
+-------------------+--------------------+
The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC value per RFC 2104, using SHA-256 as the hash algorithm "H", using the received JWS Signing Input as the "text" value, and using the shared key. This computed HMAC value is then compared to the result of base64url decoding the received encoded JWS Signature value. The comparison of the computed HMAC value to the JWS Signature value MUST be done in a constant-time manner to thwart timing attacks. Alternatively, the computed HMAC value can be base64url encoded and compared to the received encoded JWS Signature value (also in a constant-time manner), as this comparison produces the same result as comparing the unencoded values. In either case, if the values match, the HMAC has been validated.
JWS的HMAC SHA-256 MAC通过按照RFC 2104计算HMAC值、使用SHA-256作为散列算法“H”、使用接收到的JWS签名输入作为“文本”值以及使用共享密钥来验证。然后将计算出的HMAC值与base64url解码接收到的编码JWS签名值的结果进行比较。计算出的HMAC值与JWS签名值的比较必须以恒定时间的方式进行，以阻止定时攻击。或者，可以对计算出的HMAC值进行base64url编码，并将其与接收到的编码JWS签名值进行比较（也以恒定时间的方式），因为这种比较产生的结果与比较未编码值的结果相同。在任何一种情况下，如果值匹配，则HMAC已被验证。
Securing content and validation with the HMAC SHA-384 and HMAC SHA-512 algorithms is performed identically to the procedure for HMAC SHA-256 -- just using the corresponding hash algorithms with correspondingly larger minimum key sizes and result values: 384 bits each for HMAC SHA-384 and 512 bits each for HMAC SHA-512.
使用HMAC SHA-384和HMAC SHA-512算法保护内容和验证的执行过程与HMAC SHA-256的过程相同——仅使用具有相应较大最小密钥大小和结果值的相应哈希算法：HMAC SHA-384和HMAC SHA-512各384位和512位。
An example using this algorithm is shown in Appendix A.1 of [JWS].
[JWS]的附录A.1中给出了使用该算法的示例。
This section defines the use of the RSASSA-PKCS1-v1_5 digital signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447] (commonly known as PKCS #1), using SHA-2 [SHS] hash functions.
本节定义了使用SHA-2[SHS]散列函数使用RFC 3447[RFC3447]（通常称为PKCS#1）第8.2节中定义的RSASSA-PKCS1-v1_5数字签名算法。
A key of size 2048 bits or larger MUST be used with these algorithms.
这些算法必须使用2048位或更大的密钥。
The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as follows: generate a digital signature of the JWS Signing Input using RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired private key. This is the JWS Signature value.
生成RSASSA-PKCS1-v1_5 SHA-256数字签名如下：使用RSASSA-PKCS1-v1_5-SIGN和SHA-256哈希函数以及所需的私钥生成JWS签名输入的数字签名。这是JWS签名值。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:
以下“alg”（算法）头参数值用于指示JWS签名是使用相应算法计算的数字签名值：
+-------------------+---------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+---------------------------------+
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 |
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 |
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 |
+-------------------+---------------------------------+
+-------------------+---------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+---------------------------------+
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 |
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 |
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 |
+-------------------+---------------------------------+
The RSASSA-PKCS1-v1_5 SHA-256 digital signature for a JWS is validated as follows: submit the JWS Signing Input, the JWS Signature, and the public key corresponding to the private key used by the signer to the RSASSA-PKCS1-v1_5-VERIFY algorithm using SHA-256 as the hash function.
JWS的RSASSA-PKCS1-v1_5 SHA-256数字签名验证如下：使用SHA-256作为散列函数，将JWS签名输入、JWS签名和签名者使用的私钥对应的公钥提交给RSASSA-PKCS1-v1_5-VERIFY算法。
Signing and validation with the RSASSA-PKCS1-v1_5 SHA-384 and RSASSA-PKCS1-v1_5 SHA-512 algorithms is performed identically to the procedure for RSASSA-PKCS1-v1_5 SHA-256 -- just using the corresponding hash algorithms instead of SHA-256.
使用RSASSA-PKCS1-v1_5 SHA-384和RSASSA-PKCS1-v1_5 SHA-512算法进行签名和验证的过程与RSASSA-PKCS1-v1_5 SHA-256的过程相同——只需使用相应的哈希算法而不是SHA-256。
An example using this algorithm is shown in Appendix A.2 of [JWS].
[JWS]的附录A.2中给出了使用该算法的示例。
The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] provides for the use of Elliptic Curve Cryptography, which is able to provide equivalent security to RSA cryptography but using shorter key sizes and with greater processing speed for many operations. This means that ECDSA digital signatures will be substantially smaller in terms of length than equivalently strong RSA digital signatures.
椭圆曲线数字签名算法（ECDSA）[DSS]提供了椭圆曲线密码的使用，它能够提供与RSA密码相同的安全性，但对许多操作使用更短的密钥大小和更高的处理速度。这意味着ECDSA数字签名在长度方面将大大小于等效强RSA数字签名。
This specification defines the use of ECDSA with the P-256 curve and the SHA-256 cryptographic hash function, ECDSA with the P-384 curve and the SHA-384 hash function, and ECDSA with the P-521 curve and the SHA-512 hash function. The P-256, P-384, and P-521 curves are defined in [DSS].
本规范定义了ECDSA与P-256曲线和SHA-256加密哈希函数的使用，ECDSA与P-384曲线和SHA-384哈希函数的使用，以及ECDSA与P-521曲线和SHA-512哈希函数的使用。[DSS]中定义了P-256、P-384和P-521曲线。
The ECDSA P-256 SHA-256 digital signature is generated as follows:
ECDSA P-256 SHA-256数字签名生成如下：
1. Generate a digital signature of the JWS Signing Input using ECDSA P-256 SHA-256 with the desired private key. The output will be the pair (R, S), where R and S are 256-bit unsigned integers.
1. 使用ECDSA P-256 SHA-256和所需私钥生成JWS签名输入的数字签名。输出将是一对（R，S），其中R和S是256位无符号整数。
2. Turn R and S into octet sequences in big-endian order, with each array being be 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values.
2. 将R和S按大端顺序转换为八位字节序列，每个数组的长度为32个八位字节。不得缩短八位字节序列表示以省略值中包含的任何前导零八位字节。
3. Concatenate the two octet sequences in the order R and then S. (Note that many ECDSA implementations will directly produce this concatenation as their output.)
3. 将两个八位组序列按顺序R和S连接起来（注意，许多ECDSA实现将直接产生这种连接作为其输出）
4. The resulting 64-octet sequence is the JWS Signature value.
4. 生成的64个八位组序列是JWS签名值。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:
以下“alg”（算法）头参数值用于指示JWS签名是使用相应算法计算的数字签名值：
+-------------------+-------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+-------------------------------+
| ES256 | ECDSA using P-256 and SHA-256 |
| ES384 | ECDSA using P-384 and SHA-384 |
| ES512 | ECDSA using P-521 and SHA-512 |
+-------------------+-------------------------------+
+-------------------+-------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+-------------------------------+
| ES256 | ECDSA using P-256 and SHA-256 |
| ES384 | ECDSA using P-384 and SHA-384 |
| ES512 | ECDSA using P-521 and SHA-512 |
+-------------------+-------------------------------+
The ECDSA P-256 SHA-256 digital signature for a JWS is validated as follows:
JWS的ECDSA P-256 SHA-256数字签名验证如下：
1. The JWS Signature value MUST be a 64-octet sequence. If it is not a 64-octet sequence, the validation has failed.
1. JWS签名值必须是64个八位字节的序列。如果不是64个八位字节序列，则验证失败。
2. Split the 64-octet sequence into two 32-octet sequences. The first octet sequence represents R and the second S. The values R and S are represented as octet sequences using the Integer-to-OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] (in big-endian octet order).
2. 将64个八位组序列拆分为两个32个八位组序列。第一个八位字节序列表示R和第二个S。值R和S表示为八位字节序列，使用SEC1[SEC1]第2.3.7节中定义的整数到八位字节字符串转换（以大端八位字节顺序）。
3. Submit the JWS Signing Input, R, S, and the public key (x, y) to the ECDSA P-256 SHA-256 validator.
3. 将JWS签名输入R、S和公钥（x、y）提交给ECDSA P-256 SHA-256验证器。
Signing and validation with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 algorithms is performed identically to the procedure for ECDSA P-256 SHA-256 -- just using the corresponding hash algorithms with correspondingly larger result values. For ECDSA P-384 SHA-384, R and S will be 384 bits each, resulting in a 96-octet sequence. For ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a 132-octet sequence. (Note that the Integer-to-OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] used to represent R and S as octet sequences adds zero-valued high-order padding bits when needed to round the size up to a multiple of 8 bits; thus, each 521-bit integer is represented using 528 bits in 66 octets.)
使用ECDSA P-384 SHA-384和ECDSA P-521 SHA-512算法执行签名和验证的过程与ECDSA P-256 SHA-256的过程相同——仅使用具有相应较大结果值的相应哈希算法。对于ECDSA P-384 SHA-384，R和S各为384位，形成96个八位组序列。对于ECDSA P-521 SHA-512，R和S将分别为521位，产生132个八位组序列。（请注意，SEC1[SEC1]第2.3.7节中定义的整数到八位字符串转换用于将R和S表示为八位序列，当需要将大小四舍五入到8位的倍数时，会添加零值高阶填充位；因此，每个521位整数使用66个八位中的528位表示。）
Examples using these algorithms are shown in Appendices A.3 and A.4 of [JWS].
[JWS]的附录A.3和A.4中给出了使用这些算法的示例。
This section defines the use of the RSASSA-PSS digital signature algorithm as defined in Section 8.1 of RFC 3447 [RFC3447] with the MGF1 mask generation function and SHA-2 hash functions, always using the same hash function for both the RSASSA-PSS hash function and the MGF1 hash function. The size of the salt value is the same size as the hash function output. All other algorithm parameters use the defaults specified in Appendix A.2.3 of RFC 3447.
本节定义了RFC 3447[RFC3447]第8.1节中定义的RSASSA-PSS数字签名算法与MGF1掩码生成函数和SHA-2哈希函数的使用，RSASSA-PSS哈希函数和MGF1哈希函数始终使用相同的哈希函数。salt值的大小与哈希函数输出的大小相同。所有其他算法参数使用RFC 3447附录A.2.3中规定的默认值。
A key of size 2048 bits or larger MUST be used with this algorithm.
此算法必须使用2048位或更大的密钥。
The RSASSA-PSS SHA-256 digital signature is generated as follows: generate a digital signature of the JWS Signing Input using RSASSA-PSS-SIGN, the SHA-256 hash function, and the MGF1 mask generation function with SHA-256 with the desired private key. This is the JWS Signature value.
生成RSASSA-PSS SHA-256数字签名的步骤如下：使用RSASSA-PSS-SIGN、SHA-256哈希函数和带有SHA-256的MGF1掩码生成函数以及所需私钥生成JWS签名输入的数字签名。这是JWS签名值。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:
以下“alg”（算法）头参数值用于指示JWS签名是使用相应算法计算的数字签名值：
+-------------------+-----------------------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+-----------------------------------------------+
| PS256 | RSASSA-PSS using SHA-256 and MGF1 with |
| | SHA-256 |
| PS384 | RSASSA-PSS using SHA-384 and MGF1 with |
| | SHA-384 |
| PS512 | RSASSA-PSS using SHA-512 and MGF1 with |
| | SHA-512 |
+-------------------+-----------------------------------------------+
+-------------------+-----------------------------------------------+
| "alg" Param Value | Digital Signature Algorithm |
+-------------------+-----------------------------------------------+
| PS256 | RSASSA-PSS using SHA-256 and MGF1 with |
| | SHA-256 |
| PS384 | RSASSA-PSS using SHA-384 and MGF1 with |
| | SHA-384 |
| PS512 | RSASSA-PSS using SHA-512 and MGF1 with |
| | SHA-512 |
+-------------------+-----------------------------------------------+
The RSASSA-PSS SHA-256 digital signature for a JWS is validated as follows: submit the JWS Signing Input, the JWS Signature, and the public key corresponding to the private key used by the signer to the RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and using MGF1 as the mask generation function with SHA-256.
JWS的RSASSA-PSS SHA-256数字签名验证如下：将JWS签名输入、JWS签名和签名者使用的私钥对应的公钥提交给RSASSA-PSS-VERIFY算法，该算法使用SHA-256作为哈希函数，并使用MGF1作为SHA-256的掩码生成函数。
Signing and validation with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms is performed identically to the procedure for RSASSA-PSS SHA-256 -- just using the alternative hash algorithm in both roles.
使用RSASSA-PSS SHA-384和RSASSA-PSS SHA-512算法进行签名和验证的过程与RSASSA-PSS SHA-256的过程相同——仅在两个角色中使用替代哈希算法。
JWSs MAY also be created that do not provide integrity protection. Such a JWS is called an Unsecured JWS. An Unsecured JWS uses the "alg" value "none" and is formatted identically to other JWSs, but MUST use the empty octet sequence as its JWS Signature value. Recipients MUST verify that the JWS Signature value is the empty octet sequence.
也可以创建不提供完整性保护的JWS。这样的JWS称为不安全JWS。不安全的JWS使用“alg”值“none”，其格式与其他JWS相同，但必须使用空的八位字节序列作为其JWS签名值。收件人必须验证JWS签名值是否为空的八位字节序列。
Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. In order to mitigate downgrade attacks, applications MUST NOT signal acceptance of Unsecured JWSs at a global level, and SHOULD signal acceptance on a per-object basis. See Section 8.5 for security considerations associated with using this algorithm.
支持不安全JWSs的实现不能接受此类对象作为有效对象，除非应用程序指定不受完整性保护的特定对象是可以接受的。默认情况下，实现不能接受不安全的JWSs。为了减轻降级攻击，应用程序不得在全局级别发出接受不安全JWS的信号，而应在每个对象的基础上发出接受的信号。有关使用此算法的安全注意事项，请参见第8.5节。
JWE uses cryptographic algorithms to encrypt or determine the Content Encryption Key (CEK).
JWE使用加密算法加密或确定内容加密密钥（CEK）。
The table below is the set of "alg" (algorithm) Header Parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CEK, producing the JWE Encrypted Key, or to use key agreement to agree upon the CEK.
下表是本规范定义的用于JWE的“alg”（算法）头参数值集。这些算法用于加密CEK，生成JWE加密密钥，或使用密钥协议来商定CEK。
+--------------------+--------------------+--------+----------------+
| "alg" Param Value | Key Management | More | Implementation |
| | Algorithm | Header | Requirements |
| | | Params | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (none) | Recommended- |
| RSA-OAEP | RSAES OAEP using | (none) | Recommended+ |
| | default parameters | | |
| RSA-OAEP-256 | RSAES OAEP using | (none) | Optional |
| | SHA-256 and MGF1 | | |
| | with SHA-256 | | |
| A128KW | AES Key Wrap with | (none) | Recommended |
| | default initial | | |
| | value using | | |
| | 128-bit key | | |
| A192KW | AES Key Wrap with | (none) | Optional |
| | default initial | | |
| | value using | | |
| | 192-bit key | | |
| A256KW | AES Key Wrap with | (none) | Recommended |
| | default initial | | |
| | value using | | |
| | 256-bit key | | |
| dir | Direct use of a | (none) | Recommended |
| | shared symmetric | | |
| | key as the CEK | | |
| ECDH-ES | Elliptic Curve | "epk", | Recommended+ |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | key agreement | | |
| | using Concat KDF | | |
| ECDH-ES+A128KW | ECDH-ES using | "epk", | Recommended |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A128KW" | | |
| ECDH-ES+A192KW | ECDH-ES using | "epk", | Optional |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A192KW" | | |
+--------------------+--------------------+--------+----------------+
| "alg" Param Value | Key Management | More | Implementation |
| | Algorithm | Header | Requirements |
| | | Params | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (none) | Recommended- |
| RSA-OAEP | RSAES OAEP using | (none) | Recommended+ |
| | default parameters | | |
| RSA-OAEP-256 | RSAES OAEP using | (none) | Optional |
| | SHA-256 and MGF1 | | |
| | with SHA-256 | | |
| A128KW | AES Key Wrap with | (none) | Recommended |
| | default initial | | |
| | value using | | |
| | 128-bit key | | |
| A192KW | AES Key Wrap with | (none) | Optional |
| | default initial | | |
| | value using | | |
| | 192-bit key | | |
| A256KW | AES Key Wrap with | (none) | Recommended |
| | default initial | | |
| | value using | | |
| | 256-bit key | | |
| dir | Direct use of a | (none) | Recommended |
| | shared symmetric | | |
| | key as the CEK | | |
| ECDH-ES | Elliptic Curve | "epk", | Recommended+ |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | key agreement | | |
| | using Concat KDF | | |
| ECDH-ES+A128KW | ECDH-ES using | "epk", | Recommended |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A128KW" | | |
| ECDH-ES+A192KW | ECDH-ES using | "epk", | Optional |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A192KW" | | |
| ECDH-ES+A256KW | ECDH-ES using | "epk", | Recommended |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A256KW" | | |
| A128GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 128-bit key | | |
| A192GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 192-bit key | | |
| A256GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 256-bit key | | |
| PBES2-HS256+A128KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-256 and | "p2c" | |
| | "A128KW" wrapping | | |
| PBES2-HS384+A192KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-384 and | "p2c" | |
| | "A192KW" wrapping | | |
| PBES2-HS512+A256KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-512 and | "p2c" | |
| | "A256KW" wrapping | | |
+--------------------+--------------------+--------+----------------+
| ECDH-ES+A256KW | ECDH-ES using | "epk", | Recommended |
| | Concat KDF and CEK | "apu", | |
| | wrapped with | "apv" | |
| | "A256KW" | | |
| A128GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 128-bit key | | |
| A192GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 192-bit key | | |
| A256GCMKW | Key wrapping with | "iv", | Optional |
| | AES GCM using | "tag" | |
| | 256-bit key | | |
| PBES2-HS256+A128KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-256 and | "p2c" | |
| | "A128KW" wrapping | | |
| PBES2-HS384+A192KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-384 and | "p2c" | |
| | "A192KW" wrapping | | |
| PBES2-HS512+A256KW | PBES2 with HMAC | "p2s", | Optional |
| | SHA-512 and | "p2c" | |
| | "A256KW" wrapping | | |
+--------------------+--------------------+--------+----------------+
The More Header Params column indicates what additional Header Parameters are used by the algorithm, beyond "alg", which all use. All but "dir" and "ECDH-ES" also produce a JWE Encrypted Key value.
More Header Params（更多标题参数）列指示除了“alg”（所有标题参数都使用）之外，算法还使用了哪些其他标题参数。除了“dir”和“ECDH-ES”之外，其他所有的都会生成一个JWE加密的密钥值。
The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification.
在“实现需求”列中使用“+”表示在规范的未来版本中需求强度可能会增加。使用“-”表示在规范的未来版本中，需求强度可能会降低。
See Appendix A.2 for a table cross-referencing the JWE "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
本规范中定义的JWE“alg”（算法）值与其他标准和软件包使用的等效标识符的交叉引用表见附录A.2。
This section defines the specifics of encrypting a JWE CEK with RSAES-PKCS1-v1_5 [RFC3447]. The "alg" (algorithm) Header Parameter value "RSA1_5" is used for this algorithm.
本节定义了使用RSAES-PKCS1-v1_5[RFC3447]加密JWE CEK的细节。“alg”（算法）标头参数值“RSA1_5”用于此算法。
A key of size 2048 bits or larger MUST be used with this algorithm.
此算法必须使用2048位或更大的密钥。
An example using this algorithm is shown in Appendix A.2 of [JWE].
[JWE]的附录A.2中给出了使用该算法的示例。
This section defines the specifics of encrypting a JWE CEK with RSAES using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447]. Two sets of parameters for using OAEP are defined, which use different hash functions. In the first case, the default parameters specified in Appendix A.2.1 of RFC 3447 are used. (Those default parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask generation function.) In the second case, the SHA-256 hash function and the MGF1 with SHA-256 mask generation function are used.
本节定义了使用最佳非对称加密填充（OAEP）使用RSAE加密JWE CEK的细节[RFC3447]。定义了使用OAEP的两组参数，它们使用不同的哈希函数。在第一种情况下，使用RFC 3447附录A.2.1中规定的默认参数。（这些默认参数是SHA-1哈希函数和MGF1与SHA-1掩码生成函数。）在第二种情况下，使用SHA-256哈希函数和MGF1与SHA-256掩码生成函数。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm:
以下“alg”（算法）头参数值用于指示JWE加密密钥是使用相应算法加密CEK的结果：
+-------------------+-----------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+-------------------+-----------------------------------------------+
| RSA-OAEP | RSAES OAEP using default parameters |
| RSA-OAEP-256 | RSAES OAEP using SHA-256 and MGF1 with |
| | SHA-256 |
+-------------------+-----------------------------------------------+
+-------------------+-----------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+-------------------+-----------------------------------------------+
| RSA-OAEP | RSAES OAEP using default parameters |
| RSA-OAEP-256 | RSAES OAEP using SHA-256 and MGF1 with |
| | SHA-256 |
+-------------------+-----------------------------------------------+
A key of size 2048 bits or larger MUST be used with these algorithms. (This requirement is based on Table 4 (Security-strength time frames) of NIST SP 800-57 [NIST.800-57], which requires 112 bits of security for new uses, and Table 2 (Comparable strengths) of the same, which states that 2048-bit RSA keys provide 112 bits of security.)
这些算法必须使用2048位或更大的密钥。（该要求基于NIST SP 800-57[NIST.800-57]的表4（安全强度时间框架），该表要求112位安全性用于新用途，以及表2（可比强度），该表规定2048位RSA密钥提供112位安全性。）
An example using RSAES OAEP with the default parameters is shown in Appendix A.1 of [JWE].
[JWE]的附录A.1中给出了使用带有默认参数的RSAES OAEP的示例。
This section defines the specifics of encrypting a JWE CEK with the Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using the default initial value specified in Section 2.2.3.1 of that document.
本节定义了使用该文件第2.2.3.1节中规定的默认初始值，使用高级加密标准（AES）密钥包裹算法[RFC3394]对JWE CEK进行加密的细节。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm and key size:
以下“alg”（算法）头参数值用于指示JWE加密密钥是使用相应算法和密钥大小加密CEK的结果：
+-----------------+-------------------------------------------------+
| "alg" Param | Key Management Algorithm |
| Value | |
+-----------------+-------------------------------------------------+
| A128KW | AES Key Wrap with default initial value using |
| | 128-bit key |
| A192KW | AES Key Wrap with default initial value using |
| | 192-bit key |
| A256KW | AES Key Wrap with default initial value using |
| | 256-bit key |
+-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+
| "alg" Param | Key Management Algorithm |
| Value | |
+-----------------+-------------------------------------------------+
| A128KW | AES Key Wrap with default initial value using |
| | 128-bit key |
| A192KW | AES Key Wrap with default initial value using |
| | 192-bit key |
| A256KW | AES Key Wrap with default initial value using |
| | 256-bit key |
+-----------------+-------------------------------------------------+
An example using this algorithm is shown in Appendix A.3 of [JWE].
[JWE]的附录A.3中给出了使用该算法的示例。
This section defines the specifics of directly performing symmetric key encryption without performing a key wrapping step. In this case, the shared symmetric key is used directly as the Content Encryption Key (CEK) value for the "enc" algorithm. An empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "dir" is used in this case.
本节定义了直接执行对称密钥加密而不执行密钥包装步骤的细节。在这种情况下，共享对称密钥直接用作“enc”算法的内容加密密钥（CEK）值。空的八位字节序列用作JWE加密的密钥值。在这种情况下使用“alg”（算法）头参数值“dir”。
Refer to the security considerations on key lifetimes in Section 8.2 and AES GCM in Section 8.4 when considering utilizing direct encryption.
在考虑使用直接加密时，请参阅第8.2节中关于密钥寿命的安全注意事项和第8.4节中关于AES GCM的安全注意事项。
4.6. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)
4.6. 椭圆曲线Diffie-Hellman瞬时静态密钥协议（ECDH-ES）
This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. The key agreement result can be used in one of two ways:
本节定义了椭圆曲线Diffie-Hellman瞬时静态[RFC6090]以及[NIST.800-56A]第5.8.1节中定义的Concat KDF的密钥协议细节。密钥协议结果可通过以下两种方式之一使用：
1. directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the Direct Key Agreement mode, or
1. 在直接密钥协议模式下，直接作为“enc”算法的内容加密密钥（CEK），或
2. as a symmetric key used to wrap the CEK with the "A128KW", "A192KW", or "A256KW" algorithms, in the Key Agreement with Key Wrapping mode.
2. 作为对称密钥，用于使用“A128KW”、“A192KW”或“A256KW”算法包装CEK，密钥协议采用密钥包装模式。
A new ephemeral public key value MUST be generated for each key agreement operation.
必须为每个密钥协议操作生成新的临时公钥值。
In Direct Key Agreement mode, the output of the Concat KDF MUST be a key of the same length as that used by the "enc" algorithm. In this case, the empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "ECDH-ES" is used in the Direct Key Agreement mode.
在直接密钥协商模式下，Concat KDF的输出必须是与“enc”算法使用的密钥长度相同的密钥。在本例中，空的八位字节序列用作JWE加密的密钥值。“alg”（算法）头参数值“ECDH-ES”用于直接密钥协商模式。
In Key Agreement with Key Wrapping mode, the output of the Concat KDF MUST be a key of the length needed for the specified key wrapping algorithm. In this case, the JWE Encrypted Key is the CEK wrapped with the agreed-upon key.
在密钥协议与密钥包装模式中，Concat KDF的输出必须是指定密钥包装算法所需长度的密钥。在本例中，JWE加密密钥是用约定密钥包装的CEK。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the result of the key agreement algorithm as the key encryption key for the corresponding key wrapping algorithm:
以下“alg”（算法）头参数值用于指示JWE加密密钥是使用密钥协商算法的结果作为相应密钥包装算法的密钥加密密钥加密CEK的结果：
+-----------------+-------------------------------------------------+
| "alg" Param | Key Management Algorithm |
| Value | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A128KW" |
| ECDH-ES+A192KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A192KW" |
| ECDH-ES+A256KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A256KW" |
+-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+
| "alg" Param | Key Management Algorithm |
| Value | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A128KW" |
| ECDH-ES+A192KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A192KW" |
| ECDH-ES+A256KW | ECDH-ES using Concat KDF and CEK wrapped with |
| | "A256KW" |
+-----------------+-------------------------------------------------+
The following Header Parameter names are used for key agreement as defined below.
以下标题参数名称用于密钥协议，定义如下。
The "epk" (ephemeral public key) value created by the originator for the use in key agreement algorithms. This key is represented as a JSON Web Key [JWK] public key value. It MUST contain only public key parameters and SHOULD contain only the minimum JWK parameters necessary to represent the key; other JWK parameters included can be checked for consistency and honored, or they can be ignored. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.
发起者为在密钥协商算法中使用而创建的“epk”（临时公钥）值。此密钥表示为JSON Web密钥[JWK]公钥值。它必须只包含公钥参数，并且只包含表示密钥所需的最小JWK参数；可以检查包含的其他JWK参数的一致性和有效性，也可以忽略它们。当使用这些算法时，这个头参数必须存在，并且必须被实现理解和处理。
The "apu" (agreement PartyUInfo) value for key agreement algorithms using it (such as "ECDH-ES"), represented as a base64url-encoded string. When used, the PartyUInfo value contains information about the producer. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations when these algorithms are used.
使用它的密钥协议算法（如“ECDH-ES”）的“apu”（协议部分YUINFO）值，表示为base64url编码字符串。使用时，PartyInfo值包含有关生产者的信息。此标头参数的使用是可选的。当使用这些算法时，实现必须理解和处理此头参数。
The "apv" (agreement PartyVInfo) value for key agreement algorithms using it (such as "ECDH-ES"), represented as a base64url encoded string. When used, the PartyVInfo value contains information about the recipient. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations when these algorithms are used.
使用它的密钥协议算法（如“ECDH-ES”）的“apv”（协议部分信息）值，表示为base64url编码字符串。使用时，“PartyInfo”值包含有关收件人的信息。此标头参数的使用是可选的。当使用这些算法时，实现必须理解和处理此头参数。
The key derivation process derives the agreed-upon key from the shared secret Z established through the ECDH algorithm, per Section 6.2.2.2 of [NIST.800-56A].
密钥推导过程根据[NIST.800-56A]第6.2.2.2节，从通过ECDH算法建立的共享密钥Z中推导出商定的密钥。
Key derivation is performed using the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A], where the Digest Method is SHA-256. The Concat KDF parameters are set as follows:
使用[NIST.800-56A]第5.8.1节中定义的Concat KDF进行关键推导，其中摘要法为SHA-256。Concat KDF参数设置如下：
Z This is set to the representation of the shared secret Z as an octet sequence.
Z这被设置为共享秘密Z的八位字节序列表示形式。
keydatalen This is set to the number of bits in the desired output key. For "ECDH-ES", this is length of the key used by the "enc" algorithm. For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this is 128, 192, and 256, respectively.
keydatalen这设置为所需输出密钥中的位数。对于“ECDH-ES”，这是“enc”算法使用的密钥的长度。对于“ECDH-ES+A128KW”、“ECDH-ES+A192KW”和“ECDH-ES+A256KW”，分别为128、192和256。
AlgorithmID The AlgorithmID value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. In the Direct Key Agreement case, Data is set to the octets of the ASCII representation of the "enc" Header Parameter value. In the Key Agreement with Key Wrapping case, Data is set to the octets of the ASCII representation of the "alg" (algorithm) Header Parameter value.
AlgorithmID算法ID值的形式为Datalen | | Data，其中数据是由零个或多个八位字节组成的可变长度字符串，Datalen是一个固定长度的大端32位计数器，指示数据的长度（以八位字节为单位）。在直接密钥协议的情况下，数据设置为“enc”头参数值ASCII表示形式的八位字节。在密钥协议与密钥包装的情况下，数据被设置为“alg”（算法）头参数值的ASCII表示的八位字节。
PartyUInfo The PartyUInfo value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. If an "apu" (agreement PartyUInfo) Header Parameter is present, Data is set to the result of base64url decoding the "apu" value and Datalen is set to the number of octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty octet sequence.
PartyUInfo PartyUInfo值的格式为Datalen | | Data，其中Data是零个或多个八位字节的可变长度字符串，Datalen是一个固定长度的大端32位计数器，指示数据的长度（以八位字节为单位）。如果存在“apu”（协议部分YUINFO）头参数，则将数据设置为base64url解码“apu”值的结果，并将Datalen设置为数据中的八位字节数。否则，Datalen设置为0，Data设置为空八位字节序列。
PartyVInfo The PartyVInfo value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. If an "apv" (agreement PartyVInfo) Header Parameter is present, Data is set to the result of base64url decoding the "apv" value and Datalen is set to the number of octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty octet sequence.
PartyVInfo PartyVInfo值的格式为Datalen | | Data，其中Data是零个或多个八位字节的可变长度字符串，Datalen是一个固定长度的大端32位计数器，指示数据的长度（以八位字节为单位）。如果存在“apv”（协议部分yvinfo）头参数，则数据将设置为base64url解码“apv”值的结果，Datalen设置为数据中的八位字节数。否则，Datalen设置为0，Data设置为空八位字节序列。
SuppPubInfo This is set to the keydatalen represented as a 32-bit big-endian integer.
SuppPubInfo将其设置为表示为32位big-endian整数的keydatalen。
SuppPrivInfo This is set to the empty octet sequence.
SuppPrivInfo将其设置为空八位字节序列。
Applications need to specify how the "apu" and "apv" Header Parameters are used for that application. The "apu" and "apv" values MUST be distinct, when used. Applications wishing to conform to [NIST.800-56A] need to provide values that meet the requirements of that document, e.g., by using values that identify the producer and consumer. Alternatively, applications MAY conduct key derivation in a manner similar to "Diffie-Hellman Key Agreement Method" [RFC2631]: in that case, the "apu" parameter MAY either be omitted or represent a random 512-bit value (analogous to PartyAInfo in Ephemeral-Static mode in RFC 2631) and the "apv" parameter SHOULD NOT be present.
应用程序需要指定“apu”和“apv”头参数如何用于该应用程序。使用时，“apu”和“apv”值必须不同。希望符合[NIST.800-56A]的应用程序需要提供符合该文件要求的值，例如，通过使用识别生产者和消费者的值。或者，应用程序可以类似于“Diffie-Hellman密钥协商方法”[RFC2631]的方式进行密钥推导：在这种情况下，“apu”参数可以省略或表示随机512位值（类似于RFC 2631中短暂静态模式下的PartyAInfo），并且“apv”参数不应该存在。
See Appendix C for an example key agreement computation using this method.
有关使用此方法计算密钥协议的示例，请参见附录C。
This section defines the specifics of encrypting a JWE Content Encryption Key (CEK) with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).
本节定义了在Galois/计数器模式（GCM）（[AES]和[NIST.800-38D]）下使用高级加密标准（AES）加密JWE内容加密密钥（CEK）的细节。
Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with this algorithm. The IV is represented in base64url-encoded form as the "iv" (initialization vector) Header Parameter value.
此算法需要使用大小为96位的初始化向量（IV）。IV以base64url编码形式表示为“IV”（初始化向量）头参数值。
The Additional Authenticated Data value used is the empty octet string.
使用的附加身份验证数据值是空的八位字节字符串。
The requested size of the Authentication Tag output MUST be 128 bits, regardless of the key size.
无论密钥大小如何，身份验证标记输出的请求大小必须为128位。
The JWE Encrypted Key value is the ciphertext output.
JWE加密密钥值是密文输出。
The Authentication Tag output is represented in base64url-encoded form as the "tag" (authentication tag) Header Parameter value.
身份验证标签输出以base64url编码形式表示为“标签”（身份验证标签）头参数值。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm and key size:
以下“alg”（算法）头参数值用于指示JWE加密密钥是使用相应算法和密钥大小加密CEK的结果：
+-------------------+---------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+-------------------+---------------------------------------------+
| A128GCMKW | Key wrapping with AES GCM using 128-bit key |
| A192GCMKW | Key wrapping with AES GCM using 192-bit key |
| A256GCMKW | Key wrapping with AES GCM using 256-bit key |
+-------------------+---------------------------------------------+
+-------------------+---------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+-------------------+---------------------------------------------+
| A128GCMKW | Key wrapping with AES GCM using 128-bit key |
| A192GCMKW | Key wrapping with AES GCM using 192-bit key |
| A256GCMKW | Key wrapping with AES GCM using 256-bit key |
+-------------------+---------------------------------------------+
The following Header Parameters are used for AES GCM key encryption.
以下标头参数用于AES GCM密钥加密。
The "iv" (initialization vector) Header Parameter value is the base64url-encoded representation of the 96-bit IV value used for the key encryption operation. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.
“iv”（初始化向量）头参数值是密钥加密操作所用96位iv值的base64url编码表示。当使用这些算法时，这个头参数必须存在，并且必须被实现理解和处理。
The "tag" (authentication tag) Header Parameter value is the base64url-encoded representation of the 128-bit Authentication Tag value resulting from the key encryption operation. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.
“tag”（authentication tag）标头参数值是密钥加密操作产生的128位验证标记值的base64url编码表示。当使用这些算法时，这个头参数必须存在，并且必须被实现理解和处理。
This section defines the specifics of performing password-based encryption of a JWE CEK, by first deriving a key encryption key from a user-supplied password using PBES2 schemes as specified in Section 6.2 of [RFC2898], then by encrypting the JWE CEK using the derived key.
本节定义了对JWE CEK执行基于密码的加密的细节，首先使用[RFC2898]第6.2节中规定的PBES2方案从用户提供的密码中派生密钥加密密钥，然后使用派生密钥加密JWE CEK。
These algorithms use HMAC SHA-2 algorithms as the Pseudorandom Function (PRF) for the PBKDF2 key derivation and AES Key Wrap [RFC3394] for the encryption scheme. The PBES2 password input is an octet sequence; if the password to be used is represented as a text string rather than an octet sequence, the UTF-8 encoding of the text string MUST be used as the octet sequence. The salt parameter MUST be computed from the "p2s" (PBES2 salt input) Header Parameter value and the "alg" (algorithm) Header Parameter value as specified in the "p2s" definition below. The iteration count parameter MUST be provided as the "p2c" (PBES2 count) Header Parameter value. The algorithms respectively use HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 as the PRF and use 128-, 192-, and 256-bit AES Key Wrap keys. Their derived-key lengths respectively are 16, 24, and 32 octets.
这些算法使用HMAC SHA-2算法作为PBKDF2密钥派生的伪随机函数（PRF）和加密方案的AES密钥包裹[RFC3394]。PBES2密码输入为八位字节序列；如果要使用的密码表示为文本字符串而不是八位字节序列，则必须将文本字符串的UTF-8编码用作八位字节序列。salt参数必须根据以下“p2s”定义中规定的“p2s”（PBES2 salt输入）头参数值和“alg”（算法）头参数值进行计算。迭代计数参数必须作为“p2c”（PBES2计数）头参数值提供。算法分别使用HMAC SHA-256、HMAC SHA-384和HMAC SHA-512作为PRF，并使用128、192和256位AES密钥包裹密钥。它们的派生密钥长度分别为16、24和32个八位字节。
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the result of the corresponding password-based encryption algorithm as the key encryption key for the corresponding key wrapping algorithm:
以下“alg”（算法）头参数值用于指示JWE加密密钥是使用相应基于密码的加密算法的结果作为相应密钥包装算法的密钥加密密钥加密CEK的结果：
+--------------------+----------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+--------------------+----------------------------------------------+
| PBES2-HS256+A128KW | PBES2 with HMAC SHA-256 and "A128KW" |
| | wrapping |
| PBES2-HS384+A192KW | PBES2 with HMAC SHA-384 and "A192KW" |
| | wrapping |
| PBES2-HS512+A256KW | PBES2 with HMAC SHA-512 and "A256KW" |
| | wrapping |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| "alg" Param Value | Key Management Algorithm |
+--------------------+----------------------------------------------+
| PBES2-HS256+A128KW | PBES2 with HMAC SHA-256 and "A128KW" |
| | wrapping |
| PBES2-HS384+A192KW | PBES2 with HMAC SHA-384 and "A192KW" |
| | wrapping |
| PBES2-HS512+A256KW | PBES2 with HMAC SHA-512 and "A256KW" |
| | wrapping |
+--------------------+----------------------------------------------+
See Appendix C of the JWK specification [JWK] for an example key encryption computation using "PBES2-HS256+A128KW".
有关使用“PBES2-HS256+A128KW”的密钥加密计算示例，请参见JWK规范[JWK]的附录C。
The following Header Parameters are used for Key Encryption with PBES2.
以下标头参数用于PBES2的密钥加密。
The "p2s" (PBES2 salt input) Header Parameter encodes a Salt Input value, which is used as part of the PBKDF2 salt value. The "p2s" value is BASE64URL(Salt Input). This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.
“p2s”（PBES2 salt input）头参数对salt输入值进行编码，该值用作PBKDF2 salt值的一部分。“p2s”值为BASE64URL（Salt输入）。当使用这些算法时，这个头参数必须存在，并且必须被实现理解和处理。
The salt expands the possible keys that can be derived from a given password. A Salt Input value containing 8 or more octets MUST be used. A new Salt Input value MUST be generated randomly for every encryption operation; see RFC 4086 [RFC4086] for considerations on generating random values. The salt value used is (UTF8(Alg) || 0x00 || Salt Input), where Alg is the "alg" (algorithm) Header Parameter value.
salt扩展了可以从给定密码派生的可能密钥。必须使用包含8个或更多八位字节的Salt输入值。每次加密操作都必须随机生成一个新的Salt输入值；有关生成随机值的注意事项，请参阅RFC 4086[RFC4086]。使用的salt值是（UTF8（Alg）| | 0x00 | | salt输入），其中Alg是“Alg”（算法）头参数值。
The "p2c" (PBES2 count) Header Parameter contains the PBKDF2 iteration count, represented as a positive JSON integer. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.
“p2c”（PBES2 count）头参数包含PBKDF2迭代计数，表示为正JSON整数。当使用这些算法时，这个头参数必须存在，并且必须被实现理解和处理。
The iteration count adds computational expense, ideally compounded by the possible range of keys introduced by the salt. A minimum iteration count of 1000 is RECOMMENDED.
迭代计数增加了计算开销，理想情况下是由salt引入的键的可能范围复合而成。建议最少迭代次数为1000次。
JWE uses cryptographic algorithms to encrypt and integrity-protect the plaintext and to integrity-protect the Additional Authenticated Data.
JWE使用加密算法对明文进行加密和完整性保护，并对附加的经过身份验证的数据进行完整性保护。
The table below is the set of "enc" (encryption algorithm) Header Parameter values that are defined by this specification for use with JWE.
下表是本规范定义的用于JWE的一组“enc”（加密算法）头参数值。
+---------------+----------------------------------+----------------+
| "enc" Param | Content Encryption Algorithm | Implementation |
| Value | | Requirements |
+---------------+----------------------------------+----------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | Required |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.3 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | Optional |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.4 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | Required |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.5 | |
| A128GCM | AES GCM using 128-bit key | Recommended |
| A192GCM | AES GCM using 192-bit key | Optional |
| A256GCM | AES GCM using 256-bit key | Recommended |
+---------------+----------------------------------+----------------+
+---------------+----------------------------------+----------------+
| "enc" Param | Content Encryption Algorithm | Implementation |
| Value | | Requirements |
+---------------+----------------------------------+----------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | Required |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.3 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | Optional |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.4 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | Required |
| | authenticated encryption | |
| | algorithm, as defined in Section | |
| | 5.2.5 | |
| A128GCM | AES GCM using 128-bit key | Recommended |
| A192GCM | AES GCM using 192-bit key | Optional |
| A256GCM | AES GCM using 256-bit key | Recommended |
+---------------+----------------------------------+----------------+
All also use a JWE Initialization Vector value and produce JWE Ciphertext and JWE Authentication Tag values.
它们还都使用JWE初始化向量值，并生成JWE密文和JWE身份验证标记值。
See Appendix A.3 for a table cross-referencing the JWE "enc" (encryption algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
本规范中定义的JWE“enc”（加密算法）值与其他标准和软件包使用的等效标识符的交叉引用表见附录A.3。
This section defines a family of authenticated encryption algorithms built using a composition of AES [AES] in Cipher Block Chaining (CBC) mode [NIST.800-38A] with PKCS #7 padding operations per Section 6.3 of [RFC5652] and HMAC ([RFC2104] and [SHS]) operations. This algorithm family is called AES_CBC_HMAC_SHA2. It also defines three instances of this family: the first using 128-bit CBC keys and HMAC SHA-256, the second using 192-bit CBC keys and HMAC SHA-384, and the third using 256-bit CBC keys and HMAC SHA-512. Test cases for these algorithms can be found in Appendix B.
本节定义了一系列认证加密算法，这些算法使用密码块链接（CBC）模式[NIST.800-38A]中的AES[AES]组合构建，并根据[RFC5652]第6.3节和HMAC（[RFC2104]和[SHS]）操作进行PKCS#7填充操作。该算法族称为AES_CBC_HMAC_SHA2。它还定义了该系列的三个实例：第一个使用128位CBC密钥和HMAC SHA-256，第二个使用192位CBC密钥和HMAC SHA-384，第三个使用256位CBC密钥和HMAC SHA-512。这些算法的测试用例见附录B。
These algorithms are based upon "Authenticated Encryption with AES-CBC and HMAC-SHA" [AEAD-CBC-SHA], performing the same cryptographic computations, but with the Initialization Vector (IV) and Authentication Tag values remaining separate, rather than being concatenated with the ciphertext value in the output representation. This option is discussed in Appendix B of that specification. This algorithm family is a generalization of the algorithm family in [AEAD-CBC-SHA] and can be used to implement those algorithms.
这些算法基于“AES-CBC和HMAC-SHA认证加密”[AEAD-CBC-SHA]，执行相同的加密计算，但初始化向量（IV）和认证标签值保持分离，而不是与输出表示中的密文值串联。该规范附录B中讨论了该选项。该算法族是[AEAD-CBC-SHA]中算法族的推广，可用于实现这些算法。
We use the following notational conventions.
我们使用以下符号约定。
CBC-PKCS7-ENC(X, P) denotes the AES-CBC encryption of P using PKCS #7 padding utilizing the cipher with the key X. MAC(Y, M) denotes the application of the MAC to the message M using the key Y.
CBC-PKCS7-ENC（X，P）表示使用PKCS#7填充使用密钥X的密码对P进行AES-CBC加密。MAC（Y，M）表示使用密钥Y将MAC应用于消息M。
This section defines AES_CBC_HMAC_SHA2 in a manner that is independent of the AES-CBC key size or hash function to be used. Sections 5.2.2.1 and 5.2.2.2 define the generic encryption and decryption algorithms. Sections 5.2.3 through 5.2.5 define instances of AES_CBC_HMAC_SHA2 that specify those details.
本节以独立于要使用的AES-CBC密钥大小或哈希函数的方式定义AES_CBC_HMAC_SHA2。第5.2.2.1节和第5.2.2.2节定义了通用加密和解密算法。第5.2.3节至第5.2.5节定义了AES_CBC_HMAC_SHA2的实例，详细说明了这些细节。
The authenticated encryption algorithm takes as input four octet strings: a secret key K, a plaintext P, Additional Authenticated Data A, and an Initialization Vector IV. The authenticated ciphertext value E and the Authentication Tag value T are provided as outputs. The data in the plaintext are encrypted and authenticated, and the Additional Authenticated Data are authenticated, but not encrypted.
认证加密算法将四个八位字符串作为输入：密钥K、明文P、附加认证数据a和初始化向量IV。认证密文值E和认证标签值T作为输出。明文中的数据经过加密和身份验证，其他经过身份验证的数据经过身份验证，但不加密。
The encryption process is as follows, or uses an equivalent set of steps:
加密过程如下，或使用一组等效的步骤：
1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string.
1. 从输入键K生成辅助键MAC_键和ENC_键，如下所示。这两个键中的每一个都是八位字节字符串。
MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in order. ENC_KEY consists of the final ENC_KEY_LEN octets of K, in order.
MAC_KEY由K的初始MAC_KEY_LEN八位字节按顺序组成。ENC_KEY由K的最终ENC_KEY_LEN八位字节按顺序组成。
The number of octets in the input key K MUST be the sum of MAC_KEY_LEN and ENC_KEY_LEN. The values of these parameters are specified by the Authenticated Encryption algorithms in Sections 5.2.3 through 5.2.5. 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 identifier "AES_CBC_HMAC_SHA2".
输入密钥K中的八位字节数必须是MAC_key_LEN和ENC_key_LEN之和。这些参数的值由第5.2.3节至第5.2.5节中的认证加密算法指定。注意，在输入密钥K中，MAC密钥在加密密钥之前；这与标识符“AES_CBC_HMAC_SHA2”中的算法名称顺序相反。
2. The IV used is a 128-bit value generated randomly or pseudorandomly for use in the cipher.
2. 使用的IV是随机或伪随机生成的128位值，用于密码。
3. The plaintext is CBC encrypted using PKCS #7 padding using ENC_KEY as the key and the IV. We denote the ciphertext output from this step as E.
3. 明文使用PKCS#7填充进行CBC加密，使用ENC#u密钥作为密钥和IV。我们将此步骤的密文输出表示为E。
4. The octet string AL is equal to the number of bits in the Additional Authenticated Data A expressed as a 64-bit unsigned big-endian integer.
4. 八进制字符串AL等于附加认证数据A中的位数，表示为64位无符号大端整数。
5. A message Authentication Tag T is computed by applying HMAC [RFC2104] to the following data, in order:
5. 通过将HMAC[RFC2104]应用于以下数据来计算消息认证标签T，顺序如下：
the Additional Authenticated Data A, the Initialization Vector IV, the ciphertext E computed in the previous step, and the octet string AL defined above.
附加的认证数据A、初始化向量IV、在上一步骤中计算的密文E以及上面定义的八位字节字符串AL。
The string MAC_KEY is used as the MAC key. We denote the output of the MAC computed in this step as M. The first T_LEN octets of M are used as T.
字符串MAC_KEY用作MAC KEY。我们将在这一步中计算的MAC的输出表示为M。M的第一个T_LEN八位元用作T。
6. The ciphertext E and the Authentication Tag T are returned as the outputs of the authenticated encryption.
6. 密文E和认证标签T作为认证加密的输出返回。
The encryption process can be illustrated as follows. Here K, P, A, IV, and E denote the key, plaintext, Additional Authenticated Data, Initialization Vector, and ciphertext, respectively.
加密过程可以如下所示。这里K、P、A、IV和E分别表示密钥、明文、附加认证数据、初始化向量和密文。
MAC_KEY = initial MAC_KEY_LEN octets of K, ENC_KEY = final ENC_KEY_LEN octets of K, E = CBC-PKCS7-ENC(ENC_KEY, P), M = MAC(MAC_KEY, A || IV || E || AL), T = initial T_LEN octets of M.
MAC_-KEY=K的初始MAC_-KEY八位字节，ENC_-KEY=K的最终ENC_-KEY八位字节，E=CBC-PKCS7-ENC（ENC_-KEY，P），M=MAC（MAC_-KEY，A | IV | E | AL），T=M的初始T_-LEN八位字节。
The authenticated decryption operation has five inputs: K, A, IV, E, and T as defined above. It has only a single output: either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. The authenticated decryption algorithm is as follows, or uses an equivalent set of steps:
经过身份验证的解密操作有五个输入：K、A、IV、E和T，如上所述。它只有一个输出：纯文本值P或特殊符号FAIL表示输入不真实。经过身份验证的解密算法如下所示，或使用一组等效的步骤：
1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as in Step 1 of Section 5.2.2.1.
1. 如第5.2.2.1节步骤1所示，从输入键K生成辅助键MAC_键和ENC_键。
2. The integrity and authenticity of A and E are checked by computing an HMAC with the inputs as in Step 5 of Section 5.2.2.1. The value T, from the previous step, is compared to the first MAC_KEY length bits of the HMAC output. If those values are identical, then A and E are considered valid, and processing is continued. Otherwise, all of the data used in the MAC validation are discarded, and the authenticated decryption operation returns an indication that it failed, and the operation halts. (But see Section 11.5 of [JWE] for security considerations on thwarting timing attacks.)
2. 通过使用第5.2.2.1节第5步中的输入计算HMAC，检查A和E的完整性和真实性。将上一步骤中的值T与HMAC输出的第一个MAC_密钥长度位进行比较。如果这些值相同，则认为A和E有效，并继续处理。否则，MAC验证中使用的所有数据都将被丢弃，经过身份验证的解密操作将返回失败的指示，操作将停止。（关于阻止定时攻击的安全考虑，请参见[JWE]第11.5节。）
3. The value E is decrypted and the PKCS #7 padding is checked and removed. The value IV is used as the Initialization Vector. The value ENC_KEY is used as the decryption key.
3. 解密值E，检查并删除PKCS#7填充。值IV用作初始化向量。值ENC_KEY用作解密密钥。
4. The plaintext value is returned.
4. 返回纯文本值。
This algorithm is a concrete instantiation of the generic AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message authentication code [RFC2104] with the SHA-256 hash function [SHS] to provide message authentication, with the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA-256-128 algorithm defined in [RFC4868]. For encryption, it uses AES in the CBC mode of operation as defined in Section 6.2 of [NIST.800-38A], with PKCS #7 padding and a 128-bit IV value.
该算法是上述通用AES_CBC_HMAC_SHA2算法的具体实例。它使用HMAC消息身份验证码[RFC2104]和SHA-256哈希函数[SHS]来提供消息身份验证，HMAC输出被截断为128位，与[RFC4868]中定义的HMAC-SHA-256-128算法相对应。对于加密，它在[NIST.800-38A]第6.2节中定义的CBC操作模式下使用AES，使用PKCS#7填充和128位IV值。
The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256 are:
AES_CBC_HMAC_SHA2特定于AES_128_CBC_HMAC_SHAU 256的参数为：
The input key K is 32 octets long. ENC_KEY_LEN is 16 octets. MAC_KEY_LEN is 16 octets. The SHA-256 hash algorithm is used for the HMAC. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by stripping off the final 16 octets.
输入键K的长度为32个八位字节。ENC_KEY_LEN是16个八位字节。MAC_KEY_LEN是16个八位组。HMAC使用SHA-256哈希算法。HMAC-SHA-256输出被截断为T_LEN=16个八位字节，方法是去掉最后的16个八位字节。
AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but with the following differences:
AES_192_CBC_HMAC_SHA_384基于AES_128_CBC_HMAC_SHA_256，但有以下区别：
The input key K is 48 octets long instead of 32. ENC_KEY_LEN is 24 octets instead of 16. MAC_KEY_LEN is 24 octets instead of 16. SHA-384 is used for the HMAC instead of SHA-256. The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of 16.
输入键K的长度为48个八位字节，而不是32个八位字节。ENC_KEY_LEN是24个八位字节，而不是16个。MAC_KEY_LEN是24个八位字节，而不是16个。HMAC使用SHA-384代替SHA-256。HMAC SHA-384值被截断为T_LEN=24个八位字节，而不是16个八位字节。
AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but with the following differences:
AES_256_CBC_HMAC_SHA_512基于AES_128_CBC_HMAC_SHA_256，但有以下区别：
The input key K is 64 octets long instead of 32. ENC_KEY_LEN is 32 octets instead of 16. MAC_KEY_LEN is 32 octets instead of 16. SHA-512 is used for the HMAC instead of SHA-256. The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of 16.
输入键K的长度为64个八位字节，而不是32个八位字节。ENC_KEY_LEN是32个八位字节，而不是16个。MAC_KEY_LEN是32个八位字节，而不是16个。HMAC使用SHA-512而不是SHA-256。HMAC SHA-512值被截断为T_LEN=32个八位字节，而不是16个八位字节。
This section defines the specifics of performing authenticated encryption with the AES_CBC_HMAC_SHA2 algorithms.
本节定义了使用AES_CBC_HMAC_SHA2算法执行认证加密的细节。
The CEK is used as the secret key K.
CEK用作密钥K。
The following "enc" (encryption algorithm) Header Parameter values are used to indicate that the JWE Ciphertext and JWE Authentication Tag values have been computed using the corresponding algorithm:
以下“enc”（加密算法）标头参数值用于指示已使用相应算法计算了JWE密文和JWE身份验证标记值：
+---------------+---------------------------------------------------+
| "enc" Param | Content Encryption Algorithm |
| Value | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 authenticated encryption |
| | algorithm, as defined in Section 5.2.3 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 authenticated encryption |
| | algorithm, as defined in Section 5.2.4 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 authenticated encryption |
| | algorithm, as defined in Section 5.2.5 |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| "enc" Param | Content Encryption Algorithm |
| Value | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 authenticated encryption |
| | algorithm, as defined in Section 5.2.3 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 authenticated encryption |
| | algorithm, as defined in Section 5.2.4 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 authenticated encryption |
| | algorithm, as defined in Section 5.2.5 |
+---------------+---------------------------------------------------+
This section defines the specifics of performing authenticated encryption with AES in Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).
本节定义了在伽罗瓦/计数器模式（GCM）（[AES]和[NIST.800-38D]）下使用AES执行认证加密的细节。
The CEK is used as the encryption key.
CEK用作加密密钥。
Use of an IV of size 96 bits is REQUIRED with this algorithm.
此算法需要使用96位的IV。
The requested size of the Authentication Tag output MUST be 128 bits, regardless of the key size.
无论密钥大小如何，身份验证标记输出的请求大小必须为128位。
The following "enc" (encryption algorithm) Header Parameter values are used to indicate that the JWE Ciphertext and JWE Authentication Tag values have been computed using the corresponding algorithm and key size:
以下“enc”（加密算法）标头参数值用于指示已使用相应的算法和密钥大小计算了JWE密文和JWE身份验证标记值：
+-------------------+------------------------------+
| "enc" Param Value | Content Encryption Algorithm |
+-------------------+------------------------------+
| A128GCM | AES GCM using 128-bit key |
| A192GCM | AES GCM using 192-bit key |
| A256GCM | AES GCM using 256-bit key |
+-------------------+------------------------------+
+-------------------+------------------------------+
| "enc" Param Value | Content Encryption Algorithm |
+-------------------+------------------------------+
| A128GCM | AES GCM using 128-bit key |
| A192GCM | AES GCM using 192-bit key |
| A256GCM | AES GCM using 256-bit key |
+-------------------+------------------------------+
An example using this algorithm is shown in Appendix A.1 of [JWE].
[JWE]的附录A.1中给出了使用该算法的示例。
A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a cryptographic key. These keys can be either asymmetric or symmetric. They can hold both public and private information about the key. This section defines the parameters for keys using the algorithms specified by this document.
JSON Web密钥（JWK）[JWK]是表示加密密钥的JSON数据结构。这些密钥可以是不对称的，也可以是对称的。它们可以保存有关密钥的公共和私人信息。本节使用本文档指定的算法定义密钥的参数。
The table below is the set of "kty" (key type) parameter values that are defined by this specification for use in JWKs.
下表是本规范定义的用于JWKs的一组“kty”（键类型）参数值。
+-------------+--------------------------------+--------------------+
| "kty" Param | Key Type | Implementation |
| Value | | Requirements |
+-------------+--------------------------------+--------------------+
| EC | Elliptic Curve [DSS] | Recommended+ |
| RSA | RSA [RFC3447] | Required |
| oct | Octet sequence (used to | Required |
| | represent symmetric keys) | |
+-------------+--------------------------------+--------------------+
+-------------+--------------------------------+--------------------+
| "kty" Param | Key Type | Implementation |
| Value | | Requirements |
+-------------+--------------------------------+--------------------+
| EC | Elliptic Curve [DSS] | Recommended+ |
| RSA | RSA [RFC3447] | Required |
| oct | Octet sequence (used to | Required |
| | represent symmetric keys) | |
+-------------+--------------------------------+--------------------+
The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification.
在“实现需求”列中使用“+”表示在规范的未来版本中需求强度可能会增加。
JWKs can represent Elliptic Curve [DSS] keys. In this case, the "kty" member value is "EC".
JWKs可以表示椭圆曲线[DSS]密钥。在这种情况下，“kty”成员值为“EC”。
An Elliptic Curve public key is represented by a pair of coordinates drawn from a finite field, which together define a point on an Elliptic Curve. The following members MUST be present for all Elliptic Curve public keys:
椭圆曲线公钥由从有限域绘制的一对坐标表示，这些坐标共同定义椭圆曲线上的一个点。对于所有椭圆曲线公钥，必须有以下成员在场：
o "crv" o "x"
o “crv”o“x”
The following member MUST also be present for Elliptic Curve public keys for the three curves defined in the following section:
以下成员还必须出席以下部分中定义的三条曲线的椭圆曲线公钥：
o "y"
o “y”
The "crv" (curve) parameter identifies the cryptographic curve used with the key. Curve values from [DSS] used by this specification are:
“crv”（曲线）参数标识与密钥一起使用的加密曲线。本规范使用的[DSS]曲线值为：
o "P-256" o "P-384" o "P-521"
o “P-256”o“P-384”o“P-521”
These values are registered in the IANA "JSON Web Key Elliptic Curve" registry defined in Section 7.6. Additional "crv" values can be registered by other specifications. Specifications registering additional curves must define what parameters are used to represent keys for the curves registered. The "crv" value is a case-sensitive string.
这些值在第7.6节定义的IANA“JSON Web密钥椭圆曲线”注册表中注册。其他“crv”值可通过其他规范注册。注册其他曲线的规范必须定义用于表示注册曲线关键点的参数。“crv”值是区分大小写的字符串。
SEC1 [SEC1] point compression is not supported for any of these three curves.
这三条曲线中的任何一条都不支持SEC1[SEC1]点压缩。
The "x" (x coordinate) parameter contains the x coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string representation of the coordinate, as defined in Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "P-521", the octet string must be 66 octets long.
“x”（x坐标）参数包含椭圆曲线点的x坐标。它表示为坐标的八位字节字符串表示的base64url编码，如第1节[SEC1]第2.3.5节所定义。此八位字符串的长度必须是“crv”参数中指定曲线坐标的完整大小。例如，如果“crv”的值为“P-521”，则八位字节字符串的长度必须为66个八位字节。
The "y" (y coordinate) parameter contains the y coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string representation of the coordinate, as defined in Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "P-521", the octet string must be 66 octets long.
“y”（y坐标）参数包含椭圆曲线点的y坐标。它表示为坐标的八位字节字符串表示的base64url编码，如第1节[SEC1]第2.3.5节所定义。此八位字符串的长度必须是“crv”参数中指定曲线坐标的完整大小。例如，如果“crv”的值为“P-521”，则八位字节字符串的长度必须为66个八位字节。
In addition to the members used to represent Elliptic Curve public keys, the following member MUST be present to represent Elliptic Curve private keys.
除了用于表示椭圆曲线公钥的成员外，还必须有以下成员来表示椭圆曲线私钥。
The "d" (ECC private key) parameter contains the Elliptic Curve private key value. It is represented as the base64url encoding of the octet string representation of the private key value, as defined in Section 2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve).
“d”（ECC私钥）参数包含椭圆曲线私钥值。它表示为私钥值的八位字节字符串表示的base64url编码，如SEC1[SEC1]第2.3.7节所定义。此八位字节字符串的长度必须为上限（对数基-2（n）/8）八位字节（其中n是曲线的顺序）。
JWKs can represent RSA [RFC3447] keys. In this case, the "kty" member value is "RSA". The semantics of the parameters defined below are the same as those defined in Sections 3.1 and 3.2 of RFC 3447.
JWKs可以表示RSA[RFC3447]密钥。在这种情况下，“kty”成员值是“RSA”。下面定义的参数的语义与RFC 3447第3.1节和第3.2节中定义的相同。
The following members MUST be present for RSA public keys.
RSA公钥必须有以下成员在场。
The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.
“n”（模数）参数包含RSA公钥的模数值。它表示为Base64urlUInt编码值。
Note that implementers have found that some cryptographic libraries prefix an extra zero-valued octet to the modulus representations they return, for instance, returning 257 octets for a 2048-bit key, rather than 256. Implementations using such libraries will need to take care to omit the extra octet from the base64url-encoded representation.
请注意，实现者已经发现，一些加密库在返回的模表示前加上一个额外的零值八位字节，例如，2048位密钥返回257个八位字节，而不是256个。使用此类库的实现需要注意从base64url编码表示中省略额外的八位字节。
The "e" (exponent) parameter contains the exponent value for the RSA public key. It is represented as a Base64urlUInt-encoded value.
“e”（指数）参数包含RSA公钥的指数值。它表示为Base64urlUInt编码值。
For instance, when representing the value 65537, the octet sequence to be base64url-encoded MUST consist of the three octets [1, 0, 1]; the resulting representation for this value is "AQAB".
例如，当表示值65537时，要进行base64url编码的八位字节序列必须由三个八位字节组成[1，0，1]；该值的结果表示为“AQAB”。
In addition to the members used to represent RSA public keys, the following members are used to represent RSA private keys. The parameter "d" is REQUIRED for RSA private keys. The others enable optimizations and SHOULD be included by producers of JWKs representing RSA private keys. If the producer includes any of the other private key parameters, then all of the others MUST be present, with the exception of "oth", which MUST only be present when more than two prime factors were used.
除了用于表示RSA公钥的成员外，以下成员还用于表示RSA私钥。RSA私钥需要参数“d”。其他的支持优化，应该被代表RSA私钥的JWK的生产者包括在内。如果生产者包括任何其他私钥参数，则所有其他私钥参数都必须存在，但“oth”除外，只有在使用了两个以上的素因子时，“oth”才必须存在。
The "d" (private exponent) parameter contains the private exponent value for the RSA private key. It is represented as a Base64urlUInt-encoded value.
“d”（私有指数）参数包含RSA私钥的私有指数值。它表示为Base64urlUInt编码值。
The "p" (first prime factor) parameter contains the first prime factor. It is represented as a Base64urlUInt-encoded value.
“p”（第一素因子）参数包含第一素因子。它表示为Base64urlUInt编码值。
The "q" (second prime factor) parameter contains the second prime factor. It is represented as a Base64urlUInt-encoded value.
“q”（第二素数因子）参数包含第二素数因子。它表示为Base64urlUInt编码值。
The "dp" (first factor CRT exponent) parameter contains the Chinese Remainder Theorem (CRT) exponent of the first factor. It is represented as a Base64urlUInt-encoded value.
“dp”（第一因子CRT指数）参数包含第一因子的中国剩余定理（CRT）指数。它表示为Base64urlUInt编码值。
The "dq" (second factor CRT exponent) parameter contains the CRT exponent of the second factor. It is represented as a Base64urlUInt-encoded value.
“dq”（第二因子CRT指数）参数包含第二因子的CRT指数。它表示为Base64urlUInt编码值。
The "qi" (first CRT coefficient) parameter contains the CRT coefficient of the second factor. It is represented as a Base64urlUInt-encoded value.
“qi”（第一个CRT系数）参数包含第二个因子的CRT系数。它表示为Base64urlUInt编码值。
The "oth" (other primes info) parameter contains an array of information about any third and subsequent primes, should they exist. When only two primes have been used (the normal case), this parameter MUST be omitted. When three or more primes have been used, the number of array elements MUST be the number of primes used minus two. For more information on this case, see the description of the OtherPrimeInfo parameters in Appendix A.1.2 of RFC 3447 [RFC3447], upon which the following parameters are modeled. If the consumer of a JWK does not support private keys with more than two primes and it encounters a private key that includes the "oth" parameter, then it MUST NOT use the key. Each array element MUST be an object with the following members.
“oth”（其他素数信息）参数包含关于任何第三个和后续素数（如果存在）的信息数组。如果只使用了两个素数（正常情况），则必须忽略此参数。当使用了三个或更多素数时，数组元素的数量必须是所使用素数的数量减去2。有关这种情况的更多信息，请参见RFC 3447[RFC3447]附录A.1.2中的OtherPrimeInfo参数说明，以下参数是根据该说明建模的。如果JWK的使用者不支持具有两个以上素数的私钥，并且遇到包含“oth”参数的私钥，则不得使用该密钥。每个数组元素必须是具有以下成员的对象。
The "r" (prime factor) parameter within an "oth" array member represents the value of a subsequent prime factor. It is represented as a Base64urlUInt-encoded value.
“oth”数组成员中的“r”（素因子）参数表示后续素因子的值。它表示为Base64urlUInt编码值。
The "d" (factor CRT exponent) parameter within an "oth" array member represents the CRT exponent of the corresponding prime factor. It is represented as a Base64urlUInt-encoded value.
“oth”数组成员中的“d”（因子CRT指数）参数表示相应素因子的CRT指数。它表示为Base64urlUInt编码值。
The "t" (factor CRT coefficient) parameter within an "oth" array member represents the CRT coefficient of the corresponding prime factor. It is represented as a Base64urlUInt-encoded value.
“oth”数组成员中的“t”（因子CRT系数）参数表示相应素因子的CRT系数。它表示为Base64urlUInt编码值。
When the JWK "kty" member value is "oct" (octet sequence), the member "k" (see Section 6.4.1) is used to represent a symmetric key (or another key whose value is a single octet sequence). An "alg" member SHOULD also be present to identify the algorithm intended to be used with the key, unless the application uses another means or convention to determine the algorithm used.
当JWK“kty”成员值为“oct”（八位字节序列）时，成员“k”（见第6.4.1节）用于表示对称密钥（或值为单个八位字节序列的另一密钥）。“alg”成员也应在场，以识别拟与密钥一起使用的算法，除非应用程序使用其他方法或约定来确定所使用的算法。
The "k" (key value) parameter contains the value of the symmetric (or other single-valued) key. It is represented as the base64url encoding of the octet sequence containing the key value.
“k”（键值）参数包含对称（或其他单值）键的值。它表示为包含键值的八位字节序列的base64url编码。
The following registration procedure is used for all the registries established by this specification.
以下注册程序适用于本规范建立的所有注册中心。
The registration procedure for values is Specification Required [RFC5226] after a three-week review period on the jose-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
在对jose reg进行为期三周的审查后，需要规范[RFC5226]中规定的值注册程序-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家在确信此类规范将发布后，可批准注册。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register algorithm: example").
发送至邮件列表供审查的注册请求应使用适当的主题（例如，“注册请求算法：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
超过21天未确定的注册请求可提请IESG注意（使用iesg@ietf.org邮件列表）以供解决。
Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.
指定专家应适用的标准包括确定拟议登记是否与现有功能重复，是否可能具有普遍适用性或仅对单一申请有用，以及登记说明是否明确。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
建议任命多名指定专家，他们能够代表使用本规范的不同应用的观点，以便对注册决定进行广泛知情的审查。如果注册决定可能被视为对某一专家造成利益冲突，该专家应服从其他专家的判断。
This specification establishes the IANA "JSON Web Signature and Encryption Algorithms" registry for values of the JWS and JWE "alg" (algorithm) and "enc" (encryption algorithm) Header Parameters. The registry records the algorithm name, the algorithm description, the algorithm usage locations, the implementation requirements, the change controller, and a reference to the specification that defines it. The same algorithm name can be registered multiple times, provided that the sets of usage locations are disjoint.
本规范为JWS和JWE“alg”（算法）和“enc”（加密算法）头参数的值建立IANA“JSON Web签名和加密算法”注册表。注册表记录算法名称、算法描述、算法使用位置、实现要求、更改控制器以及对定义它的规范的引用。如果使用位置集不相交，则可以多次注册相同的算法名称。
It is suggested that the length of the key be included in the algorithm name when multiple variations of algorithms are being registered that use keys of different lengths and the key lengths for each need to be fixed (for instance, because they will be created by key derivation functions). This allows readers of the JSON text to more easily make security decisions.
建议在注册使用不同长度密钥的多个算法变体时，将密钥长度包括在算法名称中，并且每个算法的密钥长度需要固定（例如，因为它们将由密钥派生函数创建）。这使得JSON文本的读者能够更容易地做出安全决策。
The Designated Experts should perform reasonable due diligence that algorithms being registered either are currently considered cryptographically credible or are being registered as Deprecated or Prohibited.
指定的专家应进行合理的尽职调查，确保正在注册的算法目前被认为在加密方面是可信的，或者正在注册为不推荐或禁止的算法。
The implementation requirements of an algorithm may be changed over time as the cryptographic landscape evolves, for instance, to change the status of an algorithm to Deprecated or to change the status of an algorithm from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.
算法的实现要求可能随着时间的推移而改变，例如，将算法的状态更改为不推荐，或将算法的状态从可选更改为推荐+或必需。在指定专家审查后，仅允许在规范要求的基础上更改实施要求，新规范定义了修订后的实施要求级别。
Algorithm Name: The name requested (e.g., "HS256"). This name is a case-sensitive ASCII string. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
算法名称：请求的名称（例如，“HS256”）。此名称是区分大小写的ASCII字符串。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Algorithm Description: Brief description of the algorithm (e.g., "HMAC using SHA-256").
算法描述：算法的简要描述（例如，“HMAC使用SHA-256”）。
Algorithm Usage Location(s): The algorithm usage locations. This must be one or more of the values "alg" or "enc" if the algorithm is to be used with JWS or JWE. The value "JWK" is used if the algorithm identifier will be used as a JWK "alg" member value, but will not be used with JWS or JWE; this could be the case, for instance, for non-authenticated encryption algorithms. Other values may be used with the approval of a Designated Expert.
算法使用位置：算法使用位置。如果算法要与JWS或JWE一起使用，则必须是一个或多个值“alg”或“enc”。如果算法标识符将用作JWK“alg”成员值，则使用值“JWK”，但不会与JWS或JWE一起使用；例如，对于未经身份验证的加密算法，情况可能就是这样。经指定专家批准，可使用其他值。
JOSE Implementation Requirements: The algorithm implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-". The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification. Any identifiers registered for non-authenticated encryption algorithms or other algorithms that are otherwise unsuitable for direct use as JWS or JWE algorithms must be registered as "Prohibited".
JOSE实现要求：JWS和JWE的算法实现要求，必须是Required、Recommended、Optional、Deprecated或bankind这些词之一。或者，单词后面可以跟一个“+”或“-”。使用“+”表示在规范的未来版本中，需求强度可能会增加。使用“-”表示在规范的未来版本中，需求强度可能会降低。为非认证加密算法或其他不适合直接用作JWS或JWE算法的算法注册的任何标识符必须注册为“禁止”。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
Algorithm Analysis Documents(s): References to a publication or publications in well-known cryptographic conferences, by national standards bodies, or by other authoritative sources analyzing the cryptographic soundness of the algorithm to be registered. The Designated Experts may require convincing evidence of the cryptographic soundness of a new algorithm to be provided with the registration request unless the algorithm is being registered as Deprecated or Prohibited. Having gone through working group and IETF review, the initial registrations made by this document are exempt from the need to provide this information.
算法分析文件：参考由国家标准机构或分析待注册算法密码可靠性的其他权威来源在知名密码会议上发表的一份或多份出版物。指定专家可能要求在注册请求中提供新算法密码可靠性的令人信服的证据，除非该算法被注册为不推荐或禁止。经过工作组和IETF审查后，本文件的初始注册不需要提供此信息。
o Algorithm Name: "HS256" o Algorithm Description: HMAC using SHA-256 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Required o Change Controller: IESG o Specification Document(s): Section 3.2 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“HS256”o算法说明：HMAC使用SHA-256 o算法使用位置：“alg”o实现要求：所需o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.2节：不适用
o Algorithm Name: "HS384" o Algorithm Description: HMAC using SHA-384 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“HS384”o算法描述：HMAC使用SHA-384 o算法使用位置：“alg”o实现要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.2节：不适用
o Algorithm Name: "HS512" o Algorithm Description: HMAC using SHA-512 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“HS512”o算法说明：HMAC使用SHA-512 o算法使用位置：“alg”o实现要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.2节：不适用
o Algorithm Name: "RS256" o Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-256 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 3.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RS256”o算法说明：RSASSA-PKCS1-v1_5使用SHA-256 o算法使用位置：“alg”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.3节：不适用
o Algorithm Name: "RS384" o Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-384 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RS384”o算法描述：RSASSA-PKCS1-v1_5使用SHA-384 o算法使用位置：“alg”o实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.3节：不适用
o Algorithm Name: "RS512" o Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-512 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RS512”o算法说明：RSASSA-PKCS1-v1_5使用SHA-512 o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.3节：不适用
o Algorithm Name: "ES256" o Algorithm Description: ECDSA using P-256 and SHA-256 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended+ o Change Controller: IESG o Specification Document(s): Section 3.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ES256”o算法描述：使用P-256和SHA-256 o算法的ECDSA使用位置：“alg”o JOSE实施要求：推荐+o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.4节：不适用
o Algorithm Name: "ES384" o Algorithm Description: ECDSA using P-384 and SHA-384 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ES384”o算法描述：使用P-384和SHA-384 o算法的ECDSA使用位置：“alg”o JOSE实施要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.4节：不适用
o Algorithm Name: "ES512" o Algorithm Description: ECDSA using P-521 and SHA-512 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ES512”o算法描述：使用P-521和SHA-512 o算法的ECDSA使用位置：“alg”o JOSE实施要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.4节：不适用
o Algorithm Name: "PS256" o Algorithm Description: RSASSA-PSS using SHA-256 and MGF1 with SHA-256 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.5 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PS256”o算法描述：使用SHA-256和MGF1的RSASSA-PSS与SHA-256 o算法使用位置：“alg”o实现要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.5节：不适用
o Algorithm Name: "PS384" o Algorithm Description: RSASSA-PSS using SHA-384 and MGF1 with SHA-384 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.5 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PS384”o算法描述：使用SHA-384和MGF1的RSASSA-PSS与SHA-384 o算法使用位置：“alg”o JOSE实施要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.5节：不适用
o Algorithm Name: "PS512" o Algorithm Description: RSASSA-PSS using SHA-512 and MGF1 with SHA-512 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.5 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PS512”o算法描述：使用SHA-512和MGF1的RSASSA-PSS与SHA-512 o算法使用位置：“alg”o实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.5节：不适用
o Algorithm Name: "none" o Algorithm Description: No digital signature or MAC performed o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.6 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“无”o算法描述：无数字签名或MAC执行o算法使用位置：“alg”o JOSE实施要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第3.6节：不适用
o Algorithm Name: "RSA1_5" o Algorithm Description: RSAES-PKCS1-v1_5 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended-o Change Controller: IESG o Specification Document(s): Section 4.2 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RSA1_5”o算法描述：RSAES-PKCS1-v1_5 o算法使用位置：“alg”o JOSE实施要求：推荐的-o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.2节：不适用
o Algorithm Name: "RSA-OAEP" o Algorithm Description: RSAES OAEP using default parameters o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended+ o Change Controller: IESG o Specification Document(s): Section 4.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RSA-OAEP”o算法描述：使用默认参数的RSAES OAEP o算法使用位置：“alg”o JOSE实施要求：推荐+o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.3节：不适用
o Algorithm Name: "RSA-OAEP-256" o Algorithm Description: RSAES OAEP using SHA-256 and MGF1 with SHA-256 o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“RSA-OAEP-256”o算法描述：RSAES OAEP使用SHA-256和MGF1与SHA-256 o算法使用位置：“alg”o实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.3节：不适用
o Algorithm Name: "A128KW" o Algorithm Description: AES Key Wrap using 128-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 4.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A128KW”o算法描述：使用128位密钥的AES密钥封装o算法使用位置：“alg”o JOSE实施要求：推荐o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.4节：不适用
o Algorithm Name: "A192KW" o Algorithm Description: AES Key Wrap using 192-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A192KW”o算法描述：使用192位密钥的AES密钥封装o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.4节：不适用
o Algorithm Name: "A256KW" o Algorithm Description: AES Key Wrap using 256-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 4.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A256KW”o算法描述：使用256位密钥的AES密钥封装o算法使用位置：“alg”o JOSE实施要求：推荐o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.4节：不适用
o Algorithm Name: "dir" o Algorithm Description: Direct use of a shared symmetric key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 4.5 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“dir”o算法说明：直接使用共享对称密钥o算法使用位置：“alg”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.5节：不适用
o Algorithm Name: "ECDH-ES" o Algorithm Description: ECDH-ES using Concat KDF o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended+ o Change Controller: IESG o Specification Document(s): Section 4.6 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ECDH-ES”o算法描述：ECDH-ES使用Concat KDF o算法使用位置：“alg”o JOSE实施要求：推荐+o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.6节：不适用
o Algorithm Name: "ECDH-ES+A128KW" o Algorithm Description: ECDH-ES using Concat KDF and "A128KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 4.6 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ECDH-ES+A128KW”o算法描述：ECDH-ES使用Concat KDF和“A128KW”包装o算法使用位置：“alg”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.6节：不适用
o Algorithm Name: "ECDH-ES+A192KW" o Algorithm Description: ECDH-ES using Concat KDF and "A192KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.6 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ECDH-ES+A192KW”o算法描述：ECDH-ES使用Concat KDF和“A192KW”包装o算法使用位置：“alg”o JOSE实施要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.6节：不适用
o Algorithm Name: "ECDH-ES+A256KW" o Algorithm Description: ECDH-ES using Concat KDF and "A256KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 4.6 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“ECDH-ES+A256KW”o算法描述：ECDH-ES使用Concat KDF和“A256KW”包装o算法使用位置：“alg”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.6节：不适用
o Algorithm Name: "A128GCMKW" o Algorithm Description: Key wrapping with AES GCM using 128-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.7 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A128GCMKW”o算法描述：使用AES GCM包装密钥使用128位密钥o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.7节：不适用
o Algorithm Name: "A192GCMKW" o Algorithm Description: Key wrapping with AES GCM using 192-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.7 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A192GCMKW”o算法描述：使用192位密钥的AES GCM密钥包装o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.7节：不适用
o Algorithm Name: "A256GCMKW" o Algorithm Description: Key wrapping with AES GCM using 256-bit key o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.7 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A256GCMKW”o算法描述：使用AES GCM包装密钥使用256位密钥o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.7节：不适用
o Algorithm Name: "PBES2-HS256+A128KW" o Algorithm Description: PBES2 with HMAC SHA-256 and "A128KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.8 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PBES2-HS256+A128KW”o算法描述：PBES2带HMAC SHA-256和“A128KW”包装o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.8节：不适用
o Algorithm Name: "PBES2-HS384+A192KW" o Algorithm Description: PBES2 with HMAC SHA-384 and "A192KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.8 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PBES2-HS384+A192KW”o算法描述：PBES2带HMAC SHA-384和“A192KW”包装o算法使用位置：“alg”o JOSE实施要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.8节：不适用
o Algorithm Name: "PBES2-HS512+A256KW" o Algorithm Description: PBES2 with HMAC SHA-512 and "A256KW" wrapping o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 4.8 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“PBES2-HS512+A256KW”o算法描述：PBES2带HMAC SHA-512和“A256KW”包装o算法使用位置：“alg”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第4.8节：不适用
o Algorithm Name: "A128CBC-HS256" o Algorithm Description: AES_128_CBC_HMAC_SHA_256 authenticated encryption algorithm o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Required o Change Controller: IESG o Specification Document(s): Section 5.2.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A128CBC-HS256”o算法描述：AES_128_CBC_HMAC_SHA_256经过身份验证的加密算法o算法使用位置：“enc”o JOSE实施要求：必需o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.2.3节：不适用
o Algorithm Name: "A192CBC-HS384" o Algorithm Description: AES_192_CBC_HMAC_SHA_384 authenticated encryption algorithm o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 5.2.4 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A192CBC-HS384”o算法描述：AES_192_CBC_HMAC_SHA_384认证加密算法o算法使用位置：“enc”o JOSE实施要求：可选o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.2.4节：不适用
o Algorithm Name: "A256CBC-HS512" o Algorithm Description: AES_256_CBC_HMAC_SHA_512 authenticated encryption algorithm o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Required o Change Controller: IESG o Specification Document(s): Section 5.2.5 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A256CBC-HS512”o算法描述：AES_256_CBC_HMAC_SHA_512经过身份验证的加密算法o算法使用位置：“enc”o JOSE实现要求：必需o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.2.5节：不适用
o Algorithm Name: "A128GCM" o Algorithm Description: AES GCM using 128-bit key o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 5.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A128GCM”o算法说明：AES GCM使用128位密钥o算法使用位置：“enc”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.3节：不适用
o Algorithm Name: "A192GCM" o Algorithm Description: AES GCM using 192-bit key o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 5.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A192GCM”o算法描述：AES GCM使用192位密钥o算法使用位置：“enc”o JOSE实现要求：可选o更改控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.3节：不适用
o Algorithm Name: "A256GCM" o Algorithm Description: AES GCM using 256-bit key o Algorithm Usage Location(s): "enc" o JOSE Implementation Requirements: Recommended o Change Controller: IESG o Specification Document(s): Section 5.3 of RFC 7518 o Algorithm Analysis Documents(s): n/a
o 算法名称：“A256GCM”o算法描述：AES GCM使用256位密钥o算法使用位置：“enc”o JOSE实施要求：推荐o变更控制器：IESG o规范文件：RFC 7518 o算法分析文件第5.3节：不适用
This section registers the Header Parameter names defined in Sections 4.6.1, 4.7.1, and 4.8.1 of this specification in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS].
本节将本规范第4.6.1节、第4.7.1节和第4.8.1节中定义的头参数名称注册到[JWS]建立的IANA“JSON Web签名和加密头参数”注册表中。
o Header Parameter Name: "epk" o Header Parameter Description: Ephemeral Public Key o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.6.1.1 of RFC 7518
o 标题参数名称：“epk”o标题参数说明：临时公钥o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.6.1.1节
o Header Parameter Name: "apu" o Header Parameter Description: Agreement PartyUInfo o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.6.1.2 of RFC 7518
o 标题参数名称：“apu”o标题参数说明：协议部分YUINFO标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.6.1.2节
o Header Parameter Name: "apv" o Header Parameter Description: Agreement PartyVInfo o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.6.1.3 of RFC 7518
o 标题参数名称：“apv”o标题参数说明：协议部分信息o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.6.1.3节
o Header Parameter Name: "iv" o Header Parameter Description: Initialization Vector o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.7.1.1 of RFC 7518
o 标题参数名称：“iv”o标题参数说明：初始化向量o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.7.1.1节
o Header Parameter Name: "tag" o Header Parameter Description: Authentication Tag o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.7.1.2 of RFC 7518
o 标题参数名称：“标记”o标题参数说明：身份验证标记o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.7.1.2节
o Header Parameter Name: "p2s" o Header Parameter Description: PBES2 Salt Input o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.8.1.1 of RFC 7518
o 标题参数名称：“p2s”o标题参数说明：PBES2盐输入o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.8.1.1节
o Header Parameter Name: "p2c" o Header Parameter Description: PBES2 Count o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.8.1.2 of RFC 7518
o 标题参数名称：“p2c”o标题参数说明：PBES2计数o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7518第4.8.1.2节
This specification establishes the IANA "JSON Web Encryption Compression Algorithms" registry for JWE "zip" member values. The registry records the compression algorithm value and a reference to the specification that defines it.
本规范为JWE“zip”成员值建立IANA“JSON Web加密压缩算法”注册表。注册表记录压缩算法值和对定义它的规范的引用。
Compression Algorithm Value: The name requested (e.g., "DEF"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
压缩算法值：请求的名称（例如，“DEF”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——如果没有令人信服的理由，名称不能超过8个字符。此名称区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Compression Algorithm Description: Brief description of the compression algorithm (e.g., "DEFLATE").
压缩算法说明：压缩算法的简要说明（例如，“DEFLATE”）。
Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
o Compression Algorithm Value: "DEF" o Compression Algorithm Description: DEFLATE o Change Controller: IESG o Specification Document(s): JSON Web Encryption (JWE) [JWE]
o 压缩算法值：“DEF”o压缩算法描述：DEFLATE o Change Controller:IESG o规范文档：JSON Web加密（JWE）[JWE]
This specification establishes the IANA "JSON Web Key Types" registry for values of the JWK "kty" (key type) parameter. The registry records the "kty" value, implementation requirements, and a reference to the specification that defines it.
本规范为JWK“kty”（键类型）参数的值建立IANA“JSON Web键类型”注册表。注册表记录“kty”值、实现要求以及对定义它的规范的引用。
The implementation requirements of a key type may be changed over time as the cryptographic landscape evolves, for instance, to change the status of a key type to Deprecated or to change the status of a key type from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.
密钥类型的实现要求可能随着时间的推移而改变，例如，将密钥类型的状态更改为不推荐，或将密钥类型的状态从可选更改为推荐+或必需。在指定专家审查后，仅允许在规范要求的基础上更改实施要求，新规范定义了修订后的实施要求级别。
"kty" Parameter Value: The name requested (e.g., "EC"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
“kty”参数值：请求的名称（例如，“EC”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——如果没有令人信服的理由，名称不能超过8个字符。此名称区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Key Type Description: Brief description of the Key Type (e.g., "Elliptic Curve").
密钥类型描述：密钥类型的简要描述（例如，“椭圆曲线”）。
Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
JOSE Implementation Requirements: The key type implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-". The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification.
JOSE实现需求：JWS和JWE的关键类型实现需求，必须是Required、Recommended、Optional、Deprecated或bankind。或者，单词后面可以跟一个“+”或“-”。使用“+”表示在规范的未来版本中，需求强度可能会增加。使用“-”表示在规范的未来版本中，需求强度可能会降低。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
This section registers the values defined in Section 6.1.
本节记录了第6.1节中定义的值。
o "kty" Parameter Value: "EC"
o Key Type Description: Elliptic Curve
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2 of RFC 7518
o "kty" Parameter Value: "EC"
o Key Type Description: Elliptic Curve
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2 of RFC 7518
o "kty" Parameter Value: "RSA"
o Key Type Description: RSA
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.3 of RFC 7518
o "kty" Parameter Value: "RSA"
o Key Type Description: RSA
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.3 of RFC 7518
o "kty" Parameter Value: "oct"
o Key Type Description: Octet Sequence
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.4 of RFC 7518
o "kty" Parameter Value: "oct"
o Key Type Description: Octet Sequence
o JOSE Implementation Requirements: Required
o Change Controller: IESG
o Specification Document(s): Section 6.4 of RFC 7518
This section registers the parameter names defined in Sections 6.2, 6.3, and 6.4 of this specification in the IANA "JSON Web Key Parameters" registry established by [JWK].
本节将本规范第6.2、6.3和6.4节中定义的参数名称注册到[JWK]建立的IANA“JSON Web键参数”注册表中。
o Parameter Name: "crv" o Parameter Description: Curve o Used with "kty" Value(s): "EC" o Parameter Information Class: Public o Change Controller: IESG o Specification Document(s): Section 6.2.1.1 of RFC 7518
o 参数名称：“crv”o参数说明：曲线o与“kty”值一起使用：“EC”o参数信息类别：公共o变更控制器：IESG o规范文件：RFC 7518第6.2.1.1节
o Parameter Name: "x" o Parameter Description: X Coordinate o Used with "kty" Value(s): "EC" o Parameter Information Class: Public o Change Controller: IESG o Specification Document(s): Section 6.2.1.2 of RFC 7518
o 参数名称：“x”o参数说明：x坐标o与“kty”值一起使用：“EC”o参数信息类别：公共o变更控制器：IESG o规范文件：RFC 7518第6.2.1.2节
o Parameter Name: "y" o Parameter Description: Y Coordinate o Used with "kty" Value(s): "EC" o Parameter Information Class: Public o Change Controller: IESG o Specification Document(s): Section 6.2.1.3 of RFC 7518
o 参数名称：“y”o参数说明：y坐标o与“kty”值一起使用：“EC”o参数信息类别：公共o变更控制器：IESG o规范文件：RFC 7518第6.2.1.3节
o Parameter Name: "d" o Parameter Description: ECC Private Key o Used with "kty" Value(s): "EC" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.2.2.1 of RFC 7518
o 参数名称：“d”o参数说明：ECC私钥o与“kty”值一起使用：“EC”o参数信息类别：私钥o变更控制器：IESG o规范文件：RFC 7518第6.2.2.1节
o Parameter Name: "n" o Parameter Description: Modulus o Used with "kty" Value(s): "RSA" o Parameter Information Class: Public o Change Controller: IESG o Specification Document(s): Section 6.3.1.1 of RFC 7518
o 参数名称：“n”o参数说明：模数o与“kty”值一起使用：“RSA”o参数信息类别：公共o变更控制器：IESG o规范文件：RFC 7518第6.3.1.1节
o Parameter Name: "e" o Parameter Description: Exponent o Used with "kty" Value(s): "RSA" o Parameter Information Class: Public o Change Controller: IESG o Specification Document(s): Section 6.3.1.2 of RFC 7518
o 参数名称：“e”o参数说明：指数o与“kty”值一起使用：“RSA”o参数信息类别：公共o变更控制器：IESG o规范文件：RFC 7518第6.3.1.2节
o Parameter Name: "d" o Parameter Description: Private Exponent o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.1 of RFC 7518
o 参数名称：“d”o参数说明：专用指数o与“kty”值一起使用：“RSA”o参数信息类别：专用o变更控制器：IESG o规范文件：RFC 7518第6.3.2.1节
o Parameter Name: "p" o Parameter Description: First Prime Factor o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.2 of RFC 7518
o 参数名称：“p”o参数说明：第一个素因子o与“kty”值一起使用：“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.2节
o Parameter Name: "q" o Parameter Description: Second Prime Factor o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.3 of RFC 7518
o 参数名称：“q”o参数说明：与“kty”值一起使用的第二个素数o:“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.3节
o Parameter Name: "dp" o Parameter Description: First Factor CRT Exponent o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.4 of RFC 7518
o 参数名称：“dp”o参数说明：与“kty”值一起使用的第一因子CRT指数o:“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.4节
o Parameter Name: "dq" o Parameter Description: Second Factor CRT Exponent o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.5 of RFC 7518
o 参数名称：“dq”o参数说明：与“kty”值一起使用的第二因子CRT指数o:“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.5节
o Parameter Name: "qi" o Parameter Description: First CRT Coefficient o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.6 of RFC 7518
o 参数名称：“qi”o参数说明：与“kty”值一起使用的第一个CRT系数o:“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.6节
o Parameter Name: "oth" o Parameter Description: Other Primes Info o Used with "kty" Value(s): "RSA" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.3.2.7 of RFC 7518
o 参数名称：“oth”o参数说明：与“kty”值一起使用的其他素数信息o:“RSA”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.3.2.7节
o Parameter Name: "k" o Parameter Description: Key Value o Used with "kty" Value(s): "oct" o Parameter Information Class: Private o Change Controller: IESG o Specification Document(s): Section 6.4.1 of RFC 7518
o 参数名称：“k”o参数说明：键值o与“kty”值一起使用：“oct”o参数信息类别：私有o变更控制器：IESG o规范文件：RFC 7518第6.4.1节
This section establishes the IANA "JSON Web Key Elliptic Curve" registry for JWK "crv" member values. The registry records the curve name, implementation requirements, and a reference to the specification that defines it. This specification registers the parameter names defined in Section 6.2.1.1.
本节为JWK“crv”成员值建立IANA“JSON Web密钥椭圆曲线”注册表。注册表记录曲线名称、实现要求以及对定义它的规范的引用。本规范登记了第6.2.1.1节中定义的参数名称。
The implementation requirements of a curve may be changed over time as the cryptographic landscape evolves, for instance, to change the status of a curve to Deprecated or to change the status of a curve from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.
随着加密环境的发展，曲线的实现要求可能会随着时间的推移而改变，例如，将曲线的状态更改为不推荐，或将曲线的状态从可选更改为推荐+或必需。在指定专家审查后，仅允许在规范要求的基础上更改实施要求，新规范定义了修订后的实施要求级别。
Curve Name: The name requested (e.g., "P-256"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
曲线名称：请求的名称（例如，“P-256”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——如果没有令人信服的理由，名称不能超过8个字符。此名称区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Curve Description: Brief description of the curve (e.g., "P-256 Curve").
曲线描述：曲线的简要描述（例如，“P-256曲线”）。
JOSE Implementation Requirements: The curve implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-".
JOSE实施要求：JWS和JWE的曲线实施要求，必须是Required、Recommended、Optional、Deprecated或bankind这些词中的一个。或者，单词后面可以跟一个“+”或“-”。
The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification.
使用“+”表示在规范的未来版本中，需求强度可能会增加。使用“-”表示在规范的未来版本中，需求强度可能会降低。
Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
o Curve Name: "P-256" o Curve Description: P-256 Curve o JOSE Implementation Requirements: Recommended+ o Change Controller: IESG o Specification Document(s): Section 6.2.1.1 of RFC 7518
o 曲线名称：“P-256”o曲线描述：P-256曲线o实施要求：推荐+o变更控制器：IESG o规范文件：RFC 7518第6.2.1.1节
o Curve Name: "P-384" o Curve Description: P-384 Curve o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 6.2.1.1 of RFC 7518
o 曲线名称：“P-384”o曲线描述：P-384曲线o实施要求：可选o变更控制器：IESG o规范文件：RFC 7518第6.2.1.1节
o Curve Name: "P-521" o Curve Description: P-521 Curve o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 6.2.1.1 of RFC 7518
o 曲线名称：“P-521”o曲线描述：P-521曲线o实施要求：可选o变更控制器：IESG o规范文件：RFC 7518第6.2.1.1节
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代理解决。这些问题包括保护用户的非对称私钥和对称密钥以及对各种攻击采取对策。
The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], [NIST.800-38D], [NIST.800-56A], [NIST.800-107], [RFC2104], [RFC3394], [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this specification.
[AES]、[DSS]、[JWE]、[JWK]、[JWS]、[NIST.800-38D]、[NIST.800-56A]、[NIST.800-107]、[RFC2104]、[RFC3394]、[RFC3447]、[RFC5116]、[RFC6090]和[SHS]中的安全注意事项适用于本规范。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. Therefore, implementers and deployments must be prepared for the set of algorithms that are supported and used to change over time. Thus, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted.
实现者应该意识到加密算法会随着时间的推移变得越来越弱。随着新密码分析技术的发展和计算性能的提高，破坏特定密码算法的工作因素将减少。因此，实施者和部署人员必须为所支持并用于随时间变化的算法集做好准备。因此，加密算法的实现应该是模块化的，允许随时插入新算法。
Many algorithms have associated security considerations related to key lifetimes and/or the number of times that a key may be used. Those security considerations continue to apply when using those algorithms with JOSE data structures. See NIST SP 800-57 [NIST.800-57] for specific guidance on key lifetimes.
Many algorithms have associated security considerations related to key lifetimes and/or the number of times that a key may be used. Those security considerations continue to apply when using those algorithms with JOSE data structures. See NIST SP 800-57 [NIST.800-57] for specific guidance on key lifetimes.translate error, please retry
While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1-v1_5 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1-v1_5, for interoperability reasons, because it is commonly implemented.
虽然RFC 3447[RFC3447]第8节明确要求人们不要在新应用中采用RSASSA-PKCS1-v1_5，而是要求人们过渡到RSASSA-PSS，但出于互操作性的原因，本规范确实包括RSASSA-PKCS1-v1_5，因为它通常是实现的。
Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Section 7.2 of RFC 3447. Also, keys with a low public key exponent value, as described in Section 3 of "Twenty Years of Attacks on the RSA Cryptosystem" [Boneh99], must not be used.
与RSAES-PKCS1-v1_5一起使用的钥匙必须遵循RFC 3447第7.2节中的约束条件。此外，不得使用具有低公钥指数值的密钥，如“RSA密码系统二十年攻击”[Boneh99]第3节所述。
Keys used with AES GCM must follow the constraints in Section 8.3 of [NIST.800-38D], which states: "The total number of invocations of the authenticated encryption function shall not exceed 2^32, including all IV lengths and all instances of the authenticated encryption function with the given key". In accordance with this rule, AES GCM MUST NOT be used with the same key value more than 2^32 times.
AES GCM使用的密钥必须遵循[NIST.800-38D]第8.3节中的约束，该节规定：“已验证加密功能的调用总数不得超过2^32，包括所有IV长度和具有给定密钥的已验证加密功能的所有实例”。根据该规则，AES GCM不得与同一键值一起使用超过2^32次。
An IV value MUST NOT ever be used multiple times with the same AES GCM key. One way to prevent this is to store a counter with the key and increment it with every use. The counter can also be used to prevent exceeding the 2^32 limit above.
同一AES GCM密钥不得多次使用IV值。防止这种情况的一种方法是使用键存储计数器，并在每次使用时递增它。计数器也可用于防止超过上述2^32限制。
This security consideration does not apply to the composite AES-CBC HMAC SHA-2 or AES Key Wrap algorithms.
这种安全考虑不适用于复合AES-CBC HMAC SHA-2或AES密钥包裹算法。
Unsecured JWSs (JWSs that use the "alg" value "none") provide no integrity protection. Thus, they must only be used in contexts in which the payload is secured by means other than a digital signature or MAC value, or they need not be secured.
不安全的JWSs（使用“alg”值“none”的JWSs）不提供完整性保护。因此，它们必须仅在有效负载通过数字签名或MAC值以外的方式进行安全保护的上下文中使用，或者不需要进行安全保护。
An example means of preventing accepting Unsecured JWSs by default is for the "verify" method of a hypothetical JWS software library to have a Boolean "acceptUnsecured" parameter that indicates "none" is an acceptable "alg" value. As another example, the "verify" method might take a list of algorithms that are acceptable to the application as a parameter and would reject Unsecured JWS values if "none" is not in that list.
默认情况下防止接受不安全JWS的一种示例方法是，假设JWS软件库的“verify”方法具有一个布尔“acceptUnsecured”参数，该参数指示“none”是一个可接受的“alg”值。作为另一个示例，“verify”方法可能将应用程序可接受的算法列表作为参数，如果该列表中没有“none”，则会拒绝不安全的JWS值。
The following example illustrates the reasons for not accepting Unsecured JWSs at a global level. Suppose an application accepts JWSs over two channels, (1) HTTP and (2) HTTPS with client authentication. It requires a JWS Signature on objects received over HTTP, but accepts Unsecured JWSs over HTTPS. If the application were to globally indicate that "none" is acceptable, then an attacker could provide it with an Unsecured JWS over HTTP and still have that object successfully validate. Instead, the application needs to indicate acceptance of "none" for each object received over HTTPS (e.g., by setting "acceptUnsecured" to "true" for the first hypothetical JWS software library above), but not for each object received over HTTP.
下面的示例说明了不在全局级别接受不安全JWS的原因。假设应用程序通过两个通道接受JWSs，（1）HTTP和（2）带有客户端身份验证的HTTPS。它需要对通过HTTP接收的对象进行JWS签名，但接受通过HTTPS的不安全JWS。如果应用程序全局指示“无”是可接受的，那么攻击者可以通过HTTP向其提供不安全的JWS，并且仍然可以成功验证该对象。相反，应用程序需要为通过HTTPS接收的每个对象指示接受“none”（例如，通过为上面第一个假设的JWS软件库将“acceptUnsecured”设置为“true”），但不是为通过HTTP接收的每个对象。
Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could supply content using keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification. Implementations should set and enforce upper limits on the key sizes they accept. Section 5.6.1 (Comparable Algorithm Strengths) of NIST SP 800-57 [NIST.800-57] contains statements on largest approved key sizes that may be applicable.
验证签名的接收代理和加密消息的发送代理在使用大于本规范规定的密钥验证签名和加密消息时，需要谨慎使用加密处理。攻击者可以使用会导致过度加密处理的密钥提供内容，例如，比本规范中规定的密钥大的密钥。实现应该设置并强制执行它们接受的密钥大小上限。NIST SP 800-57[NIST.800-57]第5.6.1节（可比算法强度）包含了关于可能适用的最大批准密钥大小的声明。
It is NOT RECOMMENDED to reuse the same entire set of key material (Key Encryption Key, Content Encryption Key, Initialization Vector, etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK Set object multiple times. One suggestion for
不建议重复使用同一整套密钥材料（密钥加密密钥、内容加密密钥、初始化向量等）来加密多个JWK或JWK集对象，或多次加密同一个JWK或JWK集对象。一个建议
preventing reuse is to always generate at least one new piece of key material for each encryption operation (e.g., a new Content Encryption Key, a new IV, and/or a new PBES2 Salt), based on the considerations noted in this document as well as from RFC 4086 [RFC4086].
防止重复使用是基于本文件以及RFC 4086[RFC4086]中提到的注意事项，始终为每个加密操作生成至少一个新的密钥材料（例如，新的内容加密密钥、新的IV和/或新的PBES2 Salt）。
Passwords are vulnerable to a number of attacks. To help mitigate some of these limitations, this document applies principles from RFC 2898 [RFC2898] to derive cryptographic keys from user-supplied passwords.
密码容易受到多种攻击。为了帮助缓解其中一些限制，本文档应用RFC 2898[RFC2898]中的原则，从用户提供的密码中导出加密密钥。
However, the strength of the password still has a significant impact. A high-entropy password has greater resistance to dictionary attacks. [NIST.800-63-2] contains guidelines for estimating password entropy, which can help applications and users generate stronger passwords.
但是，密码的强度仍然有很大的影响。高熵密码对字典攻击具有更强的抵抗力。[NIST.800-63-2]包含估算密码熵的指南，可帮助应用程序和用户生成更强的密码。
An ideal password is one that is as large as (or larger than) the derived key length. However, passwords larger than a certain algorithm-specific size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm. It is RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no shorter than 16 octets and no longer than 128 octets and a password used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no longer than 128 octets long.
理想的密码是与派生密钥长度相同（或大于）的密码。但是，首先对大于特定算法大小的密码进行散列，这会将攻击者的有效搜索空间减少到散列算法的长度。建议用于“PBES2-HS256+A128KW”的密码不小于16个八位字节，不大于128个八位字节；用于“PBES2-HS512+A256KW”的密码不小于32个八位字节，不大于128个八位字节。
Still, care needs to be taken in where and how password-based encryption is used. These algorithms can still be susceptible to dictionary-based attacks if the iteration count is too small; this is of particular concern if these algorithms are used to protect data that an attacker can have indefinite number of attempts to circumvent the protection, such as protected data stored on a file system.
尽管如此，在哪里以及如何使用基于密码的加密仍然需要谨慎。如果迭代次数太少，这些算法仍然容易受到基于字典的攻击；如果这些算法用于保护攻击者可能多次试图绕过保护的数据，例如存储在文件系统上的受保护数据，则这一点尤其值得关注。
See Section 10.1 of [JWS] for security considerations on key entropy and random values.
有关密钥熵和随机值的安全注意事项，请参见[JWS]第10.1节。
See Section 10.5 of [JWS] for security considerations on differences between digital signatures and MACs.
有关数字签名和MAC之间差异的安全注意事项，请参见[JWS]第10.5节。
See Section 11.3 of [JWE] for security considerations on using matching algorithm strengths.
有关使用匹配算法优势的安全注意事项，请参见[JWE]第11.3节。
See Section 11.4 of [JWE] for security considerations on adaptive chosen-ciphertext attacks.
关于自适应选择密文攻击的安全注意事项，请参见[JWE]第11.4节。
See Section 10.9 of [JWS] and Section 11.5 of [JWE] for security considerations on timing attacks.
有关定时攻击的安全注意事项，请参见[JWS]第10.9节和[JWE]第11.5节。
See Section 9.3 of [JWK] for security considerations on RSA private key representations and blinding.
请参见[JWK]第9.3节，了解RSA私钥表示和盲取的安全注意事项。
Passwords obtained from users are likely to require preparation and normalization to account for differences of octet sequences generated by different input devices, locales, etc. It is RECOMMENDED that applications perform the steps outlined in [PRECIS] to prepare a password supplied directly by a user before performing key derivation and encryption.
从用户处获得的密码可能需要准备和规范化，以说明不同输入设备、地区等产生的八位字节序列的差异。建议应用程序执行[PRECIS]中概述的步骤在执行密钥派生和加密之前，准备用户直接提供的密码。
[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>。
[Boneh99] "Twenty Years of Attacks on the RSA Cryptosystem", Notices of the American Mathematical Society (AMS), Vol. 46, No. 2, pp. 203-213, 1999, <http://crypto.stanford.edu/ ~dabo/pubs/papers/RSA-survey.pdf>.
[Boneh99]“对RSA密码系统的二十年攻击”，《美国数学学会公告》，第46卷，第2期，第203-213页，1999年<http://crypto.stanford.edu/ ~dabo/pubs/papers/RSA survey.pdf>。
[DSS] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[DSS]国家标准与技术研究所（NIST），“数字签名标准（DSS）”，FIPS PUB 186-42013年7月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<http://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[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>.
[NIST.800-38A] National Institute of Standards and Technology (NIST), "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, December 2001, <http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>.
[NIST.800-38A]国家标准与技术研究所（NIST），“分组密码操作模式建议”，NIST特别出版物800-38A，2001年12月<http://csrc.nist.gov/publications/nistpubs/800-38a/ sp800-38a.pdf>。
[NIST.800-38D] National Institute of Standards and Technology (NIST), "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, December 2001, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.
[NIST.800-38D]国家标准与技术研究所（NIST），“分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，NIST特别出版物800-38D，2001年12月<http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>。
[NIST.800-56A] National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 2, May 2013, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>.
[NIST.800-56A]美国国家标准与技术研究所（NIST），“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，第2版，2013年5月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>。
[NIST.800-57] National Institute of Standards and Technology (NIST), "Recommendation for Key Management - Part 1: General (Revision 3)", NIST Special Publication 800-57, Part 1, Revision 3, July 2012, <http://csrc.nist.gov/publications/ nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
[NIST.800-57]国家标准与技术研究所（NIST），“关键管理建议-第1部分：总则（第3版）”，NIST特别出版物800-57，第1部分，第3版，2012年7月<http://csrc.nist.gov/publications/ nistpubs/800-57/sp800-57\u part1\u rev3\u general.pdf>。
[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>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 2898，DOI 10.17487/RFC2898，2000年9月<http://www.rfc-editor.org/info/rfc2898>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，DOI 10.17487/RFC3394，2002年9月<http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[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>.
[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>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，DOI 10.17487/RFC4868，2007年5月<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 6090，DOI 10.17487/RFC6090，2011年2月<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1]高效加密标准组，“第1节：椭圆曲线加密”，版本2.0，2009年5月<http://www.secg.org/sec1-v2.pdf>.
[SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[SHS]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS PUB 180-42012年3月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[AEAD-CBC-SHA] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", Work in Progress, draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[AEAD-CBC-SHA]McGrew，D.，Foley，J.，和K.Paterson，“AES-CBC和HMAC-SHA的认证加密”，正在进行的工作，草稿-McGrew-AEAD-AES-CBC-HMAC-sha2-052014年7月。
[CanvasApp] Facebook, "Canvas Applications", 2010, <http://developers.facebook.com/docs/authentication/ canvas>.
[CanvasApp]Facebook，“Canvas应用程序”，2010年<http://developers.facebook.com/docs/authentication/ 画布>。
[JCA] Oracle, "Java Cryptography Architecture (JCA) Reference Guide", 2014, <http://docs.oracle.com/javase/8/docs/techno tes/guides/security/crypto/CryptoSpec.html>.
[JCA]Oracle，“Java加密体系结构（JCA）参考指南”，2014年<http://docs.oracle.com/javase/8/docs/techno tes/guides/security/crypto/CryptoSpec.html>。
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple Encryption", September 2010, <http://jsonenc.info/enc/1.0/>.
[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月。
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign 1.0", Draft 01, September 2010, <http://jsonenc.info/jss/1.0/>.
[JSS]Bradley，J.和N.Sakimura编辑，“JSON简单符号1.0”，草案01，2010年9月<http://jsonenc.info/jss/1.0/>.
[JWE-JWK] Miller, M., "Using JavaScript Object Notation (JSON) Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects", Work in Progress, draft-miller-jose-jwe-protected-jwk-02, June 2013.
[JWE-JWK]Miller，M.，“使用JavaScript对象表示法（JSON）Web加密（JWE）保护JSON Web密钥（JWK）对象”，正在进行的工作，draft-Miller-jose-JWE-protected-JWK-022013年6月。
[MagicSignatures] Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic Signatures", January 2011, <http://salmon-protocol.googlecode.com/svn/trunk/ draft-panzer-magicsig-01.html>.
[MagicSignatures]Panzer，J.，Ed.，Laurie，B.，和D.Balfanz，“魔法签名”，2011年1月<http://salmon-protocol.googlecode.com/svn/trunk/ draft-panzer-magicsig-01.html>。
[NIST.800-107] National Institute of Standards and Technology (NIST), "Recommendation for Applications Using Approved Hash Algorithms", NIST Special Publication 800-107, Revision 1, August 2012, <http://csrc.nist.gov/publications/ nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-107]国家标准与技术研究所（NIST），“使用经批准哈希算法的应用建议”，NIST特别出版物800-107，第1版，2012年8月<http://csrc.nist.gov/publications/ nistpubs/800-107-rev1/sp800-107-rev1.pdf>。
[NIST.800-63-2] National Institute of Standards and Technology (NIST), "Electronic Authentication Guideline", NIST Special Publication 800-63-2, August 2013, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-63-2.pdf>.
[NIST.800-63-2]国家标准与技术研究所（NIST），“电子认证指南”，NIST特别出版物800-63-2，2013年8月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-63-2.pdf>。
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", Work in Progress, draft-ietf-precis-saslprepbis-16, April 2015.
[PRECIS]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，正在进行的工作，草稿-ietf-PRECIS-saslprepbis-16，2015年4月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <http://www.rfc-editor.org/info/rfc2631>.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 2631，DOI 10.17487/RFC26311999年6月<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, DOI 10.17487/RFC3275, March 2002, <http://www.rfc-editor.org/info/rfc3275>.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 3275，DOI 10.17487/RFC3275，2002年3月<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[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>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[W3C.NOTE-xmldsig-core2-20130411] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, T., Yiu, K., Datta, P., and S. Cantor, "XML Signature Syntax and Processing Version 2.0", World Wide Web Consortium Note NOTE-xmldsig-core2-20130411, April 2013, <http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.NOTE-xmldsig-core2-20130411]伊斯特莱克，D.，雷格尔，J.，索洛，D.，赫希，F.，罗斯勒，T.，姚，K.，达塔，P.，和S.坎托，“XML签名语法和处理版本2.0”，万维网联盟NOTE-xmldsig-core2-20130411，2013年4月<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210] Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", World Wide Web Consortium Recommendation REC-xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[W3C.REC-xmlenc-core-20021210]Eastlake，D.和J.Reagle，“XML加密语法和处理”，万维网联盟建议REC-xmlenc-core-20021210，2002年12月<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[W3C.REC-xmlenc-core1-20130411] Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium Recommendation REC-xmlenc-core1-20130411, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
[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 appendix contains tables cross-referencing the cryptographic
algorithm identifier values defined in this specification with the
equivalent identifiers used by other standards and software packages.
See XML DSIG [RFC3275], XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411], XML Encryption
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.REC-xmlenc-core1-20130411], and Java Cryptography Architecture
[JCA] for more information about the names defined by those
documents.
This appendix contains tables cross-referencing the cryptographic
algorithm identifier values defined in this specification with the
equivalent identifiers used by other standards and software packages.
See XML DSIG [RFC3275], XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411], XML Encryption
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.REC-xmlenc-core1-20130411], and Java Cryptography Architecture
[JCA] for more information about the names defined by those
documents.
This section contains a table cross-referencing the JWS digital signature and MAC "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
本节包含一个表格，该表格交叉引用了本规范中定义的JWS数字签名和MAC“alg”（算法）值，以及其他标准和软件包使用的等效标识符。
+-------------------------------------------------------------------+
| JWS | XML DSIG |
| | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 |
| | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 |
| | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 |
| | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 |
| | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 |
| | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 |
| | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 |
| | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 |
| | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 |
| | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 |
| | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 |
| | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| JWS | XML DSIG |
| | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 |
| | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 |
| | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 |
| | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 |
| | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 |
| | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 |
| | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 |
| | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 |
| | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 |
| | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 |
| | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 |
| | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
This section contains a table cross-referencing the JWE "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
本节包含一个交叉引用本规范中定义的JWE“alg”（算法）值与其他标准和软件包使用的等效标识符的表格。
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| RSA1_5 | http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
| | RSA/ECB/PKCS1Padding | 1.2.840.113549.1.1.1 |
+-------------------------------------------------------------------+
| RSA-OAEP | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
| | RSA/ECB/OAEPWithSHA-1AndMGF1Padding | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| RSA-OAEP-256 | http://www.w3.org/2009/xmlenc11#rsa-oaep |
| | & http://www.w3.org/2009/xmlenc11#mgf1sha256 |
| | RSA/ECB/OAEPWithSHA-256AndMGF1Padding | |
| | & MGF1ParameterSpec.SHA256 | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| ECDH-ES | http://www.w3.org/2009/xmlenc11#ECDH-ES |
| | ECDH | 1.3.132.1.12 |
+-------------------------------------------------------------------+
| A128KW | http://www.w3.org/2001/04/xmlenc#kw-aes128 |
| | AESWrap | 2.16.840.1.101.3.4.1.5 |
+-------------------------------------------------------------------+
| A192KW | http://www.w3.org/2001/04/xmlenc#kw-aes192 |
| | AESWrap | 2.16.840.1.101.3.4.1.25 |
+-------------------------------------------------------------------+
| A256KW | http://www.w3.org/2001/04/xmlenc#kw-aes256 |
| | AESWrap | 2.16.840.1.101.3.4.1.45 |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| RSA1_5 | http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
| | RSA/ECB/PKCS1Padding | 1.2.840.113549.1.1.1 |
+-------------------------------------------------------------------+
| RSA-OAEP | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
| | RSA/ECB/OAEPWithSHA-1AndMGF1Padding | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| RSA-OAEP-256 | http://www.w3.org/2009/xmlenc11#rsa-oaep |
| | & http://www.w3.org/2009/xmlenc11#mgf1sha256 |
| | RSA/ECB/OAEPWithSHA-256AndMGF1Padding | |
| | & MGF1ParameterSpec.SHA256 | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| ECDH-ES | http://www.w3.org/2009/xmlenc11#ECDH-ES |
| | ECDH | 1.3.132.1.12 |
+-------------------------------------------------------------------+
| A128KW | http://www.w3.org/2001/04/xmlenc#kw-aes128 |
| | AESWrap | 2.16.840.1.101.3.4.1.5 |
+-------------------------------------------------------------------+
| A192KW | http://www.w3.org/2001/04/xmlenc#kw-aes192 |
| | AESWrap | 2.16.840.1.101.3.4.1.25 |
+-------------------------------------------------------------------+
| A256KW | http://www.w3.org/2001/04/xmlenc#kw-aes256 |
| | AESWrap | 2.16.840.1.101.3.4.1.45 |
+-------------------------------------------------------------------+
This section contains a table cross-referencing the JWE "enc" (encryption algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
本节包含一个交叉引用本规范中定义的JWE“enc”（加密算法）值与其他标准和软件包使用的等效标识符的表格。
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and "A256CBC-HS512", the corresponding AES-CBC algorithm identifiers are listed.
对于复合算法“A128CBC-HS256”、“A192CBC-HS384”和“A256CBC-HS512”，列出了相应的AES-CBC算法标识符。
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| A128CBC-HS256 | http://www.w3.org/2001/04/xmlenc#aes128-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.2 |
+-------------------------------------------------------------------+
| A192CBC-HS384 | http://www.w3.org/2001/04/xmlenc#aes192-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.22 |
+-------------------------------------------------------------------+
| A256CBC-HS512 | http://www.w3.org/2001/04/xmlenc#aes256-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.42 |
+-------------------------------------------------------------------+
| A128GCM | http://www.w3.org/2009/xmlenc11#aes128-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.6 |
+-------------------------------------------------------------------+
| A192GCM | http://www.w3.org/2009/xmlenc11#aes192-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.26 |
+-------------------------------------------------------------------+
| A256GCM | http://www.w3.org/2009/xmlenc11#aes256-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.46 |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| A128CBC-HS256 | http://www.w3.org/2001/04/xmlenc#aes128-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.2 |
+-------------------------------------------------------------------+
| A192CBC-HS384 | http://www.w3.org/2001/04/xmlenc#aes192-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.22 |
+-------------------------------------------------------------------+
| A256CBC-HS512 | http://www.w3.org/2001/04/xmlenc#aes256-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.42 |
+-------------------------------------------------------------------+
| A128GCM | http://www.w3.org/2009/xmlenc11#aes128-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.6 |
+-------------------------------------------------------------------+
| A192GCM | http://www.w3.org/2009/xmlenc11#aes192-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.26 |
+-------------------------------------------------------------------+
| A256GCM | http://www.w3.org/2009/xmlenc11#aes256-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.46 |
+-------------------------------------------------------------------+
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
附录B.AES_CBC_HMAC_SHA2算法的测试用例
The following test cases can be used to validate implementations of the AES_CBC_HMAC_SHA2 algorithms defined in Section 5.2. They are also intended to correspond to test cases that may appear in a future version of [AEAD-CBC-SHA], demonstrating that the cryptographic computations performed are the same.
以下测试用例可用于验证第5.2节中定义的AES_CBC_HMAC_SHA2算法的实现。它们还旨在与[AEAD-CBC-SHA]未来版本中可能出现的测试用例相对应，证明执行的加密计算是相同的。
The variable names are those defined in Section 5.2. All values are hexadecimal.
变量名称为第5.2节中定义的名称。所有值都是十六进制的。
AES_128_CBC_HMAC_SHA_256
AES_128_CBC_HMAC_SHA_256
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
K=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 15 17 19 1a 1b 1d 1d 1d 1f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
MAC_密钥=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY=1011121315151718191B1B1B1C1D1B1B11E1F1F1F
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
P=41206369706572207377374656d2076d7574206e74206265207265717569726520746f20626573637265742c20616e64206974207620626206d75742062656206c20746f2066616c206946e74207465206868616e642076f6620746865206565656e7676f792076767676f66207676767676792076767676767676f70767676767676f707676767676767676767676f707676767676767676767676767676767676767676767676767676767669 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
IV=1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 4b 65 72 63 6b 68 6f 66 66 73
A=546865207363636F6E6420707269696E6369706C665206F662041756775737465204B6572636B686F66673
AL = 00 00 00 00 00 00 01 50
AL = 00 00 00 00 00 00 01 50
E = c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
E=c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79 a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9 a9 a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 36 09 d4 5a c6 98 64 e3 32 1c f8 35 ac 40 96 c8 6e 13 14 c5 40 19 e8 ca 79 b9 cf 38 4c 48 6a 54 c5 10 78 e5 f8 d8 d8 d8 d8 d8 d8 b9 b948 b3 d6 95 50 a6 76 46 34 44 27 ad e5 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
M = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 e6 e5 45 82 47 65 15 f0 ad 9f 75 a2 b7 1c 73 ef
M=65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 e6 e5 45 82 47 65 15 f0 ad 9f 75 a2 b7 1c 73 ef
T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
T=65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
K=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 15 17 19 1a 1b 1c 1d 1f 20 21 22 24 25 26 27 29 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17
MAC_KEY=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 14 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
ENC_KEY=18 19 1a 1b 1c 1d 1e 1f 20 21 22 24 25 26 27 28 29 2b 2c 2d 2e 2f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
P=41206369706572207377374656d2076d7574206e74206265207265717569726520746f20626573637265742c20616e64206974207620626206d75742062656206c20746f2066616c206946e74207465206868616e642076f6620746865206565656e7676f792076767676f66207676767676792076767676767676f70767676767676f707676767676767676767676f707676767676767676767676767676767676767676767676767676767669 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
IV=1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 4b 65 72 63 6b 68 6f 66 66 73
A=546865207363636F6E6420707269696E6369706C665206F662041756775737465204B6572636B686F66673
AL = 00 00 00 00 00 00 01 50
AL = 00 00 00 00 00 00 01 50
E = ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
E=ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5 d3 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db 00 D 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6 57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b ed 78 7a 0f fc bf 39 04 be 64 1d 5c 21 05 bf e2 74 e5 32 49 A 6c 3b6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 F280 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
M = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 75 16 80 39 cc c7 33 d7 45 94 f8 86 b3 fa af d4 86 f2 5c 71 31 e3 28 1e 36 c7 a2 d1 30 af de 57
M=84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 75 16 80 39 cc c7 33 d7 45 94 f8 86 b3 fa af d4 86 f2 5c 71 31 e3 28 1e 36 c7 a2 d1 30 af de 57
T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 75 16 80 39 cc c7 33 d7
T=84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 75 16 80 39 cc c7 33 d7
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
K=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0e 0f 10 11 12 13 15 17 19 1a 1b 1d 1f 20 21 22 24 25 26 28 29 2b 2c 2d 2f 30 31 32 34 36 38 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
MAC_密钥=00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 16 17 19 1a 1b 1c 1d 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
ENC_KEY=20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 36 37 38 3a 3b 3c 3d 3e 3f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
P=41206369706572207377374656d2076d7574206e74206265207265717569726520746f20626573637265742c20616e64206974207620626206d75742062656206c20746f2066616c206946e74207465206868616e642076f6620746865206565656e7676f792076767676f66207676767676792076767676767676f70767676767676f707676767676767676767676f707676767676767676767676767676767676767676767676767676767669 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
IV=1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63 69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20 4b 65 72 63 6b 68 6f 66 66 73
A=546865207363636F6E6420707269696E6369706C665206F662041756775737465204B6572636B686F66673
AL = 00 00 00 00 00 00 01 50
AL = 00 00 00 00 00 00 01 50
E = 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
E=4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd 3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 c2 e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2 08 46 a1 09 cc f5 0d c8 fe cb ad 28 c7 3f 09 b3 a3 b7 5e 66 25 94 e4 b2 e6 60 9e 312c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b是26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
M = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07 53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c
M=4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07 53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c
T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
T=4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
This example uses ECDH-ES Key Agreement and the Concat KDF to derive the CEK in the manner described in Section 4.6. In this example, the ECDH-ES Direct Key Agreement mode ("alg" value "ECDH-ES") is used to produce an agreed-upon key for AES GCM with a 128-bit key ("enc" value "A128GCM").
本示例使用ECDH-ES密钥协议和Concat KDF，以第4.6节所述的方式推导CEK。在此示例中，ECDH-ES直接密钥协商模式（“alg”值“ECDH-ES”）用于为具有128位密钥的AES GCM生成约定密钥（“enc”值“A128GCM”）。
In this example, a producer Alice is encrypting content to a consumer Bob. The producer (Alice) generates an ephemeral key for the key agreement computation. Alice's ephemeral key (in JWK format) used for the key agreement computation in this example (including the private part) is:
在本例中，生产者Alice正在向消费者Bob加密内容。生产者（Alice）为密钥协商计算生成临时密钥。本例中用于密钥协议计算的Alice的临时密钥（JWK格式）为：
{"kty":"EC", "crv":"P-256", "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps", "d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo" }
{“kty”：“EC”，“crv”：“P-256”，“x”：“GI0GAILBDU7T53AKRMYGCSF3N5DO7MMWNBHKW5SV0”，“y”：“SLW_xSffzlpwrehevi30DHM_4EgVwt3NQQEUD7NMFPS”，“d”：“0_nxarpumqoajT50GZ8Yitr8Grtr8Grtr8Grtwyeacumd-MToTmIo”}
The consumer's (Bob's) key (in JWK format) used for the key agreement computation in this example (including the private part) is:
本例中用于密钥协议计算的消费者（Bob）密钥（JWK格式）为：
{"kty":"EC", "crv":"P-256", "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ", "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck", "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw" }
{“kty”：“EC”、“crv”：“P-256”、“x”：“Wenjy2hsccsm6aeddg04biovhywvohqfef_PxMQ”、“y”：“e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck”、“d”：“VEMDZPDXXK8P8N0CndSXS924Q6NS1RxFASL6BFUQDW”}
Header Parameter values used in this example are as follows. The "apu" (agreement PartyUInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Alice" and the "apv" (agreement PartyVInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Bob". The "epk" (ephemeral public key) Header Parameter is used to communicate the producer's (Alice's) ephemeral public key value to the consumer (Bob).
本例中使用的标题参数值如下所示。“apu”（agreement PartyInfo）头参数值是UTF-8字符串“Alice”的base64url编码，“apv”（agreement PartyInfo）头参数值是UTF-8字符串“Bob”的base64url编码。“epk”（临时公钥）头参数用于将生产者（Alice）的临时公钥值传递给使用者（Bob）。
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
The resulting Concat KDF [NIST.800-56A] parameter values are:
产生的Concat KDF[NIST.800-56A]参数值为：
Z This is set to the ECDH-ES key agreement output. (This value is often not directly exposed by libraries, due to NIST security requirements, and only serves as an input to a KDF.) In this example, Z is following the octet sequence (using JSON array notation): [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196].
Z这设置为ECDH-ES密钥协议输出。（由于NIST的安全要求，该值通常不会被库直接公开，并且仅作为KDF的输入。）在本例中，Z遵循八位字节序列（使用JSON数组表示法）：[158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196].
keydatalen This value is 128 - the number of bits in the desired output key (because "A128GCM" uses a 128-bit key).
keydatalen此值为128—所需输出密钥中的位数（因为“A128GCM”使用128位密钥）。
AlgorithmID This is set to the octets representing the 32-bit big-endian value 7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content "A128GCM", followed, by the octets representing the ASCII string "A128GCM" - [65, 49, 50, 56, 71, 67, 77].
AlgorithmID设置为表示32位大端值7-[0,0,0,7]——算法ID内容“A128GCM”中的八位字节数，然后是表示ASCII字符串“A128GCM”——[65,49,50,56,71,67,77]的八位字节。
PartyUInfo This is set to the octets representing the 32-bit big-endian value 5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content "Alice", followed, by the octets representing the UTF-8 string "Alice" - [65, 108, 105, 99, 101].
PartyUInfo设置为表示32位大端值的八位字节5-[0,0,0,5]——PartyUInfo内容“Alice”中的八位字节数，然后是表示UTF-8字符串“Alice”[65,108,105,99,101]的八位字节。
PartyVInfo This is set to the octets representing the 32-bit big-endian value 3 - [0, 0, 0, 3] - the number of octets in the PartyUInfo content "Bob", followed, by the octets representing the UTF-8 string "Bob" - [66, 111, 98].
PartyVInfo设置为表示32位大端值的八位字节3-[0,0,0,3]——PARTYUIINFO内容“Bob”中的八位字节数，然后是表示UTF-8字符串“Bob”的八位字节“-[66,111,98]。
SuppPubInfo This is set to the octets representing the 32-bit big-endian value 128 - [0, 0, 0, 128] - the keydatalen value.
SuppPubInfo将其设置为表示32位big-endian值128-[0,0,0,128]-keydatalen值的八位字节。
SuppPrivInfo This is set to the empty octet sequence.
SuppPrivInfo将其设置为空八位字节序列。
Concatenating the parameters AlgorithmID through SuppPubInfo results in an OtherInfo value of: [0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
通过SuppPubInfo连接参数AlgorithmID将导致OtherInfo值：[0,0,0,7,65,49,50,56,71,67,77,0,0,0,5,65,108,105,99,101,0,0,0,3,66,111,98,0,0,0,0,128]
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo value results in the Concat KDF round 1 hash input of: [0, 0, 0, 1, 158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196, 0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
将整数1（[0,0,0,1]）、Z和OtherInfo值串联在一起，将导致Concat KDF第1轮哈希输入：[0, 0, 0, 1, 158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196, 0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
The resulting derived key, which is the first 128 bits of the round 1 hash output is: [86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16, 26]
得到的派生密钥是第1轮散列输出的前128位：[86、170、141、234、248、35、109、32、92、34、40、205、113、167、16、26]
The base64url-encoded representation of this derived key is:
此派生密钥的base64url编码表示形式为：
VqqN6vgjbSBcIijNcacQGg
VQQN6VGJBBCIIJNCACQGG
Acknowledgements
致谢
Solutions for signing and encrypting JSON content were previously explored by "Magic Signatures" [MagicSignatures], "JSON Simple Sign 1.0" [JSS], "Canvas Applications" [CanvasApp], "JSON Simple Encryption" [JSE], and "JavaScript Message Security Format" [JSMS], all of which influenced this document.
签名和加密JSON内容的解决方案之前由“Magic Signatures”[MagicSignatures]、“JSON Simple Sign 1.0”[JSS]、“CanvasApp]、“JSON Simple Encryption”[JSE]和“JavaScript消息安全格式”[JSMS]进行了探索，所有这些都影响了本文档。
The "Authenticated Encryption with AES-CBC and HMAC-SHA" [AEAD-CBC-SHA] specification, upon which the AES_CBC_HMAC_SHA2 algorithms are based, was written by David A. McGrew and Kenny Paterson. The test cases for AES_CBC_HMAC_SHA2 are based upon those for [AEAD-CBC-SHA] by John Foley.
“使用AES-CBC和HMAC-SHA进行认证加密”[AEAD-CBC-SHA]规范是AES_CBC_HMAC_SHA2算法的基础，由David A.McGrew和Kenny Paterson编写。AES_CBC_HMAC_SHA2的测试用例基于John Foley的[AEAD-CBC-SHA]测试用例。
Matt Miller wrote "Using JavaScript Object Notation (JSON) Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects" [JWE-JWK], upon which the password-based encryption content of this document is based.
Matt Miller写道“使用JavaScript对象表示法（JSON）Web加密（JWE）保护JSON Web密钥（JWK）对象”[JWE-JWK]，本文档基于密码的加密内容就是基于此。
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工作组的工作，该工作组包括数十名积极和专注的参与者。特别是，以下个人提供了影响本规范的想法、反馈和措辞：
Dirk Balfanz, Richard Barnes, Carsten Bormann, John Bradley, Brian Campbell, Alissa Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni Even, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
德克·巴尔芬兹、理查德·巴恩斯、卡斯滕·鲍曼、约翰·布拉德利、布赖恩·坎贝尔、艾莉莎·库珀、布伦诺·德梅德罗斯、弗拉基米尔·朱维诺夫、罗尼·埃文、斯蒂芬·法雷尔、雅伦·戈兰、迪克·哈特、乔·希尔德布兰德、杰夫·霍奇斯、埃德蒙·杰伊、查理·考夫曼、巴里·莱巴、詹姆斯·曼格、马特·米勒、凯瑟琳·莫里亚蒂、托尼·纳达林、阿克塞尔·内克尔、约翰·潘泽、，艾曼纽尔·拉维特、埃里克·雷斯科拉、皮特·雷斯尼克、纳特·樱村、吉姆·沙德、汉内斯·茨霍芬尼和肖恩·特纳。
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
Jim Schaad和Karen O'Donoghue担任JOSE工作组主席，Sean Turner、Stephen Farrell和Kathleen Moriarty在创建本规范期间担任安全区域主管。
Author's Address
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/