draft-ietf-jose-json-web-algorithms-17.txt   draft-ietf-jose-json-web-algorithms-18.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track October 7, 2013 Intended status: Standards Track November 12, 2013
Expires: April 10, 2014 Expires: May 16, 2014
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-17 draft-ietf-jose-json-web-algorithms-18
Abstract Abstract
The JSON Web Algorithms (JWA) specification registers cryptographic The JSON Web Algorithms (JWA) specification registers cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. It defines several IANA registries for these specifications. It defines several IANA registries for these
identifiers. identifiers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2014. This Internet-Draft will expire on May 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Cryptographic Algorithms for Digital Signatures and MACs . . . 6 3. Cryptographic Algorithms for Digital Signatures and MACs . . . 6
3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 6 3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 6
3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7 3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7
3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 8 3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 8
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 9 3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 9
3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 10 3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 10
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 10
4. Cryptographic Algorithms for Encryption . . . . . . . . . . . 11 4. Cryptographic Algorithms for Key Management . . . . . . . . . 11
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 11 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 11
4.2. "enc" (Encryption Method) Header Parameter Values for 4.2. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 13
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 13
4.3. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 17 4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 13
4.4. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 17 4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 14
4.5. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 18 4.6. Key Agreement with Elliptic Curve Diffie-Hellman
4.6. Direct Encryption with a Shared Symmetric Key . . . . . . 18 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 14
4.7. Key Agreement with Elliptic Curve Diffie-Hellman 4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 14
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 18 4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 15
4.7.1. Header Parameters Used for ECDH Key Agreement . . . . 19 4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 15
4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 19 4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 15
4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 19 4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 15
4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 19 4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 17
4.7.2. Key Derivation for ECDH Key Agreement . . . . . . . . 19 4.7.1. Header Parameters Used for AES GCM Key Encryption . . 17
4.8. Key Encryption with AES GCM . . . . . . . . . . . . . . . 21 4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 17
4.8.1. Header Parameters Used for AES GCM Key Encryption . . 21 4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 17
4.8.1.1. "iv" (Initialization Vector) Header Parameter . . 21 4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 17
4.8.1.2. "tag" (Authentication Tag) Header Parameter . . . 22 4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 18
4.9. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 22 4.8.1.1. "p2s" (PBES2 salt) Parameter . . . . . . . . . . . 18
4.9.1. Header Parameters Used for PBES2 Key Encryption . . . 22 4.8.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 18
4.9.1.1. "p2s" (PBES2 salt) Parameter . . . . . . . . . . . 22 5. Cryptographic Algorithms for Content Encryption . . . . . . . 19
4.9.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 23 5.1. "enc" (Encryption Method) Header Parameter Values for
4.10. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 23 JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.10.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 23 5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 20
4.10.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23 5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 20
4.10.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 24 5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 20
4.10.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 25 5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 20
4.10.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 26 5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 22
4.10.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 26 5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 23
4.10.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 27 5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 23
4.10.6. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 27 5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 23
4.11. Plaintext Encryption with AES GCM . . . . . . . . . . . . 27 5.2.6. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 24
5. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 28 5.3. Plaintext Encryption with AES GCM . . . . . . . . . . . . 24
5.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28 6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 24
5.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 28 6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 25
5.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28 6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 25
5.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 29 6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 25
5.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 29 6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 25
5.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 29 6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 26
5.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 29 6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 26
5.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29 6.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 26
5.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30 6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 26
5.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 30 6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 26
5.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30 6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 27
5.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 30 6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 27
5.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 30 6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 27
5.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 30 6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 27
5.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 31 6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 27
5.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31 6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 27
5.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 31 6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 28
5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31 6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 28
5.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 31 6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 28
5.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 32 6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 28
5.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32 6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 28
5.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 33 6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 29
6.1. JSON Web Signature and Encryption Algorithms Registry . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Template . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. JSON Web Signature and Encryption Algorithms Registry . . 30
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35 7.1.1. Registration Template . . . . . . . . . . . . . . . . 31
6.2. JWE Header Parameter Names Registration . . . . . . . . . 39 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 32
6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 39 7.2. JWE Header Parameter Names Registration . . . . . . . . . 37
6.3. JSON Web Encryption Compression Algorithms Registry . . . 40 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 38
6.3.1. Registration Template . . . . . . . . . . . . . . . . 40 7.3. JSON Web Encryption Compression Algorithms Registry . . . 38
6.3.2. Initial Registry Contents . . . . . . . . . . . . . . 41 7.3.1. Registration Template . . . . . . . . . . . . . . . . 39
6.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 41 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 39
6.4.1. Registration Template . . . . . . . . . . . . . . . . 41 7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 39
6.4.2. Initial Registry Contents . . . . . . . . . . . . . . 42 7.4.1. Registration Template . . . . . . . . . . . . . . . . 40
6.5. JSON Web Key Parameters Registration . . . . . . . . . . . 43 7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 40
6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 43 7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 41
6.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 45 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 41
6.6.1. Registration Template . . . . . . . . . . . . . . . . 45 7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 43
6.6.2. Initial Registry Contents . . . . . . . . . . . . . . 46 7.6.1. Registration Template . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 44
7.1. Algorithms and Key Sizes will be Deprecated . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
7.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Algorithms and Key Sizes will be Deprecated . . . . . . . 45
7.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . . 47 8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 45
7.4. AES GCM Security Considerations . . . . . . . . . . . . . 47 8.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . . 45
7.5. Plaintext JWS Security Considerations . . . . . . . . . . 47 8.4. AES GCM Security Considerations . . . . . . . . . . . . . 46
7.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 48 8.5. Plaintext JWS Security Considerations . . . . . . . . . . 46
7.7. Reusing Key Material when Encrypting Keys . . . . . . . . 48 8.6. Differences between Digital Signatures and MACs . . . . . 47
7.8. Password Considerations . . . . . . . . . . . . . . . . . 48 8.7. Denial of Service Attacks . . . . . . . . . . . . . . . . 47
8. Internationalization Considerations . . . . . . . . . . . . . 49 8.8. Reusing Key Material when Encrypting Keys . . . . . . . . 47
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.9. Password Considerations . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . . 51 9. Internationalization Considerations . . . . . . . . . . . . . 48
Appendix A. Digital Signature/MAC Algorithm Identifier 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Cross-Reference . . . . . . . . . . . . . . . . . . . 53 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48
Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 54 Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 52
C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 55 A.1. Digital Signature/MAC Algorithm Identifier
C.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 56 Cross-Reference . . . . . . . . . . . . . . . . . . . . . 52
C.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 57 A.2. Key Management Algorithm Identifier Cross-Reference . . . 53
Appendix D. Example ECDH-ES Key Agreement Computation . . . . . . 58 A.3. Content Encryption Algorithm Identifier Cross-Reference . 53
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 60 Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 54
Appendix F. Document History . . . . . . . . . . . . . . . . . . 61 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 55
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 56
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 57
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 58
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 60
Appendix E. Document History . . . . . . . . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
The JSON Web Algorithms (JWA) specification registers cryptographic The JSON Web Algorithms (JWA) specification registers cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK)
[JWK] specifications. It defines several IANA registries for these [JWK] specifications. It defines several IANA registries for these
identifiers. All these specifications utilize JavaScript Object identifiers. All these specifications utilize JavaScript Object
Notation (JSON) [RFC4627] based data structures. This specification Notation (JSON) [RFC4627] based data structures. This specification
skipping to change at page 5, line 50 skipping to change at page 5, line 50
ASCII(STRING) denotes the octets of the ASCII [USASCII] ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING. representation of STRING.
The concatenation of two values A and B is denoted as A || B. The concatenation of two values A and B is denoted as A || B.
2. Terminology 2. Terminology
These terms defined by the JSON Web Signature (JWS) [JWS] These terms defined by the JSON Web Signature (JWS) [JWS]
specification are incorporated into this specification: "JSON Web specification are incorporated into this specification: "JSON Web
Signature (JWS)", "JSON Text Object", "JWS Header", "JWS Payload", Signature (JWS)", "JWS Header", "JWS Payload", "JWS Signature", "JWS
"JWS Signature", "JWS Protected Header", "Base64url Encoding", and Protected Header", "Base64url Encoding", and "JWS Signing Input".
"JWS Signing Input".
These terms defined by the JSON Web Encryption (JWE) [JWE] These terms defined by the JSON Web Encryption (JWE) [JWE]
specification are incorporated into this specification: "JSON Web specification are incorporated into this specification: "JSON Web
Encryption (JWE)", "Authenticated Encryption", "Plaintext", Encryption (JWE)", "Authenticated Encryption", "Plaintext",
"Ciphertext", "Additional Authenticated Data (AAD)", "Authentication "Ciphertext", "Additional Authenticated Data (AAD)", "Authentication
Tag", "Content Encryption Key (CEK)", "JWE Header", "JWE Encrypted Tag", "Content Encryption Key (CEK)", "JWE Header", "JWE Encrypted
Key", "JWE Initialization Vector", "JWE Ciphertext", "JWE Key", "JWE Initialization Vector", "JWE Ciphertext", "JWE
Authentication Tag", "JWE Protected Header", "Key Management Mode", Authentication Tag", "JWE Protected Header", "Key Management Mode",
"Key Encryption", "Key Wrapping", "Direct Key Agreement", "Key "Key Encryption", "Key Wrapping", "Direct Key Agreement", "Key
Agreement with Key Wrapping", and "Direct Encryption". Agreement with Key Wrapping", and "Direct Encryption".
skipping to change at page 7, line 5 skipping to change at page 6, line 36
JWS uses cryptographic algorithms to digitally sign or create a JWS uses cryptographic algorithms to digitally sign or create a
Message Authentication Codes (MAC) of the contents of the JWS Header Message Authentication Codes (MAC) of the contents of the JWS Header
and the JWS Payload. and the JWS Payload.
3.1. "alg" (Algorithm) Header Parameter Values for JWS 3.1. "alg" (Algorithm) Header Parameter Values for JWS
The table below is the set of "alg" (algorithm) header parameter The table below is the set of "alg" (algorithm) header parameter
values defined by this specification for use with JWS, each of which values defined by this specification for use with JWS, each of which
is explained in more detail in the following sections: is explained in more detail in the following sections:
+-----------+--------------------------------------+----------------+ +---------------+------------------------------+--------------------+
| alg | Digital Signature or MAC Algorithm | Implementation | | alg Parameter | Digital Signature or MAC | Implementation |
| Parameter | | Requirements | | Value | Algorithm | Requirements |
| Value | | | +---------------+------------------------------+--------------------+
+-----------+--------------------------------------+----------------+ | HS256 | HMAC using SHA-256 | Required |
| HS256 | HMAC using SHA-256 hash algorithm | Required | | HS384 | HMAC using SHA-384 | Optional |
| HS384 | HMAC using SHA-384 hash algorithm | Optional | | HS512 | HMAC using SHA-512 | Optional |
| HS512 | HMAC using SHA-512 hash algorithm | Optional | | RS256 | RSASSA-PKCS-v1_5 using | Recommended |
| RS256 | RSASSA-PKCS-v1_5 using SHA-256 hash | Recommended | | | SHA-256 | |
| | algorithm | | | RS384 | RSASSA-PKCS-v1_5 using | Optional |
| RS384 | RSASSA-PKCS-v1_5 using SHA-384 hash | Optional | | | SHA-384 | |
| | algorithm | | | RS512 | RSASSA-PKCS-v1_5 using | Optional |
| RS512 | RSASSA-PKCS-v1_5 using SHA-512 hash | Optional | | | SHA-512 | |
| | algorithm | | | ES256 | ECDSA using P-256 and | Recommended+ |
| ES256 | ECDSA using P-256 curve and SHA-256 | Recommended+ | | | SHA-256 | |
| | hash algorithm | | | ES384 | ECDSA using P-384 and | Optional |
| ES384 | ECDSA using P-384 curve and SHA-384 | Optional | | | SHA-384 | |
| | hash algorithm | | | ES512 | ECDSA using P-521 and | Optional |
| ES512 | ECDSA using P-521 curve and SHA-512 | Optional | | | SHA-512 | |
| | hash algorithm | | | PS256 | RSASSA-PSS using SHA-256 and | Optional |
| PS256 | RSASSA-PSS using SHA-256 hash | Optional | | | MGF1 with SHA-256 | |
| | algorithm and MGF1 mask generation | | | PS384 | RSASSA-PSS using SHA-384 and | Optional |
| | function with SHA-256 | | | | MGF1 with SHA-384 | |
| PS384 | RSASSA-PSS using SHA-384 hash | Optional | | PS512 | RSASSA-PSS using SHA-512 and | Optional |
| | algorithm and MGF1 mask generation | | | | MGF1 with SHA-512 | |
| | function with SHA-384 | | | none | No digital signature or MAC | Optional |
| PS512 | RSASSA-PSS using SHA-512 hash | Optional | | | performed | |
| | algorithm and MGF1 mask generation | | +---------------+------------------------------+--------------------+
| | function with SHA-512 | |
| none | No digital signature or MAC value | Optional |
| | included | |
+-----------+--------------------------------------+----------------+
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
See Appendix A for a table cross-referencing the digital signature See Appendix A.1 for a table cross-referencing the JWS digital
and MAC "alg" (algorithm) values used in this specification with the signature and MAC "alg" (algorithm) values defined in this
equivalent identifiers used by other standards and software packages. specification with the equivalent identifiers used by other standards
and software packages.
3.2. HMAC with SHA-2 Functions 3.2. HMAC with SHA-2 Functions
Hash-based Message Authentication Codes (HMACs) enable one to use a Hash-based Message Authentication Codes (HMACs) enable one to use a
secret plus a cryptographic hash function to generate a Message secret plus a cryptographic hash function to generate a Message
Authentication Code (MAC). This can be used to demonstrate that Authentication Code (MAC). This can be used to demonstrate that
whoever generated the MAC was in possession of the MAC key. whoever generated the MAC was in possession of the MAC key.
The algorithm for implementing and validating HMACs is provided in The algorithm for implementing and validating HMACs is provided in
RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA- RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA-
skipping to change at page 11, line 20 skipping to change at page 10, line 52
RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and
using MGF1 as the mask generation function with SHA-256. using MGF1 as the mask generation function with SHA-256.
Signing with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms Signing with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms
is performed identically to the procedure for RSASSA-PSS SHA-256 -- is performed identically to the procedure for RSASSA-PSS SHA-256 --
just using the alternative hash algorithm in both roles. just using the alternative hash algorithm in both roles.
3.6. Using the Algorithm "none" 3.6. Using the Algorithm "none"
JWSs MAY also be created that do not provide integrity protection. JWSs MAY also be created that do not provide integrity protection.
Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the Such a JWS is called a "Plaintext JWS". A Plaintext JWS MUST use the
"alg" value "none", and are formatted identically to other JWSs, but "alg" value "none", and is formatted identically to other JWSs, but
with the empty string for its JWS Signature value. See Section 7.5 MUST use the empty octet sequence as its JWS Signature value.
for security considerations associated with using this algorithm. Receivers MUST verify that the JWS Signature value is the empty octet
sequence. See Section 8.5 for security considerations associated
with using this algorithm.
4. Cryptographic Algorithms for Encryption 4. Cryptographic Algorithms for Key Management
JWE uses cryptographic algorithms to encrypt the Content Encryption JWE uses cryptographic algorithms to encrypt or determine the Content
Key (CEK) and the Plaintext. Encryption Key (CEK).
4.1. "alg" (Algorithm) Header Parameter Values for JWE 4.1. "alg" (Algorithm) Header Parameter Values for JWE
The table below is the set of "alg" (algorithm) Header Parameter The table below is the set of "alg" (algorithm) Header Parameter
values that are defined by this specification for use with JWE. values that are defined by this specification for use with JWE.
These algorithms are used to encrypt the CEK, producing the JWE These algorithms are used to encrypt the CEK, producing the JWE
Encrypted Key, or to use key agreement to agree upon the CEK. Encrypted Key, or to use key agreement to agree upon the CEK.
+-------------------+-----------------+------------+----------------+ +-------------------+-----------------+------------+----------------+
| alg Parameter | Key Management | Additional | Implementation | | alg Parameter | Key Management | Additional | Implementation |
| Value | Algorithm | Header | Requirements | | Value | Algorithm | Header | Requirements |
| | | Parameters | | | | | Parameters | |
+-------------------+-----------------+------------+----------------+ +-------------------+-----------------+------------+----------------+
| RSA1_5 | RSAES-PKCS1-V1_ | (none) | Required | | RSA1_5 | RSAES-PKCS1-V1_ | (none) | Required |
| | 5[RFC3447] | | | | | 5 | | |
| RSA-OAEP | RSAES using | (none) | Optional | | RSA-OAEP | RSAES using | (none) | Optional |
| | Optimal | | | | | OAEP with | | |
| | Asymmetric | | | | | default | | |
| | Encryption | | |
| | Padding (OAEP) | | |
| | [RFC3447], with | | |
| | the default | | |
| | parameters | | | | | parameters | | |
| | specified by | | | | A128KW | AES Key Wrap | (none) | Recommended |
| | RFC 3447 in | | | | | with default | | |
| | Section A.2.1 | | |
| A128KW | Advanced | (none) | Recommended |
| | Encryption | | |
| | Standard (AES) | | |
| | Key Wrap | | |
| | Algorithm | | |
| | [RFC3394] using | | |
| | the default | | |
| | initial value | | | | | initial value | | |
| | specified in | | | | | using 128 bit | | |
| | Section 2.2.3.1 | | | | | key | | |
| | and using 128 | | |
| | bit keys | | |
| A192KW | AES Key Wrap | (none) | Optional | | A192KW | AES Key Wrap | (none) | Optional |
| | Algorithm using | | | | | with default | | |
| | the default | | |
| | initial value | | | | | initial value | | |
| | specified in | | | | | using 192 bit | | |
| | Section 2.2.3.1 | | | | | key | | |
| | and using 192 | | |
| | bit keys | | |
| A256KW | AES Key Wrap | (none) | Recommended | | A256KW | AES Key Wrap | (none) | Recommended |
| | Algorithm using | | | | | with default | | |
| | the default | | |
| | initial value | | | | | initial value | | |
| | specified in | | | | | using 256 bit | | |
| | Section 2.2.3.1 | | | | | key | | |
| | and using 256 | | |
| | bit keys | | |
| dir | Direct use of a | (none) | Recommended | | dir | Direct use of a | (none) | Recommended |
| | shared | | | | | shared | | |
| | symmetric key | | | | | symmetric key | | |
| | as the Content | | | | | as the CEK | | |
| | Encryption Key | | |
| | (CEK) for the | | |
| | content | | |
| | encryption step | | |
| | (rather than | | |
| | using the | | |
| | symmetric key | | |
| | to wrap the | | |
| | CEK) | | |
| ECDH-ES | Elliptic Curve | "epk", | Recommended+ | | ECDH-ES | Elliptic Curve | "epk", | Recommended+ |
| | Diffie-Hellman | "apu", | | | | Diffie-Hellman | "apu", | |
| | Ephemeral | "apv" | | | | Ephemeral | "apv" | |
| | Static | | |
| | [RFC6090] key | | |
| | agreement using | | |
| | the Concat KDF, | | |
| | as defined in | | |
| | Section 5.8.1 | | |
| | of | | |
| | [NIST.800-56A], | | |
| | with the | | |
| | agreed-upon key | | |
| | being used | | |
| | directly as the | | |
| | Content | | |
| | Encryption Key | | |
| | (CEK) (rather | | |
| | than being used | | |
| | to wrap the | | |
| | CEK), as | | |
| | specified in | | |
| | Section 4.7 | | |
| ECDH-ES+A128KW | Elliptic Curve | "epk", | Recommended |
| | Diffie-Hellman | "apu", | |
| | Ephemeral | "apv" | |
| | Static key | | | | | Static key | | |
| | agreement per | | | | | agreement using | | |
| | "ECDH-ES" and | | | | | Concat KDF | | |
| | Section 4.7, | | | | ECDH-ES+A128KW | ECDH-ES using | "epk", | Recommended |
| | where the | | | | | Concat KDF and | "apu", | |
| | agreed-upon key | | | | | CEK wrapped | "apv" | |
| | is used to wrap | | | | | with "A128KW" | | |
| | the Content | | | | ECDH-ES+A192KW | ECDH-ES using | "epk", | Optional |
| | Encryption Key | | | | | Concat KDF and | "apu", | |
| | (CEK) with the | | | | | CEK wrapped | "apv" | |
| | "A128KW" | | | | | with "A192KW" | | |
| | function | | | | ECDH-ES+A256KW | ECDH-ES using | "epk", | Recommended |
| | (rather than | | | | | Concat KDF and | "apu", | |
| | being used | | | | | CEK wrapped | "apv" | |
| | directly as the | | | | | with "A256KW" | | |
| | CEK) | | | | A128GCMKW | Key wrapping | "iv", | Optional |
| ECDH-ES+A192KW | Elliptic Curve | "epk", | Optional | | | with AES GCM | "tag" | |
| | Diffie-Hellman | "apu", | |
| | Ephemeral | "apv" | |
| | Static key | | |
| | agreement, | | |
| | where the | | |
| | agreed-upon key | | |
| | is used to wrap | | |
| | the Content | | |
| | Encryption Key | | |
| | (CEK) with the | | |
| | "A192KW" | | |
| | function | | |
| | (rather than | | |
| | being used | | |
| | directly as the | | |
| | CEK) | | |
| ECDH-ES+A256KW | Elliptic Curve | "epk", | Recommended |
| | Diffie-Hellman | "apu", | |
| | Ephemeral | "apv" | |
| | Static key | | |
| | agreement, | | |
| | where the | | |
| | agreed-upon key | | |
| | is used to wrap | | |
| | the Content | | |
| | Encryption Key | | |
| | (CEK) with the | | |
| | "A256KW" | | |
| | function | | |
| | (rather than | | |
| | being used | | |
| | directly as the | | |
| | CEK) | | |
| A128GCMKW | AES in | "iv", | Optional |
| | Galois/Counter | "tag" | |
| | Mode (GCM) | | |
| | [AES] | | |
| | [NIST.800-38D] | | |
| | using 128 bit | | |
| | keys | | |
| A192GCMKW | AES GCM using | "iv", | Optional |
| | 192 bit keys | "tag" | |
| A256GCMKW | AES GCM using | "iv", | Optional |
| | 256 bit keys | "tag" | |
| PBES2-HS256+A128K | PBES2 [RFC2898] | "p2s", | Optional |
| W | with HMAC | "p2c" | |
| | SHA-256 as the | | |
| | PRF and AES Key | | |
| | Wrap [RFC3394] | | |
| | using 128 bit | | | | | using 128 bit | | |
| | keys for the | | | | | key | | |
| | encryption | | | | A192GCMKW | Key wrapping | "iv", | Optional |
| | scheme | | | | | with AES GCM | "tag" | |
| | using 192 bit | | |
| | key | | |
| A256GCMKW | Key wrapping | "iv", | Optional |
| | with AES GCM | "tag" | |
| | using 256 bit | | |
| | key | | |
| PBES2-HS256+A128K | PBES2 with HMAC | "p2s", | Optional |
| W | SHA-256 and | "p2c" | |
| | "A128KW" | | |
| | wrapping | | |
| PBES2-HS384+A192K | PBES2 with HMAC | "p2s", | Optional | | PBES2-HS384+A192K | PBES2 with HMAC | "p2s", | Optional |
| W | SHA-256 as the | "p2c" | | | W | SHA-384 and | "p2c" | |
| | PRF and AES Key | | | | | "A192KW" | | |
| | Wrap using 192 | | | | | wrapping | | |
| | bit keys for | | |
| | the encryption | | |
| | scheme | | |
| PBES2-HS512+A256K | PBES2 with HMAC | "p2s", | Optional | | PBES2-HS512+A256K | PBES2 with HMAC | "p2s", | Optional |
| W | SHA-256 as the | "p2c" | | | W | SHA-512 and | "p2c" | |
| | PRF and AES Key | | | | | "A256KW" | | |
| | Wrap using 256 | | | | | wrapping | | |
| | bit keys for | | |
| | the encryption | | |
| | scheme | | |
+-------------------+-----------------+------------+----------------+ +-------------------+-----------------+------------+----------------+
The Additional Header Parameters column indicates what additional The Additional Header Parameters column indicates what additional
Header Parameters are used by the algorithm, beyond "alg", which all Header Parameters are used by the algorithm, beyond "alg", which all
use. All but "dir" and "ECDH-ES" also produce a JWE Encrypted Key use. All but "dir" and "ECDH-ES" also produce a JWE Encrypted Key
value. value.
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
4.2. "enc" (Encryption Method) Header Parameter Values for JWE See Appendix A.2 for a table cross-referencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
The table below is the set of "enc" (encryption method) Header identifiers used by other standards and software packages.
Parameter values that are defined by this specification for use with
JWE. These algorithms are used to encrypt the Plaintext, which
produces the Ciphertext.
+-------------+------------------------+------------+---------------+
| enc | Content Encryption | Additional | Implementatio |
| Parameter | Algorithm | Header | nRequirements |
| Value | | Parameters | |
+-------------+------------------------+------------+---------------+
| A128CBC-HS2 | The | (none) | Required |
| 56 | AES_128_CBC_HMAC_SHA_2 | | |
| | 56 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 4.10.3. This | | |
| | algorithm uses a 256 | | |
| | bit key. | | |
| A192CBC-HS3 | The | (none) | Optional |
| 84 | AES_192_CBC_HMAC_SHA_3 | | |
| | 84 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 4.10.4. This | | |
| | algorithm uses a 384 | | |
| | bit key. | | |
| A256CBC-HS5 | The | (none) | Required |
| 12 | AES_256_CBC_HMAC_SHA_5 | | |
| | 12 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 4.10.5. This | | |
| | algorithm uses a 512 | | |
| | bit key. | | |
| A128GCM | AES in Galois/Counter | (none) | Recommended |
| | Mode (GCM) [AES] | | |
| | [NIST.800-38D] using | | |
| | 128 bit keys | | |
| A192GCM | AES GCM using 192 bit | (none) | Optional |
| | keys | | |
| A256GCM | AES GCM using 256 bit | (none) | Recommended |
| | keys | | |
+-------------+------------------------+------------+---------------+
The Additional Header Parameters column indicates what additional
Header Parameters are used by the algorithm, beyond "enc", which all
use. All also use a JWE Initialization Vector value and produce JWE
Ciphertext and JWE Authentication Tag values.
See Appendix B for a table cross-referencing the encryption "alg"
(algorithm) and "enc" (encryption method) values used in this
specification with the equivalent identifiers used by other standards
and software packages.
4.3. Key Encryption with RSAES-PKCS1-V1_5 4.2. Key Encryption with RSAES-PKCS1-V1_5
This section defines the specifics of encrypting a JWE CEK with This section defines the specifics of encrypting a JWE CEK with
RSAES-PKCS1-V1_5 [RFC3447]. The "alg" Header Parameter value RSAES-PKCS1-V1_5 [RFC3447]. The "alg" Header Parameter value
"RSA1_5" is used in this case. "RSA1_5" is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm. A key of size 2048 bits or larger MUST be used with this algorithm.
An example using this algorithm is shown in Appendix A.2 of [JWE]. An example using this algorithm is shown in Appendix A.2 of [JWE].
4.4. Key Encryption with RSAES OAEP 4.3. Key Encryption with RSAES OAEP
This section defines the specifics of encrypting a JWE CEK with RSAES This section defines the specifics of encrypting a JWE CEK with RSAES
using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with
the default parameters specified by RFC 3447 in Section A.2.1. the default parameters specified by RFC 3447 in Section A.2.1.
(Those default parameters are using a hash function of SHA-1 and a (Those default parameters are using a hash function of SHA-1 and a
mask generation function of MGF1 with SHA-1.) The "alg" Header mask generation function of MGF1 with SHA-1.) The "alg" Header
Parameter value "RSA-OAEP" is used in this case. Parameter value "RSA-OAEP" is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm. A key of size 2048 bits or larger MUST be used with this algorithm.
An example using this algorithm is shown in Appendix A.1 of [JWE]. An example using this algorithm is shown in Appendix A.1 of [JWE].
4.5. Key Wrapping with AES Key Wrap 4.4. Key Wrapping with AES Key Wrap
This section defines the specifics of encrypting a JWE CEK with the This section defines the specifics of encrypting a JWE CEK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
the default initial value specified in Section 2.2.3.1 using 128, the default initial value specified in Section 2.2.3.1 using a 128,
192, or 256 bit keys. The "alg" Header Parameter values "A128KW", 192, or 256 bit key. The "alg" Header Parameter values "A128KW",
"A192KW", or "A256KW" are respectively used in this case. "A192KW", or "A256KW" are respectively used in this case.
An example using this algorithm is shown in Appendix A.3 of [JWE]. An example using this algorithm is shown in Appendix A.3 of [JWE].
4.6. Direct Encryption with a Shared Symmetric Key 4.5. Direct Encryption with a Shared Symmetric Key
This section defines the specifics of directly performing symmetric This section defines the specifics of directly performing symmetric
key encryption without performing a key wrapping step. In this case, key encryption without performing a key wrapping step. In this case,
the shared symmetric key is used directly as the Content Encryption the shared symmetric key is used directly as the Content Encryption
Key (CEK) value for the "enc" algorithm. An empty octet sequence is Key (CEK) value for the "enc" algorithm. An empty octet sequence is
used as the JWE Encrypted Key value. The "alg" Header Parameter used as the JWE Encrypted Key value. The "alg" Header Parameter
value "dir" is used in this case. value "dir" is used in this case.
Refer to the security considerations on key lifetimes in Section 7.2 Refer to the security considerations on key lifetimes in Section 8.2
and AES GCM in Section 7.4 when considering utilizing direct and AES GCM in Section 8.4 when considering utilizing direct
encryption. encryption.
4.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static 4.6. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static
(ECDH-ES) (ECDH-ES)
This section defines the specifics of key agreement with Elliptic This section defines the specifics of key agreement with Elliptic
Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with
the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. The 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: key agreement result can be used in one of two ways:
1. directly as the Content Encryption Key (CEK) for the "enc" 1. directly as the Content Encryption Key (CEK) for the "enc"
algorithm, in the Direct Key Agreement mode, or algorithm, in the Direct Key Agreement mode, or
2. as a symmetric key used to wrap the CEK with the "A128KW", 2. as a symmetric key used to wrap the CEK with the "A128KW",
"A192KW", or "A256KW" algorithms, in the Key Agreement with Key "A192KW", or "A256KW" algorithms, in the Key Agreement with Key
Wrapping mode. Wrapping mode.
The "alg" Header Parameter value "ECDH-ES" is used in the Direct Key The "alg" Header Parameter value "ECDH-ES" is used in the Direct Key
Agreement mode and the values "ECDH-ES+A128KW", "ECDH-ES+A192KW", or Agreement mode. In this mode, the output of the Concat KDF MUST be a
"ECDH-ES+A256KW" are used in the Key Agreement with Key Wrapping key of the same length as that used by the "enc" algorithm; in this
mode. case, the empty octet sequence is used as the JWE Encrypted Key
value.
In the Direct Key Agreement case, the output of the Concat KDF MUST The "alg" Header Parameter values "ECDH-ES+A128KW", "ECDH-ES+A192KW",
be a key of the same length as that used by the "enc" algorithm; in or "ECDH-ES+A256KW" are used in the Key Agreement with Key Wrapping
this case, the empty octet sequence is used as the JWE Encrypted Key mode. In this mode, the output of the Concat KDF MUST be a key of
value. In the Key Agreement with Key Wrapping case, the output of the length needed for the specified key wrapping algorithm, one of
the Concat KDF MUST be a key of the length needed for the specified 128, 192, or 256 bits respectively.
key wrapping algorithm, one of 128, 192, or 256 bits respectively.
A new ephemeral public key value MUST be generated for each key A new ephemeral public key value MUST be generated for each key
agreement operation. agreement operation.
4.7.1. Header Parameters Used for ECDH Key Agreement 4.6.1. Header Parameters Used for ECDH Key Agreement
The following Header Parameter names are used for key agreement as The following Header Parameter names are used for key agreement as
defined below. defined below.
4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter 4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter
The "epk" (ephemeral public key) value created by the originator for The "epk" (ephemeral public key) value created by the originator for
the use in key agreement algorithms. This key is represented as a 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 JSON Web Key [JWK] public key value. It MUST contain only public key
parameters and SHOULD contain only the minimum JWK parameters parameters and SHOULD contain only the minimum JWK parameters
necessary to represent the key; other JWK parameters included can be necessary to represent the key; other JWK parameters included can be
checked for consistency and honored or can be ignored. This Header checked for consistency and honored or can be ignored. This Header
Parameter is REQUIRED and MUST be understood and processed by Parameter MUST be present and MUST be understood and processed by
implementations when these algorithms are used. implementations when these algorithms are used.
4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter 4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter
The "apu" (agreement PartyUInfo) value for key agreement algorithms The "apu" (agreement PartyUInfo) value for key agreement algorithms
using it (such as "ECDH-ES"), represented as a base64url encoded using it (such as "ECDH-ES"), represented as a base64url encoded
string. When used, the PartyUInfo value contains information about string. When used, the PartyUInfo value contains information about
the sender. Use of this Header Parameter is OPTIONAL. This Header the sender. Use of this Header Parameter is OPTIONAL. This Header
Parameter MUST be understood and processed by implementations when Parameter MUST be understood and processed by implementations when
these algorithms are used. these algorithms are used.
4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter 4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter
The "apv" (agreement PartyVInfo) value for key agreement algorithms The "apv" (agreement PartyVInfo) value for key agreement algorithms
using it (such as "ECDH-ES"), represented as a base64url encoded using it (such as "ECDH-ES"), represented as a base64url encoded
string. When used, the PartyVInfo value contains information about string. When used, the PartyVInfo value contains information about
the receiver. Use of this Header Parameter is OPTIONAL. This Header the receiver. Use of this Header Parameter is OPTIONAL. This Header
Parameter MUST be understood and processed by implementations when Parameter MUST be understood and processed by implementations when
these algorithms are used. these algorithms are used.
4.7.2. Key Derivation for ECDH Key Agreement 4.6.2. Key Derivation for ECDH Key Agreement
The key derivation process derives the agreed upon key from the The key derivation process derives the agreed upon key from the
shared secret Z established through the ECDH algorithm, per Section shared secret Z established through the ECDH algorithm, per Section
6.2.2.2 of [NIST.800-56A]. 6.2.2.2 of [NIST.800-56A].
Key derivation is performed using the Concat KDF, as defined in 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. Section 5.8.1 of [NIST.800-56A], where the Digest Method is SHA-256.
The Concat KDF parameters are set as follows: The Concat KDF parameters are set as follows:
Z This is set to the representation of the shared secret Z as an Z This is set to the representation of the shared secret Z as an
skipping to change at page 20, line 47 skipping to change at page 16, line 37
PartyVInfo) Header Parameter is present, Data is set to the result PartyVInfo) Header Parameter is present, Data is set to the result
of base64url decoding the "apv" value and Datalen is set to the 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 number of octets in Data. Otherwise, Datalen is set to 0 and Data
is set to the empty octet sequence. is set to the empty octet sequence.
SuppPubInfo This is set to the keydatalen represented as a 32 bit SuppPubInfo This is set to the keydatalen represented as a 32 bit
big endian integer. big endian integer.
SuppPrivInfo This is set to the empty octet sequence. SuppPrivInfo This is set to the empty octet sequence.
Applications MUST specify what values should be used in the "apu" and Applications need to specify how the "apu" and "apv" parameters are
"apv" parameters. The "apu" and "apv" values MUST be distinct. used for that application. The "apu" and "apv" values MUST be
Applications wishing to conform to [NIST.800-56A] need to provide distinct, when used. Applications wishing to conform to
values that meet the requirements of that document, e.g., by using [NIST.800-56A] need to provide values that meet the requirements of
values that identify the sender and recipient. Alternatively, that document, e.g., by using values that identify the sender and
applications MAY conduct key derivation in a manner similar to The recipient. Alternatively, applications MAY conduct key derivation in
Diffie-Hellman Key Agreement Method [RFC2631]: In that case, the a manner similar to The Diffie-Hellman Key Agreement Method
"apu" field MAY either be omitted or represent a random 512-bit value [RFC2631]: In that case, the "apu" field MAY either be omitted or
(analogous to PartyAInfo in Ephemeral-Static mode in [RFC2631]) and represent a random 512-bit value (analogous to PartyAInfo in
the "apv" field should not be present. Ephemeral-Static mode in [RFC2631]) and the "apv" field should not be
present.
See Appendix D for an example key agreement computation using this See Appendix C for an example key agreement computation using this
method. method.
4.8. Key Encryption with AES GCM 4.7. Key Encryption with AES GCM
This section defines the specifics of encrypting a JWE Content This section defines the specifics of encrypting a JWE Content
Encryption Key (CEK) with Advanced Encryption Standard (AES) in Encryption Key (CEK) with Advanced Encryption Standard (AES) in
Galois/Counter Mode (GCM) [AES] [NIST.800-38D] using 128, 192, or 256 Galois/Counter Mode (GCM) [AES] [NIST.800-38D] using a 128, 192, or
bit keys. The "alg" Header Parameter values "A128GCMKW", 256 bit key. The "alg" Header Parameter values "A128GCMKW",
"A192GCMKW", or "A256GCMKW" are respectively used in this case. "A192GCMKW", or "A256GCMKW" are respectively used in this case.
Use of an Initialization Vector of size 96 bits is REQUIRED with this Use of an Initialization Vector of size 96 bits is REQUIRED with this
algorithm. The Initialization Vector is represented in base64url algorithm. The Initialization Vector is represented in base64url
encoded form as the "iv" (initialization vector) Header Parameter encoded form as the "iv" (initialization vector) Header Parameter
value. value.
The Additional Authenticated Data value used is the empty octet The Additional Authenticated Data value used is the empty octet
string. string.
The requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
regardless of the key size. regardless of the key size.
The JWE Encrypted Key value is the Ciphertext output. The JWE Encrypted Key value is the Ciphertext output.
The Authentication Tag output is represented in base64url encoded The Authentication Tag output is represented in base64url encoded
form as the "tag" (authentication tag) Header Parameter value. form as the "tag" (authentication tag) Header Parameter value.
4.8.1. Header Parameters Used for AES GCM Key Encryption 4.7.1. Header Parameters Used for AES GCM Key Encryption
The following Header Parameters are used for AES GCM key encryption. The following Header Parameters are used for AES GCM key encryption.
4.8.1.1. "iv" (Initialization Vector) Header Parameter 4.7.1.1. "iv" (Initialization Vector) Header Parameter
The "iv" (initialization vector) Header Parameter value is the The "iv" (initialization vector) Header Parameter value is the
base64url encoded representation of the Initialization Vector value base64url encoded representation of the Initialization Vector value
used for the key encryption operation. This Header Parameter is used for the key encryption operation. This Header Parameter MUST be
REQUIRED and MUST be understood and processed by implementations when present and MUST be understood and processed by implementations when
these algorithms are used. these algorithms are used.
4.8.1.2. "tag" (Authentication Tag) Header Parameter 4.7.1.2. "tag" (Authentication Tag) Header Parameter
The "tag" (authentication tag) Header Parameter value is the The "tag" (authentication tag) Header Parameter value is the
base64url encoded representation of the Authentication Tag value base64url encoded representation of the Authentication Tag value
resulting from the key encryption operation. This Header Parameter resulting from the key encryption operation. This Header Parameter
is REQUIRED and MUST be understood and processed by implementations MUST be present and MUST be understood and processed by
when these algorithms are used. implementations when these algorithms are used.
4.9. Key Encryption with PBES2 4.8. Key Encryption with PBES2
The "PBES2-HS256+A128KW", "PBES2-HS384+A192KW", and The "PBES2-HS256+A128KW", "PBES2-HS384+A192KW", and
"PBES2-HS512+A256KW" composite algorithms are used to perform "PBES2-HS512+A256KW" composite algorithms are used to perform
password-based encryption of a JWE CEK, by first deriving a key password-based encryption of a JWE CEK, by first deriving a key
encryption key from a user-supplied password, then encrypting the JWE encryption key from a user-supplied password, then encrypting the JWE
CEK using the derived key. These algorithms are PBES2 schemes as CEK using the derived key. These algorithms are PBES2 schemes as
specified in Section 6.2 of [RFC2898]. specified in Section 6.2 of [RFC2898].
These algorithms use HMAC SHA-2 algorithms as the Pseudo-Random These algorithms use HMAC SHA-2 algorithms as the Pseudo-Random
Function (PRF) for the PBKDF2 key derivation and AES Key Wrap Function (PRF) for the PBKDF2 key derivation and AES Key Wrap
[RFC3394] for the encryption scheme. The salt MUST be provided as [RFC3394] for the encryption scheme. The PBES2 password input is an
the "p2s" Header Parameter value, and MUST be base64url decoded to 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 MUST be provided
as the "p2s" Header Parameter value, and MUST be base64url decoded to
obtain the value. The iteration count parameter MUST be provided as obtain the value. The iteration count parameter MUST be provided as
the "p2c" Header Parameter value. The algorithms respectively use the "p2c" Header Parameter value. The algorithms respectively use
HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 as the PRF and use 128, 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 192, and 256 bit AES Key Wrap keys. Their derived-key lengths
respectively are 16, 24, and 32 octets. respectively are 16, 24, and 32 octets.
See Appendix C of JSON Web Key (JWK) [JWK] for an example key See Appendix C of JSON Web Key (JWK) [JWK] for an example key
encryption computation using "PBES2-HS256+A128KW". encryption computation using "PBES2-HS256+A128KW".
4.9.1. Header Parameters Used for PBES2 Key Encryption 4.8.1. Header Parameters Used for PBES2 Key Encryption
The following Header Parameters are used for Key Encryption with The following Header Parameters are used for Key Encryption with
PBES2. PBES2.
4.9.1.1. "p2s" (PBES2 salt) Parameter 4.8.1.1. "p2s" (PBES2 salt) Parameter
The "p2s" (PBES2 salt) Header Parameter contains the PBKDF2 salt The "p2s" (PBES2 salt) Header Parameter contains the PBKDF2 salt
value, encoded using base64url. This Header Parameter is REQUIRED value, encoded using base64url. This Header Parameter MUST be
and MUST be understood and processed by implementations when these present and MUST be understood and processed by implementations when
algorithms are used. these algorithms are used.
The salt expands the possible keys that can be derived from a given The salt expands the possible keys that can be derived from a given
password. A salt value containing 8 or more octets MUST be used. A password. A salt value containing 8 or more octets MUST be used. A
new salt value MUST be generated randomly for every encryption new salt value MUST be generated randomly for every encryption
operation; see [RFC4086] for considerations on generating random operation; see [RFC4086] for considerations on generating random
values. values.
4.9.1.2. "p2c" (PBES2 count) Parameter 4.8.1.2. "p2c" (PBES2 count) Parameter
The "p2c" (PBES2 count) Header Parameter contains the PBKDF2 The "p2c" (PBES2 count) Header Parameter contains the PBKDF2
iteration count, represented as a positive integer. This Header iteration count, represented as a positive integer. This Header
Parameter is REQUIRED and MUST be understood and processed by Parameter MUST be present and MUST be understood and processed by
implementations when these algorithms are used. implementations when these algorithms are used.
The iteration count adds computational expense, ideally compounded by The iteration count adds computational expense, ideally compounded by
the possible range of keys introduced by the salt. A minimum the possible range of keys introduced by the salt. A minimum
iteration count of 1000 is RECOMMENDED. iteration count of 1000 is RECOMMENDED.
4.10. AES_CBC_HMAC_SHA2 Algorithms 5. Cryptographic Algorithms for Content Encryption
JWE uses cryptographic algorithms to encrypt the Plaintext.
5.1. "enc" (Encryption Method) Header Parameter Values for JWE
The table below is the set of "enc" (encryption method) Header
Parameter values that are defined by this specification for use with
JWE. These algorithms are used to encrypt the Plaintext, which
produces the Ciphertext.
+-------------+------------------------+------------+---------------+
| enc | Content Encryption | Additional | Implementatio |
| Parameter | Algorithm | Header | nRequirements |
| Value | | Parameters | |
+-------------+------------------------+------------+---------------+
| A128CBC-HS2 | AES_128_CBC_HMAC_SHA_2 | (none) | Required |
| 56 | 56 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 5.2.3 | | |
| A192CBC-HS3 | AES_192_CBC_HMAC_SHA_3 | (none) | Optional |
| 84 | 84 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 5.2.4 | | |
| A256CBC-HS5 | AES_256_CBC_HMAC_SHA_5 | (none) | Required |
| 12 | 12 authenticated | | |
| | encryption algorithm, | | |
| | as defined in | | |
| | Section 5.2.5 | | |
| A128GCM | AES GCM using 128 bit | (none) | Recommended |
| | key | | |
| A192GCM | AES GCM using 192 bit | (none) | Optional |
| | key | | |
| A256GCM | AES GCM using 256 bit | (none) | Recommended |
| | key | | |
+-------------+------------------------+------------+---------------+
The Additional Header Parameters column indicates what additional
Header Parameters are used by the algorithm, beyond "enc", which all
use. All also use a JWE Initialization Vector value and produce JWE
Ciphertext and JWE Authentication Tag values.
See Appendix A.3 for a table cross-referencing the JWE "enc"
(encryption method) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
5.2. AES_CBC_HMAC_SHA2 Algorithms
This section defines a family of authenticated encryption algorithms This section defines a family of authenticated encryption algorithms
built using a composition of Advanced Encryption Standard (AES) in built using a composition of Advanced Encryption Standard (AES) in
Cipher Block Chaining (CBC) mode with PKCS #5 padding [AES] Cipher Block Chaining (CBC) mode with PKCS #5 padding [AES]
[NIST.800-38A] operations and HMAC [RFC2104] [SHS] operations. This [NIST.800-38A] operations and HMAC [RFC2104] [SHS] operations. This
algorithm family is called AES_CBC_HMAC_SHA2. It also defines three 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 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 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 third using 256 bit CBC keys and HMAC SHA-512. Test cases for these
algorithms can be found in Appendix C. algorithms can be found in Appendix B.
These algorithms are based upon Authenticated Encryption with AES-CBC These algorithms are based upon Authenticated Encryption with AES-CBC
and HMAC-SHA [I-D.mcgrew-aead-aes-cbc-hmac-sha2], performing the same and HMAC-SHA [I-D.mcgrew-aead-aes-cbc-hmac-sha2], performing the same
cryptographic computations, but with the Initialization Vector and cryptographic computations, but with the Initialization Vector and
Authentication Tag values remaining separate, rather than being Authentication Tag values remaining separate, rather than being
concatenated with the Ciphertext value in the output representation. concatenated with the Ciphertext value in the output representation.
This option is discussed in Appendix B of that specification. This This option is discussed in Appendix B of that specification. This
algorithm family is a generalization of the algorithm family in algorithm family is a generalization of the algorithm family in
[I-D.mcgrew-aead-aes-cbc-hmac-sha2], and can be used to implement [I-D.mcgrew-aead-aes-cbc-hmac-sha2], and can be used to implement
those algorithms. those algorithms.
4.10.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2
We use the following notational conventions. We use the following notational conventions.
CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS
#5 padding using the cipher with the key X. #5 padding using the cipher with the key X.
MAC(Y, M) denotes the application of the Message Authentication MAC(Y, M) denotes the application of the Message Authentication
Code (MAC) to the message M, using the key Y. Code (MAC) to the message M, using the key Y.
4.10.2. Generic AES_CBC_HMAC_SHA2 Algorithm 5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm
This section defines AES_CBC_HMAC_SHA2 in a manner that is 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. independent of the AES CBC key size or hash function to be used.
Section 4.10.2.1 and Section 4.10.2.2 define the generic encryption Section 5.2.2.1 and Section 5.2.2.2 define the generic encryption and
and decryption algorithms. Section 4.10.3 and Section 4.10.5 define decryption algorithms. Section 5.2.3 and Section 5.2.5 define
instances of AES_CBC_HMAC_SHA2 that specify those details. instances of AES_CBC_HMAC_SHA2 that specify those details.
4.10.2.1. AES_CBC_HMAC_SHA2 Encryption 5.2.2.1. AES_CBC_HMAC_SHA2 Encryption
The authenticated encryption algorithm takes as input four octet The authenticated encryption algorithm takes as input four octet
strings: a secret key K, a plaintext P, associated data A, and an strings: a secret key K, a plaintext P, associated data A, and an
initialization vector IV. The authenticated ciphertext value E and initialization vector IV. The authenticated ciphertext value E and
the authentication tag value T are provided as outputs. The data in the authentication tag value T are provided as outputs. The data in
the plaintext are encrypted and authenticated, and the associated the plaintext are encrypted and authenticated, and the associated
data are authenticated, but not encrypted. data are authenticated, but not encrypted.
The encryption process is as follows, or uses an equivalent set of The encryption process is as follows, or uses an equivalent set of
steps: steps:
skipping to change at page 24, line 32 skipping to change at page 21, line 24
MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in
order. order.
ENC_KEY consists of the final ENC_KEY_LEN octets of K, in ENC_KEY consists of the final ENC_KEY_LEN octets of K, in
order. order.
Here we denote the number of octets in the MAC_KEY as Here we denote the number of octets in the MAC_KEY as
MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;
the values of these parameters are specified by the AEAD the values of these parameters are specified by the AEAD
algorithms (in Section 4.10.3 and Section 4.10.5). The number of algorithms (in Section 5.2.3 and Section 5.2.5). The number of
octets in the input key K is the sum of MAC_KEY_LEN and octets in the input key K is the sum of MAC_KEY_LEN and
ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY
and ENC_KEY MUST NOT overlap. Note that the MAC key comes before and ENC_KEY MUST NOT overlap. Note that the MAC key comes before
the encryption key in the input key K; this is in the opposite the encryption key in the input key K; this is in the opposite
order of the algorithm names in the identifier order of the algorithm names in the identifier
"AES_CBC_HMAC_SHA2". "AES_CBC_HMAC_SHA2".
2. The Initialization Vector (IV) used is a 128 bit value generated 2. The Initialization Vector (IV) used is a 128 bit value generated
randomly or pseudorandomly for use in the cipher. randomly or pseudorandomly for use in the cipher.
skipping to change at page 25, line 34 skipping to change at page 22, line 27
MAC_KEY = initial MAC_KEY_LEN bytes of K, MAC_KEY = initial MAC_KEY_LEN bytes of K,
ENC_KEY = final ENC_KEY_LEN bytes of K, ENC_KEY = final ENC_KEY_LEN bytes of K,
E = CBC-PKCS5-ENC(ENC_KEY, P), E = CBC-PKCS5-ENC(ENC_KEY, P),
M = MAC(MAC_KEY, A || IV || E || AL), M = MAC(MAC_KEY, A || IV || E || AL),
T = initial T_LEN bytes of M. T = initial T_LEN bytes of M.
4.10.2.2. AES_CBC_HMAC_SHA2 Decryption 5.2.2.2. AES_CBC_HMAC_SHA2 Decryption
The authenticated decryption operation has four inputs: K, A, E, and The authenticated decryption operation has four inputs: K, A, E, and
T as defined above. It has only a single output, either a plaintext 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 value P or a special symbol FAIL that indicates that the inputs are
not authentic. The authenticated decryption algorithm is as follows, not authentic. The authenticated decryption algorithm is as follows,
or uses an equivalent set of steps: or uses an equivalent set of steps:
1. The secondary keys MAC_KEY and ENC_KEY are generated from the 1. The secondary keys MAC_KEY and ENC_KEY are generated from the
input key K as in Step 1 of Section 4.10.2.1. input key K as in Step 1 of Section 5.2.2.1.
2. The integrity and authenticity of A and E are checked by 2. The integrity and authenticity of A and E are checked by
computing an HMAC with the inputs as in Step 5 of computing an HMAC with the inputs as in Step 5 of
Section 4.10.2.1. The value T, from the previous step, is 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 compared to the first MAC_KEY length bits of the HMAC output. If
those values are identical, then A and E are considered valid, those values are identical, then A and E are considered valid,
and processing is continued. Otherwise, all of the data used in and processing is continued. Otherwise, all of the data used in
the MAC validation are discarded, and the AEAD decryption the MAC validation are discarded, and the AEAD decryption
operation returns an indication that it failed, and the operation operation returns an indication that it failed, and the operation
halts. (But see Section 10 of [JWE] for security considerations halts. (But see Section 10 of [JWE] for security considerations
on thwarting timing attacks.) on thwarting timing attacks.)
3. The value E is decrypted and the PKCS #5 padding is removed. The 3. The value E is decrypted and the PKCS #5 padding is removed. The
value IV is used as the initialization vector. The value ENC_KEY value IV is used as the initialization vector. The value ENC_KEY
is used as the decryption key. is used as the decryption key.
4. The plaintext value is returned. 4. The plaintext value is returned.
4.10.3. AES_128_CBC_HMAC_SHA_256 5.2.3. AES_128_CBC_HMAC_SHA_256
This algorithm is a concrete instantiation of the generic This algorithm is a concrete instantiation of the generic
AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message
authentication code [RFC2104] with the SHA-256 hash function [SHS] to authentication code [RFC2104] with the SHA-256 hash function [SHS] to
provide message authentication, with the HMAC output truncated to 128 provide message authentication, with the HMAC output truncated to 128
bits, corresponding to the HMAC-SHA-256-128 algorithm defined in bits, corresponding to the HMAC-SHA-256-128 algorithm defined in
[RFC4868]. For encryption, it uses AES in the Cipher Block Chaining [RFC4868]. For encryption, it uses AES in the Cipher Block Chaining
(CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A], (CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A],
with PKCS #5 padding. with PKCS #5 padding.
The input key K is 32 octets long. The input key K is 32 octets long.
The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets.
The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16
octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
stripping off the final 16 octets. stripping off the final 16 octets.
4.10.4. AES_192_CBC_HMAC_SHA_384 5.2.4. AES_192_CBC_HMAC_SHA_384
AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but
with the following differences: with the following differences:
A 192 bit AES CBC key is used instead of 128. A 192 bit AES CBC key is used instead of 128.
SHA-384 is used in HMAC instead of SHA-256. SHA-384 is used in HMAC instead of SHA-256.
ENC_KEY_LEN is 24 octets instead of 16. ENC_KEY_LEN is 24 octets instead of 16.
MAC_KEY_LEN is 24 octets instead of 16. MAC_KEY_LEN is 24 octets instead of 16.
The length of the input key K is 48 octets instead of 32. The length of the input key K is 48 octets instead of 32.
The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of
16. 16.
4.10.5. AES_256_CBC_HMAC_SHA_512 5.2.5. AES_256_CBC_HMAC_SHA_512
AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but
with the following differences: with the following differences:
A 256 bit AES CBC key is used instead of 128. A 256 bit AES CBC key is used instead of 128.
SHA-512 is used in HMAC instead of SHA-256. SHA-512 is used in HMAC instead of SHA-256.
ENC_KEY_LEN is 32 octets instead of 16. ENC_KEY_LEN is 32 octets instead of 16.
MAC_KEY_LEN is 32 octets instead of 16. MAC_KEY_LEN is 32 octets instead of 16.
The length of the input key K is 64 octets instead of 32. The length of the input key K is 64 octets instead of 32.
The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of
16. 16.
4.10.6. Plaintext Encryption with AES_CBC_HMAC_SHA2 5.2.6. Plaintext Encryption with AES_CBC_HMAC_SHA2
The algorithm value "A128CBC-HS256" is used as the "alg" value when The algorithm value "A128CBC-HS256" is used as the "alg" value when
using AES_128_CBC_HMAC_SHA_256 with JWE. The algorithm value using AES_128_CBC_HMAC_SHA_256 with JWE. The algorithm value
"A192CBC-HS384" is used as the "alg" value when using "A192CBC-HS384" is used as the "alg" value when using
AES_192_CBC_HMAC_SHA_384 with JWE. The algorithm value AES_192_CBC_HMAC_SHA_384 with JWE. The algorithm value
"A256CBC-HS512" is used as the "alg" value when using "A256CBC-HS512" is used as the "alg" value when using
AES_256_CBC_HMAC_SHA_512 with JWE. AES_256_CBC_HMAC_SHA_512 with JWE.
4.11. Plaintext Encryption with AES GCM 5.3. Plaintext Encryption with AES GCM
This section defines the specifics of encrypting the JWE Plaintext This section defines the specifics of encrypting the JWE Plaintext
with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM)
[AES] [NIST.800-38D] using 128, 192, or 256 bit keys. The "enc" [AES] [NIST.800-38D] using a 128, 192, or 256 bit key. The "enc"
Header Parameter values "A128GCM", "A192GCM", or "A256GCM" are Header Parameter values "A128GCM", "A192GCM", or "A256GCM" are
respectively used in this case. respectively used in this case.
The CEK is used as the encryption key. The CEK is used as the encryption key.
Use of an initialization vector of size 96 bits is REQUIRED with this Use of an initialization vector of size 96 bits is REQUIRED with this
algorithm. algorithm.
The requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
regardless of the key size. regardless of the key size.
The JWE Authentication Tag is set to be the Authentication Tag value The JWE Authentication Tag is set to be the Authentication Tag value
produced by the encryption. During decryption, the received JWE produced by the encryption. During decryption, the received JWE
Authentication Tag is used as the Authentication Tag value. Authentication Tag is used as the Authentication Tag value.
An example using this algorithm is shown in Appendix A.1 of [JWE]. An example using this algorithm is shown in Appendix A.1 of [JWE].
5. Cryptographic Algorithms for Keys 6. Cryptographic Algorithms for Keys
A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a
cryptographic key. These keys can be either asymmetric or symmetric. cryptographic key. These keys can be either asymmetric or symmetric.
They can hold both public and private information about the key. They can hold both public and private information about the key.
This section defines the parameters for keys using the algorithms This section defines the parameters for keys using the algorithms
specified by this document. specified by this document.
5.1. "kty" (Key Type) Parameter Values 6.1. "kty" (Key Type) Parameter Values
The table below is the set of "kty" (key type) parameter values that The table below is the set of "kty" (key type) parameter values that
are defined by this specification for use in JWKs. are defined by this specification for use in JWKs.
+--------------+--------------------------------+-------------------+ +--------------+--------------------------------+-------------------+
| kty | Key Type | Implementation | | kty | Key Type | Implementation |
| Parameter | | Requirements | | Parameter | | Requirements |
| Value | | | | Value | | |
+--------------+--------------------------------+-------------------+ +--------------+--------------------------------+-------------------+
| EC | Elliptic Curve [DSS] | Recommended+ | | EC | Elliptic Curve [DSS] | Recommended+ |
| RSA | RSA [RFC3447] | Required | | RSA | RSA [RFC3447] | Required |
| oct | Octet sequence (used to | Required | | oct | Octet sequence (used to | Required |
| | represent symmetric keys) | | | | represent symmetric keys) | |
+--------------+--------------------------------+-------------------+ +--------------+--------------------------------+-------------------+
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
5.2. Parameters for Elliptic Curve Keys 6.2. Parameters for Elliptic Curve Keys
JWKs can represent Elliptic Curve [DSS] keys. In this case, the JWKs can represent Elliptic Curve [DSS] keys. In this case, the
"kty" member value MUST be "EC". "kty" member value MUST be "EC".
5.2.1. Parameters for Elliptic Curve Public Keys 6.2.1. Parameters for Elliptic Curve Public Keys
An elliptic curve public key is represented by a pair of coordinates An elliptic curve public key is represented by a pair of coordinates
drawn from a finite field, which together define a point on an drawn from a finite field, which together define a point on an
elliptic curve. The following members MUST be present for elliptic elliptic curve. The following members MUST be present for elliptic
curve public keys: curve public keys:
o "crv" o "crv"
o "x" o "x"
o "y" o "y"
SEC1 point compression is not supported for any values. SEC1 [SEC1] point compression is not supported for any values.
5.2.1.1. "crv" (Curve) Parameter 6.2.1.1. "crv" (Curve) Parameter
The "crv" (curve) member identifies the cryptographic curve used with The "crv" (curve) member identifies the cryptographic curve used with
the key. Curve values from [DSS] used by this specification are: the key. Curve values from [DSS] used by this specification are:
o "P-256" o "P-256"
o "P-384" o "P-384"
o "P-521" o "P-521"
These values are registered in the IANA JSON Web Key Elliptic Curve These values are registered in the IANA JSON Web Key Elliptic Curve
registry defined in Section 6.6. Additional "crv" values MAY be registry defined in Section 7.6. Additional "crv" values MAY be
used, provided they are understood by implementations using that used, provided they are understood by implementations using that
Elliptic Curve key. The "crv" value is a case sensitive string. Elliptic Curve key. The "crv" value is a case-sensitive string.
5.2.1.2. "x" (X Coordinate) Parameter 6.2.1.2. "x" (X Coordinate) Parameter
The "x" (x coordinate) member contains the x coordinate for the The "x" (x coordinate) member contains the x coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the octet string representation of the coordinate, as defined in the octet string representation of the coordinate, as defined in
Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST 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" 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 parameter. For example, if the value of "crv" is "P-521", the octet
string must be 66 octets long. string must be 66 octets long.
5.2.1.3. "y" (Y Coordinate) Parameter 6.2.1.3. "y" (Y Coordinate) Parameter
The "y" (y coordinate) member contains the y coordinate for the The "y" (y coordinate) member contains the y coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the octet string representation of the coordinate, as defined in the octet string representation of the coordinate, as defined in
Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST 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" 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 parameter. For example, if the value of "crv" is "P-521", the octet
string must be 66 octets long. string must be 66 octets long.
5.2.2. Parameters for Elliptic Curve Private Keys 6.2.2. Parameters for Elliptic Curve Private Keys
In addition to the members used to represent Elliptic Curve public In addition to the members used to represent Elliptic Curve public
keys, the following member MUST be present to represent Elliptic keys, the following member MUST be present to represent Elliptic
Curve private keys. Curve private keys.
5.2.2.1. "d" (ECC Private Key) Parameter 6.2.2.1. "d" (ECC Private Key) Parameter
The "d" (ECC private key) member contains the Elliptic Curve private The "d" (ECC private key) member contains the Elliptic Curve private
key value. It is represented as the base64url encoding of the octet key value. It is represented as the base64url encoding of the octet
string representation of the private key value, as defined in string representation of the private key value, as defined in
Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet Sections C.4 and 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 string MUST be ceiling(log-base-2(n)/8) octets (where n is the order
of the curve). of the curve).
5.3. Parameters for RSA Keys 6.3. Parameters for RSA Keys
JWKs can represent RSA [RFC3447] keys. In this case, the "kty" JWKs can represent RSA [RFC3447] keys. In this case, the "kty"
member value MUST be "RSA". member value MUST be "RSA".
5.3.1. Parameters for RSA Public Keys 6.3.1. Parameters for RSA Public Keys
The following members MUST be present for RSA public keys. The following members MUST be present for RSA public keys.
5.3.1.1. "n" (Modulus) Parameter 6.3.1.1. "n" (Modulus) Parameter
The "n" (modulus) member contains the modulus value for the RSA The "n" (modulus) member contains the modulus value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. The value's unsigned big endian representation as an octet sequence. The
octet sequence MUST utilize the minimum number of octets to represent octet sequence MUST utilize the minimum number of octets to represent
the value. the value.
5.3.1.2. "e" (Exponent) Parameter 6.3.1.2. "e" (Exponent) Parameter
The "e" (exponent) member contains the exponent value for the RSA The "e" (exponent) member contains the exponent value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. The value's unsigned big endian representation as an octet sequence. The
octet sequence MUST utilize the minimum number of octets to represent octet sequence MUST utilize the minimum number of octets to represent
the value. For instance, when representing the value 65537, the the value. For instance, when representing the value 65537, the
octet sequence to be base64url encoded MUST consist of the three octet sequence to be base64url encoded MUST consist of the three
octets [1, 0, 1]. octets [1, 0, 1].
5.3.2. Parameters for RSA Private Keys 6.3.2. Parameters for RSA Private Keys
In addition to the members used to represent RSA public keys, the In addition to the members used to represent RSA public keys, the
following members are used to represent RSA private keys. The following members are used to represent RSA private keys. The
parameter "d" is REQUIRED for RSA private keys. The others enable parameter "d" is REQUIRED for RSA private keys. The others enable
optimizations and SHOULD be included by producers of JWKs optimizations and SHOULD be included by producers of JWKs
representing RSA private keys. If the producer includes any of the representing RSA private keys. If the producer includes any of the
other private key parameters, then all of the others MUST be present, other private key parameters, then all of the others MUST be present,
with the exception of "oth", which MUST only be present when more with the exception of "oth", which MUST only be present when more
than two prime factors were used. The consumer of a JWK MAY choose than two prime factors were used. The consumer of a JWK MAY choose
to accept an RSA private key that does not contain a complete set of to accept an RSA private key that does not contain a complete set of
the private key parameters other than "d", including JWKs in which the private key parameters other than "d", including JWKs in which
"d" is the only RSA private key parameter included. "d" is the only RSA private key parameter included.
5.3.2.1. "d" (Private Exponent) Parameter 6.3.2.1. "d" (Private Exponent) Parameter
The "d" (private exponent) member contains the private exponent value The "d" (private exponent) member contains the private exponent value
for the RSA private key. It is represented as the base64url encoding for the RSA private key. It is represented as the base64url encoding
of the value's unsigned big endian representation as an octet of the value's unsigned big endian representation as an octet
sequence. The octet sequence MUST utilize the minimum number of sequence. The octet sequence MUST utilize the minimum number of
octets to represent the value. octets to represent the value.
5.3.2.2. "p" (First Prime Factor) Parameter 6.3.2.2. "p" (First Prime Factor) Parameter
The "p" (first prime factor) member contains the first prime factor, The "p" (first prime factor) member contains the first prime factor,
a positive integer. It is represented as the base64url encoding of a positive integer. It is represented as the base64url encoding of
the value's unsigned big endian representation as an octet sequence. the value's unsigned big endian representation as an octet sequence.
The octet sequence MUST utilize the minimum number of octets to The octet sequence MUST utilize the minimum number of octets to
represent the value. represent the value.
5.3.2.3. "q" (Second Prime Factor) Parameter 6.3.2.3. "q" (Second Prime Factor) Parameter
The "q" (second prime factor) member contains the second prime The "q" (second prime factor) member contains the second prime
factor, a positive integer. It is represented as the base64url factor, a positive integer. It is represented as the base64url
encoding of the value's unsigned big endian representation as an encoding of the value's unsigned big endian representation as an
octet sequence. The octet sequence MUST utilize the minimum number octet sequence. The octet sequence MUST utilize the minimum number
of octets to represent the value. of octets to represent the value.
5.3.2.4. "dp" (First Factor CRT Exponent) Parameter 6.3.2.4. "dp" (First Factor CRT Exponent) Parameter
The "dp" (first factor CRT exponent) member contains the Chinese The "dp" (first factor CRT exponent) member contains the Chinese
Remainder Theorem (CRT) exponent of the first factor, a positive Remainder Theorem (CRT) exponent of the first factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. The octet unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the sequence MUST utilize the minimum number of octets to represent the
value. value.
5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter 6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter
The "dq" (second factor CRT exponent) member contains the Chinese The "dq" (second factor CRT exponent) member contains the Chinese
Remainder Theorem (CRT) exponent of the second factor, a positive Remainder Theorem (CRT) exponent of the second factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. The octet unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the sequence MUST utilize the minimum number of octets to represent the
value. value.
5.3.2.6. "qi" (First CRT Coefficient) Parameter 6.3.2.6. "qi" (First CRT Coefficient) Parameter
The "dp" (first CRT coefficient) member contains the Chinese The "dp" (first CRT coefficient) member contains the Chinese
Remainder Theorem (CRT) coefficient of the second factor, a positive Remainder Theorem (CRT) coefficient of the second factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. The octet unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the sequence MUST utilize the minimum number of octets to represent the
value. value.
5.3.2.7. "oth" (Other Primes Info) Parameter 6.3.2.7. "oth" (Other Primes Info) Parameter
The "oth" (other primes info) member contains an array of information The "oth" (other primes info) member contains an array of information
about any third and subsequent primes, should they exist. When only about any third and subsequent primes, should they exist. When only
two primes have been used (the normal case), this parameter MUST be two primes have been used (the normal case), this parameter MUST be
omitted. When three or more primes have been used, the number of omitted. When three or more primes have been used, the number of
array elements MUST be the number of primes used minus two. Each array elements MUST be the number of primes used minus two. Each
array element MUST be an object with the following members: array element MUST be an object with the following members:
5.3.2.7.1. "r" (Prime Factor) 6.3.2.7.1. "r" (Prime Factor)
The "r" (prime factor) parameter within an "oth" array member The "r" (prime factor) parameter within an "oth" array member
represents the value of a subsequent prime factor, a positive represents the value of a subsequent prime factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. The octet unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the sequence MUST utilize the minimum number of octets to represent the
value. value.
5.3.2.7.2. "d" (Factor CRT Exponent) 6.3.2.7.2. "d" (Factor CRT Exponent)
The "d" (Factor CRT Exponent) parameter within an "oth" array member The "d" (Factor CRT Exponent) parameter within an "oth" array member
represents the CRT exponent of the corresponding prime factor, a represents the CRT exponent of the corresponding prime factor, a
positive integer. It is represented as the base64url encoding of the positive integer. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. The value's unsigned big endian representation as an octet sequence. The
octet sequence MUST utilize the minimum number of octets to represent octet sequence MUST utilize the minimum number of octets to represent
the value. the value.
5.3.2.7.3. "t" (Factor CRT Coefficient) 6.3.2.7.3. "t" (Factor CRT Coefficient)
The "t" (factor CRT coefficient) parameter within an "oth" array The "t" (factor CRT coefficient) parameter within an "oth" array
member represents the CRT coefficient of the corresponding prime member represents the CRT coefficient of the corresponding prime
factor, a positive integer. It is represented as the base64url factor, a positive integer. It is represented as the base64url
encoding of the value's unsigned big endian representation as an encoding of the value's unsigned big endian representation as an
octet sequence. The octet sequence MUST utilize the minimum number octet sequence. The octet sequence MUST utilize the minimum number
of octets to represent the value. of octets to represent the value.
5.4. Parameters for Symmetric Keys 6.4. Parameters for Symmetric Keys
When the JWK "kty" member value is "oct" (octet sequence), the member When the JWK "kty" member value is "oct" (octet sequence), the member
"k" is used to represent a symmetric key (or another key whose value "k" is used to represent a symmetric key (or another key whose value
is a single octet sequence). An "alg" member SHOULD also be present is a single octet sequence). An "alg" member SHOULD also be present
to identify the algorithm intended to be used with the key, unless to identify the algorithm intended to be used with the key, unless
the application uses another means or convention to determine the the application uses another means or convention to determine the
algorithm used. algorithm used.
5.4.1. "k" (Key Value) Parameter 6.4.1. "k" (Key Value) Parameter
The "k" (key value) member contains the value of the symmetric (or The "k" (key value) member contains the value of the symmetric (or
other single-valued) key. It is represented as the base64url other single-valued) key. It is represented as the base64url
encoding of the octet sequence containing the key value. encoding of the octet sequence containing the key value.
6. IANA Considerations 7. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two-week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
skipping to change at page 34, line 7 skipping to change at page 30, line 44
list. list.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification, in order to enable broadly-informed review of this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Expert(s). Expert(s).
6.1. JSON Web Signature and Encryption Algorithms Registry 7.1. JSON Web Signature and Encryption Algorithms Registry
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Algorithms registry for values of the JWS and JWE "alg" Encryption Algorithms registry for values of the JWS and JWE "alg"
(algorithm) and "enc" (encryption method) Header Parameters. The (algorithm) and "enc" (encryption method) Header Parameters. The
registry records the algorithm name, the algorithm usage locations registry records the algorithm name, the algorithm usage locations,
from the set "alg" and "enc", implementation requirements, and a implementation requirements, and a reference to the specification
reference to the specification that defines it. The same algorithm that defines it. The same algorithm name can be registered multiple
name MAY be registered multiple times, provided that the sets of times, provided that the sets of usage locations are disjoint.
usage locations are disjoint.
It is suggested that when algorithms can use keys of different It is suggested that when algorithms can use keys of different
lengths, that the length of the key be included in the algorithm lengths, that the length of the key be included in the algorithm
name. This allows readers of the JSON text to easily make security name. This allows readers of the JSON text to easily make security
consideration decisions. consideration decisions.
The implementation requirements of an algorithm MAY be changed over The implementation requirements of an algorithm MAY be changed over
time by the Designated Experts(s) as the cryptographic landscape time by the Designated Experts(s) as the cryptographic landscape
evolves, for instance, to change the status of an algorithm to evolves, for instance, to change the status of an algorithm to
Deprecated, or to change the status of an algorithm from Optional to Deprecated, or to change the status of an algorithm from Optional to
Recommended+ or Required. Changes of implementation requirements are Recommended+ or Required. Changes of implementation requirements are
only permitted on a Specification Required basis, with the new only permitted on a Specification Required basis, with the new
specification defining the revised implementation requirements level. specification defining the revised implementation requirements level.
6.1.1. Template 7.1.1. Registration Template
Algorithm Name: Algorithm Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case-
sensitive. Names may not match other registered names in a case sensitive. Names may not match other registered names in a case-
insensitive manner unless the Designated Expert(s) state that insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
Algorithm Description:
Brief description of the Algorithm (e.g., "Example description").
Algorithm Usage Location(s): Algorithm Usage Location(s):
The algorithm usage, which must be one or more of the values "alg" The algorithm usage location. This must be one or more of the
or "enc". 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.
Implementation Requirements: Implementation Requirements:
The algorithm implementation requirements, which must be one the The algorithm implementation requirements, which must be one the
words Required, Recommended, Optional, or Deprecated. Optionally, words Required, Recommended, Optional, Deprecated, or Prohibited.
the word can be followed by a "+" or "-". The use of "+" Optionally, the word can be followed by a "+" or "-". The use of
indicates that the requirement strength is likely to be increased "+" indicates that the requirement strength is likely to be
in a future version of the specification. The use of "-" increased in a future version of the specification. The use of
indicates that the requirement strength is likely to be decreased "-" indicates that the requirement strength is likely to be
in a future version of the specification. 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".
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.1.2. Initial Registry Contents 7.1.2. Initial Registry Contents
o Algorithm Name: "HS256" o Algorithm Name: "HS256"
o Algorithm Description: HMAC using SHA-256
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "HS384" o Algorithm Name: "HS384"
o Algorithm Description: HMAC using SHA-384
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "HS512" o Algorithm Name: "HS512"
o Algorithm Description: HMAC using SHA-512
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS256" o Algorithm Name: "RS256"
o Algorithm Description: RSASSA-PKCS-v1_5 using SHA-256
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS384" o Algorithm Name: "RS384"
o Algorithm Description: RSASSA-PKCS-v1_5 using SHA-384
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS512" o Algorithm Name: "RS512"
o Algorithm Description: RSASSA-PKCS-v1_5 using SHA-512
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES256" o Algorithm Name: "ES256"
o Algorithm Description: ECDSA using P-256 and SHA-256
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES384" o Algorithm Name: "ES384"
o Algorithm Description: ECDSA using P-384 and SHA-384
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES512" o Algorithm Name: "ES512"
o Algorithm Description: ECDSA using P-521 and SHA-512
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS256" o Algorithm Name: "PS256"
o Algorithm Description: RSASSA-PSS using SHA-256 and MGF1 with SHA-
256
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS384" o Algorithm Name: "PS384"
o Algorithm Description: RSASSA-PSS using SHA-384 and MGF1 with SHA-
384
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS512" o Algorithm Name: "PS512"
o Algorithm Description: RSASSA-PSS using SHA-512 and MGF1 with SHA-
512
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "none" o Algorithm Name: "none"
o Algorithm Description: No digital signature or MAC performed
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RSA1_5" o Algorithm Name: "RSA1_5"
o Algorithm Description: RSAES-PKCS1-V1_5
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "RSA-OAEP" o Algorithm Name: "RSA-OAEP"
o Algorithm Description: RSAES using OAEP with default parameters
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128KW" o Algorithm Name: "A128KW"
o Algorithm Description: AES Key Wrap using 128 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A192KW" o Algorithm Name: "A192KW"
o Algorithm Description: AES Key Wrap using 192 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A256KW" o Algorithm Name: "A256KW"
o Algorithm Description: AES Key Wrap using 256 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "dir" o Algorithm Name: "dir"
o Algorithm Description: Direct use of a shared symmetric key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES" o Algorithm Name: "ECDH-ES"
o Algorithm Description: ECDH-ES using Concat KDF
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A128KW" o Algorithm Name: "ECDH-ES+A128KW"
o Algorithm Description: ECDH-ES using Concat KDF and "A128KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A192KW" o Algorithm Name: "ECDH-ES+A192KW"
o Algorithm Description: ECDH-ES using Concat KDF and "A192KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A256KW" o Algorithm Name: "ECDH-ES+A256KW"
o Algorithm Description: ECDH-ES using Concat KDF and "A256KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128GCMKW" o Algorithm Name: "A128GCMKW"
o Algorithm Description: Key wrapping with AES GCM using 128 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.7 of [[ this document ]]
o Algorithm Name: "A192GCMKW" o Algorithm Name: "A192GCMKW"
o Algorithm Description: Key wrapping with AES GCM using 192 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.7 of [[ this document ]]
o Algorithm Name: "A256GCMKW" o Algorithm Name: "A256GCMKW"
o Algorithm Description: Key wrapping with AES GCM using 256 bit key
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.7 of [[ this document ]]
o Algorithm Name: "PBES2-HS256+A128KW" o Algorithm Name: "PBES2-HS256+A128KW"
o Algorithm Description: PBES2 with HMAC SHA-256 and "A128KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "PBES2-HS384+A192KW" o Algorithm Name: "PBES2-HS384+A192KW"
o Algorithm Description: PBES2 with HMAC SHA-384 and "A192KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "PBES2-HS512+A256KW" o Algorithm Name: "PBES2-HS512+A256KW"
o Algorithm Description: PBES2 with HMAC SHA-512 and "A256KW"
wrapping
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "A128CBC-HS256" o Algorithm Name: "A128CBC-HS256"
o Algorithm Description: AES_128_CBC_HMAC_SHA_256 authenticated
encryption algorithm
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
o Algorithm Name: "A192CBC-HS384" o Algorithm Name: "A192CBC-HS384"
o Algorithm Description: AES_192_CBC_HMAC_SHA_384 authenticated
encryption algorithm
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
o Algorithm Name: "A256CBC-HS512" o Algorithm Name: "A256CBC-HS512"
o Algorithm Description: AES_256_CBC_HMAC_SHA_512 authenticated
encryption algorithm
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
o Algorithm Name: "A128GCM" o Algorithm Name: "A128GCM"
o Algorithm Description: AES GCM using 128 bit key
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
o Algorithm Name: "A192GCM" o Algorithm Name: "A192GCM"
o Algorithm Description: AES GCM using 192 bit key
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
o Algorithm Name: "A256GCM" o Algorithm Name: "A256GCM"
o Algorithm Description: AES GCM using 256 bit key
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 5.1 of [[ this document ]]
6.2. JWE Header Parameter Names Registration 7.2. JWE Header Parameter Names Registration
This specification registers the Header Parameter names defined in This specification registers the Header Parameter names defined in
Section 4.7.1, Section 4.8.1, and Section 4.9.1 in the IANA JSON Web Section 4.6.1, Section 4.7.1, and Section 4.8.1 in the IANA JSON Web
Signature and Encryption Header Parameters registry defined in [JWS]. Signature and Encryption Header Parameters registry defined in [JWS].
6.2.1. Registry Contents 7.2.1. Registry Contents
o Header Parameter Name: "epk" o Header Parameter Name: "epk"
o Header Parameter Description: Ephemeral Public Key
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.7.1.1 of [[ this document ]] o Specification Document(s): Section 4.6.1.1 of [[ this document ]]
o Header Parameter Name: "apu" o Header Parameter Name: "apu"
o Header Parameter Description: Agreement PartyUInfo
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.7.1.2 of [[ this document ]] o Specification Document(s): Section 4.6.1.2 of [[ this document ]]
o Header Parameter Name: "apv" o Header Parameter Name: "apv"
o Header Parameter Description: Agreement PartyVInfo
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.7.1.3 of [[ this document ]] o Specification Document(s): Section 4.6.1.3 of [[ this document ]]
o Header Parameter Name: "iv" o Header Parameter Name: "iv"
o Header Parameter Description: Initialization Vector
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.8.1.1 of [[ this document ]] o Specification Document(s): Section 4.7.1.1 of [[ this document ]]
o Header Parameter Name: "tag" o Header Parameter Name: "tag"
o Header Parameter Description: Authentication Tag
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.8.1.2 of [[ this document ]] o Specification Document(s): Section 4.7.1.2 of [[ this document ]]
o Header Parameter Name: "p2s" o Header Parameter Name: "p2s"
o Header Parameter Description: PBES2 salt
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.9.1.1 of [[ this document ]] o Specification Document(s): Section 4.8.1.1 of [[ this document ]]
o Header Parameter Name: "p2c" o Header Parameter Name: "p2c"
o Header Parameter Description: PBES2 count
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.9.1.2 of [[ this document ]] o Specification Document(s): Section 4.8.1.2 of [[ this document ]]
6.3. JSON Web Encryption Compression Algorithms Registry 7.3. JSON Web Encryption Compression Algorithms Registry
This specification establishes the IANA JSON Web Encryption This specification establishes the IANA JSON Web Encryption
Compression Algorithms registry for JWE "zip" member values. The Compression Algorithms registry for JWE "zip" member values. The
registry records the compression algorithm value and a reference to registry records the compression algorithm value and a reference to
the specification that defines it. the specification that defines it.
6.3.1. Registration Template 7.3.1. Registration Template
Compression Algorithm Value: Compression Algorithm Value:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a case-sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that case-insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
Compression Algorithm Description:
Brief description of the compression algorithm (e.g., "Example
description").
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.3.2. Initial Registry Contents 7.3.2. Initial Registry Contents
o Compression Algorithm Value: "DEF" o Compression Algorithm Value: "DEF"
o Compression Algorithm Description: DEFLATE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): JSON Web Encryption (JWE) [JWE] o Specification Document(s): JSON Web Encryption (JWE) [JWE]
6.4. JSON Web Key Types Registry 7.4. JSON Web Key Types Registry
This specification establishes the IANA JSON Web Key Types registry This specification establishes the IANA JSON Web Key Types registry
for values of the JWK "kty" (key type) parameter. The registry for values of the JWK "kty" (key type) parameter. The registry
records the "kty" value, implementation requirements, and a reference records the "kty" value, implementation requirements, and a reference
to the specification that defines it. to the specification that defines it.
The implementation requirements of a key type MAY be changed over The implementation requirements of a key type MAY be changed over
time by the Designated Experts(s) as the cryptographic landscape time by the Designated Experts(s) as the cryptographic landscape
evolves, for instance, to change the status of a key type to 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 Deprecated, or to change the status of a key type from Optional to
Recommended+ or Required. Changes of implementation requirements are Recommended+ or Required. Changes of implementation requirements are
only permitted on a Specification Required basis, with the new only permitted on a Specification Required basis, with the new
specification defining the revised implementation requirements level. specification defining the revised implementation requirements level.
6.4.1. Registration Template 7.4.1. Registration Template
"kty" Parameter Value: "kty" Parameter Value:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a case-sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that case-insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
Key Type Description:
Brief description of the Key Type (e.g., "Example description").
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Implementation Requirements: Implementation Requirements:
The key type implementation requirements, which must be one the The key type implementation requirements, which must be one the
words Required, Recommended, Optional, or Deprecated. Optionally, words Required, Recommended, Optional, or Deprecated. Optionally,
the word can be followed by a "+" or "-". The use of "+" the word can be followed by a "+" or "-". The use of "+"
indicates that the requirement strength is likely to be increased indicates that the requirement strength is likely to be increased
in a future version of the specification. The use of "-" in a future version of the specification. The use of "-"
indicates that the requirement strength is likely to be decreased indicates that the requirement strength is likely to be decreased
in a future version of the specification. in a future version of the specification.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.4.2. Initial Registry Contents 7.4.2. Initial Registry Contents
This specification registers the values defined in Section 5.1. This specification registers the values defined in Section 6.1.
o "kty" Parameter Value: "EC" o "kty" Parameter Value: "EC"
o Key Type Description: Elliptic Curve
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2 of [[ this document ]] o Specification Document(s): Section 6.2 of [[ this document ]]
o "kty" Parameter Value: "RSA" o "kty" Parameter Value: "RSA"
o Key Type Description: RSA
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3 of [[ this document ]] o Specification Document(s): Section 6.3 of [[ this document ]]
o "kty" Parameter Value: "oct" o "kty" Parameter Value: "oct"
o Key Type Description: Octet sequence
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.4 of [[ this document ]] o Specification Document(s): Section 6.4 of [[ this document ]]
6.5. JSON Web Key Parameters Registration 7.5. JSON Web Key Parameters Registration
This specification registers the parameter names defined in Sections This specification registers the parameter names defined in Sections
5.2, 5.3, and 5.4 in the IANA JSON Web Key Parameters registry 6.2, 6.3, and 6.4 in the IANA JSON Web Key Parameters registry
defined in [JWK]. defined in [JWK].
6.5.1. Registry Contents 7.5.1. Registry Contents
o Parameter Name: "crv" o Parameter Name: "crv"
o Parameter Description: Curve
o Used with "kty" Value(s): "EC" o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
o Parameter Name: "x" o Parameter Name: "x"
o Parameter Description: X Coordinate
o Used with "kty" Value(s): "EC" o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.2 of [[ this document ]] o Specification Document(s): Section 6.2.1.2 of [[ this document ]]
o Parameter Name: "y" o Parameter Name: "y"
o Parameter Description: Y Coordinate
o Used with "kty" Value(s): "EC" o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.3 of [[ this document ]] o Specification Document(s): Section 6.2.1.3 of [[ this document ]]
o Parameter Name: "d" o Parameter Name: "d"
o Parameter Description: ECC Private Key
o Used with "kty" Value(s): "EC" o Used with "kty" Value(s): "EC"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.2.1 of [[ this document ]] o Specification Document(s): Section 6.2.2.1 of [[ this document ]]
o Parameter Name: "n" o Parameter Name: "n"
o Parameter Description: Modulus
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.1.1 of [[ this document ]] o Specification Document(s): Section 6.3.1.1 of [[ this document ]]
o Parameter Name: "e" o Parameter Name: "e"
o Parameter Description: Exponent
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.1.2 of [[ this document ]] o Specification Document(s): Section 6.3.1.2 of [[ this document ]]
o Parameter Name: "d" o Parameter Name: "d"
o Parameter Description: Private Exponent
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.1 of [[ this document ]] o Specification Document(s): Section 6.3.2.1 of [[ this document ]]
o Parameter Name: "p" o Parameter Name: "p"
o Parameter Description: First Prime Factor
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.2 of [[ this document ]] o Specification Document(s): Section 6.3.2.2 of [[ this document ]]
o Parameter Name: "q" o Parameter Name: "q"
o Parameter Description: Second Prime Factor
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.3 of [[ this document ]] o Specification Document(s): Section 6.3.2.3 of [[ this document ]]
o Parameter Name: "dp" o Parameter Name: "dp"
o Parameter Description: First Factor CRT Exponent
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.4 of [[ this document ]] o Specification Document(s): Section 6.3.2.4 of [[ this document ]]
o Parameter Name: "dq" o Parameter Name: "dq"
o Parameter Description: Second Factor CRT Exponent
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.5 of [[ this document ]] o Specification Document(s): Section 6.3.2.5 of [[ this document ]]
o Parameter Name: "qi" o Parameter Name: "qi"
o Parameter Description: First CRT Coefficient
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.6 of [[ this document ]] o Specification Document(s): Section 6.3.2.6 of [[ this document ]]
o Parameter Name: "oth" o Parameter Name: "oth"
o Parameter Description: Other Primes Info
o Used with "kty" Value(s): "RSA" o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.3.2.7 of [[ this document ]] o Specification Document(s): Section 6.3.2.7 of [[ this document ]]
o Parameter Name: "k" o Parameter Name: "k"
o Parameter Description: Key Value
o Used with "kty" Value(s): "oct" o Used with "kty" Value(s): "oct"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.4.1 of [[ this document ]] o Specification Document(s): Section 6.4.1 of [[ this document ]]
6.6. JSON Web Key Elliptic Curve Registry 7.6. JSON Web Key Elliptic Curve Registry
This specification establishes the IANA JSON Web Key Elliptic Curve This specification establishes the IANA JSON Web Key Elliptic Curve
registry for JWK "crv" member values. The registry records the curve registry for JWK "crv" member values. The registry records the curve
name, implementation requirements, and a reference to the name, implementation requirements, and a reference to the
specification that defines it. This specification registers the specification that defines it. This specification registers the
parameter names defined in Section 5.2.1.1. parameter names defined in Section 6.2.1.1.
The implementation requirements of a curve MAY be changed over time The implementation requirements of a curve MAY be changed over time
by the Designated Experts(s) as the cryptographic landscape evolves, by the Designated Experts(s) as the cryptographic landscape evolves,
for instance, to change the status of a curve to Deprecated, or to for instance, to change the status of a curve to Deprecated, or to
change the status of a curve from Optional to Recommended+ or change the status of a curve from Optional to Recommended+ or
Required. Changes of implementation requirements are only permitted Required. Changes of implementation requirements are only permitted
on a Specification Required basis, with the new specification on a Specification Required basis, with the new specification
defining the revised implementation requirements level. defining the revised implementation requirements level.
6.6.1. Registration Template 7.6.1. Registration Template
Curve Name: Curve Name:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a case-sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that case-insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
Curve Description:
Brief description of the curve (e.g., "Example description").
Implementation Requirements: Implementation Requirements:
The curve implementation requirements, which must be one the words The curve implementation requirements, which must be one the words
Required, Recommended, Optional, or Deprecated. Optionally, the Required, Recommended, Optional, or Deprecated. Optionally, the
word can be followed by a "+" or "-". The use of "+" indicates word can be followed by a "+" or "-". The use of "+" indicates
that the requirement strength is likely to be increased in a that the requirement strength is likely to be increased in a
future version of the specification. The use of "-" indicates future version of the specification. The use of "-" indicates
that the requirement strength is likely to be decreased in a that the requirement strength is likely to be decreased in a
future version of the specification. future version of the specification.
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.6.2. Initial Registry Contents 7.6.2. Initial Registry Contents
o Curve Name: "P-256" o Curve Name: "P-256"
o Curve Description: P-256 curve
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
o Curve Name: "P-384" o Curve Name: "P-384"
o Curve Description: P-384 curve
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
o Curve Name: "P-521" o Curve Name: "P-521"
o Curve Description: P-521 curve
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
7. Security Considerations 8. Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient. The entire list of encrypting a message for the wrong recipient. The entire list of
security considerations is beyond the scope of this document, but security considerations is beyond the scope of this document, but
some significant considerations are listed here. some significant considerations are listed here.
The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], The security considerations in [AES], [DSS], [JWE], [JWK], [JWS],
[NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394], [NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394],
[RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this
specification. specification.
Algorithms of matching strengths should be used together whenever Algorithms of matching strengths should be used together whenever
possible. For instance, when AES Key Wrap is used with a given key possible. For instance, when AES Key Wrap is used with a given key
size, using the same key size is recommended when AES GCM is also size, using the same key size is recommended when AES GCM is also
used. used.
7.1. Algorithms and Key Sizes will be Deprecated 8.1. Algorithms and Key Sizes will be Deprecated
Eventually the algorithms and/or key sizes currently described in Eventually the algorithms and/or key sizes currently described in
this specification will no longer be considered sufficiently secure this specification will no longer be considered sufficiently secure
and will be removed. Therefore, implementers and deployments must be and will be deprecated. Therefore, implementers and deployments must
prepared for this eventuality. be prepared for this eventuality.
7.2. Key Lifetimes 8.2. Key Lifetimes
Many algorithms have associated security considerations related to Many algorithms have associated security considerations related to
key lifetimes and/or the number of times that a key may be used. key lifetimes and/or the number of times that a key may be used.
Those security considerations continue to apply when using those Those security considerations continue to apply when using those
algorithms with JOSE data structures. algorithms with JOSE data structures.
7.3. RSAES-PKCS1-v1_5 Security Considerations 8.3. RSAES-PKCS1-v1_5 Security Considerations
While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
to adopt RSASSA-PKCS-v1_5 for new applications and instead requests to adopt RSASSA-PKCS-v1_5 for new applications and instead requests
that people transition to RSASSA-PSS, this specification does include that people transition to RSASSA-PSS, this specification does include
RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly
implemented. implemented.
Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Keys used with RSAES-PKCS1-v1_5 must follow the constraints in
Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low
public key exponent value must not be used. public key exponent value must not be used.
7.4. AES GCM Security Considerations 8.4. AES GCM Security Considerations
Keys used with AES GCM must follow the constraints in Section 8.3 of 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 [NIST.800-38D], which states: "The total number of invocations of the
authenticated encryption function shall not exceed 2^32, including authenticated encryption function shall not exceed 2^32, including
all IV lengths and all instances of the authenticated encryption all IV lengths and all instances of the authenticated encryption
function with the given key". In accordance with this rule, AES GCM 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. MUST NOT be used with the same key value more than 2^32 times.
An Initialization Vector value MUST never be used multiple times with An Initialization Vector value MUST never be used multiple times with
the same AES GCM key. One way to prevent this is to store a counter 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 with the key and increment it with every use. The counter can also
be used to prevent exceeding the 2^32 limit above. be used to prevent exceeding the 2^32 limit above.
This security consideration does not apply to the composite AES-CBC This security consideration does not apply to the composite AES-CBC
HMAC SHA-2 or AES Key Wrap algorithms. HMAC SHA-2 or AES Key Wrap algorithms.
7.5. Plaintext JWS Security Considerations 8.5. Plaintext JWS Security Considerations
Plaintext JWSs (JWSs that use the "alg" value "none") provide no Plaintext JWSs (JWSs that use the "alg" value "none") provide no
integrity protection. Thus, they must only be used in contexts where integrity protection. Thus, they must only be used in contexts where
the payload is secured by means other than a digital signature or MAC the payload is secured by means other than a digital signature or MAC
value, or need not be secured. value, or need not be secured.
Implementations that support plaintext JWS objects MUST NOT accept Implementations that support plaintext JWS objects MUST NOT accept
such objects as valid unless the application specifies that it is such objects as valid unless the application specifies that it is
acceptable for a specific object to not be integrity-protected. acceptable for a specific object to not be integrity-protected.
Implementations MUST NOT accept plaintext JWS objects by default. Implementations MUST NOT accept plaintext JWS objects by default.
skipping to change at page 48, line 24 skipping to change at page 47, line 9
HTTPS with client authentication. It requires a JWS signature on HTTPS with client authentication. It requires a JWS signature on
objects received over HTTP, but accepts plaintext JWS objects over objects received over HTTP, but accepts plaintext JWS objects over
HTTPS. If the application were to globally indicate that "none" is HTTPS. If the application were to globally indicate that "none" is
acceptable, then an attacker could provide it with an unsigned object acceptable, then an attacker could provide it with an unsigned object
over HTTP and still have that object successfully validate. Instead, over HTTP and still have that object successfully validate. Instead,
the application needs to indicate acceptance of "none" for each the application needs to indicate acceptance of "none" for each
object received over HTTPS (e.g., by setting "acceptUnsigned" to object received over HTTPS (e.g., by setting "acceptUnsigned" to
"true" for the first hypothetical JWS software library above), but "true" for the first hypothetical JWS software library above), but
not for each object received over HTTP. not for each object received over HTTP.
7.6. Denial of Service Attacks 8.6. Differences between Digital Signatures and MACs
While in many cases, MACs and digital signatures can be used for
integrity checking, there are some significant differences between
the security properties that each of them provides. These need to be
taken into consideration when designing protocols and selecting the
algorithms to be used in protocols.
Both signatures and MACs provide for integrity checking -- verifying
that the message has not been modified since the integrity value was
computed. However, MACs provide for origination identification only
under specific circumstances. It can normally be assumed that a
private key used for a signature is only in the hands of a single
entity (although perhaps a distributed entity, in the case of
replicated servers), however a MAC key needs to be in the hands of
all the entities that use it for integrity computation and checking.
This means that origination can only be determined if a MAC key is
known only to two entities and the receiver knows that it did not
create the message. MAC validation cannot be used to prove
origination to a third party.
8.7. Denial of Service Attacks
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
send certificates with keys that would result in excessive send certificates with keys that would result in excessive
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
7.7. Reusing Key Material when Encrypting Keys 8.8. Reusing Key Material when Encrypting Keys
It is NOT RECOMMENDED to reuse the same key material (Key Encryption It is NOT RECOMMENDED to reuse the same key material (Key Encryption
Key, Content Encryption Key, Initialization Vector, etc.) to encrypt Key, Content Encryption Key, Initialization Vector, etc.) to encrypt
multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK
Set object multiple times. One suggestion for preventing re-use is Set object multiple times. One suggestion for preventing re-use is
to always generate a new set key material for each encryption to always generate a new set key material for each encryption
operation, based on the considerations noted in this document as well operation, based on the considerations noted in this document as well
as from [RFC4086]. as from [RFC4086].
7.8. Password Considerations 8.9. Password Considerations
While convenient for end users, passwords are vulnerable to a number Passwords are vulnerable to a number of attacks. To help mitigate
of attacks. To help mitigate some of these limitations, this some of these limitations, this document applies principles from
document applies principles from [RFC2898] to derive cryptographic [RFC2898] to derive cryptographic keys from user-supplied passwords.
keys from user-supplied passwords.
However, the strength of the password still has a significant impact. However, the strength of the password still has a significant impact.
A high-entry password has greater resistance to dictionary attacks. A high-entropy password has greater resistance to dictionary attacks.
[NIST-800-63-1] contains guidelines for estimating password entropy, [NIST-800-63-1] contains guidelines for estimating password entropy,
which can help applications and users generate stronger passwords. which can help applications and users generate stronger passwords.
An ideal password is one that is as large (or larger) than the An ideal password is one that is as large as (or larger than) the
derived key length but less than the PRF's block size. Passwords derived key length. However, passwords larger than a certain
larger than the PRF's block size are first hashed, which reduces an algorithm-specific size are first hashed, which reduces an attacker's
attacker's effective search space to the length of the hash algorithm effective search space to the length of the hash algorithm. It is
(32 octets for HMAC SHA-256). It is RECOMMENDED that the password be RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no
no longer than 64 octets long for "PBES2-HS512+A256KW". 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.
Still, care needs to be taken in where and how password-based Still, care needs to be taken in where and how password-based
encryption is used. Such algorithms MUST NOT be used where the encryption is used. These algorithms can still be susceptible to
attacker can make an indefinite number of attempts to circumvent the dictionary-based attacks if the iteration count is too small; this is
protection. 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.
8. Internationalization Considerations 9. Internationalization Considerations
Passwords obtained from users are likely to require preparation and Passwords obtained from users are likely to require preparation and
normalization to account for differences of octet sequences generated normalization to account for differences of octet sequences generated
by different input devices, locales, etc. It is RECOMMENDED that by different input devices, locales, etc. It is RECOMMENDED that
applications to perform the steps outlined in applications to perform the steps outlined in
[I-D.melnikov-precis-saslprepbis] to prepare a password supplied [I-D.melnikov-precis-saslprepbis] to prepare a password supplied
directly by a user before performing key derivation and encryption. directly by a user before performing key derivation and encryption.
9. References 10. References
9.1. Normative References 10.1. Normative References
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197, "Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001. November 2001.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4, July 2013. Signature Standard (DSS)", FIPS PUB 186-4, July 2013.
[I-D.melnikov-precis-saslprepbis] [I-D.melnikov-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation and Saint-Andre, P. and A. Melnikov, "Preparation and
Comparison of Internationalized Strings Representing Comparison of Internationalized Strings Representing
Simple User Names and Passwords", Simple User Names and Passwords",
draft-melnikov-precis-saslprepbis-04 (work in progress), draft-melnikov-precis-saslprepbis-04 (work in progress),
September 2012. September 2012.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption Encryption (JWE)", draft-ietf-jose-json-web-encryption
(work in progress), October 2013. (work in progress), November 2013.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
October 2013. November 2013.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), October 2013. in progress), November 2013.
[NIST.800-38A] [NIST.800-38A]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", "Recommendation for Block Cipher Modes of Operation",
NIST PUB 800-38A, December 2001. NIST PUB 800-38A, December 2001.
[NIST.800-38D] [NIST.800-38D]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
skipping to change at page 51, line 31 skipping to change at page 50, line 37
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009. Elliptic Curve Cryptography", May 2009.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-3, October 2008. Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
9.2. Informative References 10.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[I-D.mcgrew-aead-aes-cbc-hmac-sha2] [I-D.mcgrew-aead-aes-cbc-hmac-sha2]
McGrew, D., Foley, J., and K. Paterson, "Authenticated McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", Encryption with AES-CBC and HMAC-SHA",
draft-mcgrew-aead-aes-cbc-hmac-sha2-02 (work in progress), draft-mcgrew-aead-aes-cbc-hmac-sha2-02 (work in progress),
July 2013. July 2013.
skipping to change at page 53, line 5 skipping to change at page 52, line 9
Wide Web Consortium CR CR-xmlenc-core1-20120313, Wide Web Consortium CR CR-xmlenc-core1-20120313,
March 2012, March 2012,
<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
[W3C.REC-xmlenc-core-20021210] [W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML Encryption Syntax and Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", World Wide Web Consortium Recommendation REC- Processing", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, December 2002, xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>. <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
Appendix A. Digital Signature/MAC Algorithm Identifier Cross-Reference Appendix A. Algorithm Identifier Cross-Reference
This appendix contains a table cross-referencing the digital This appendix contains tables cross-referencing the cryptographic
signature and MAC "alg" (algorithm) values used in this specification algorithm identifier values defined in this specification with the
with the equivalent identifiers used by other standards and software equivalent identifiers used by other standards and software packages.
packages. See XML DSIG [RFC3275], XML DSIG 2.0 See XML DSIG [RFC3275], XML DSIG 2.0 [W3C.CR-xmldsig-core2-20120124],
[W3C.CR-xmldsig-core2-20120124], and Java Cryptography Architecture XML Encryption [W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture
[JCA] for more information about the names defined by those [JCA] for more information about the names defined by those
documents. documents.
+-----+---------------------------------+-----------+---------------+ A.1. Digital Signature/MAC Algorithm Identifier Cross-Reference
| JWS | XML DSIG | JCA | OID |
+-----+---------------------------------+-----------+---------------+
| HS2 | http://www.w3.org/2001/04/xmlds | HmacSHA25 | 1.2.840.11354 |
| 56 | ig-more#hmac-sha256 | 6 | 9.2.9 |
| HS3 | http://www.w3.org/2001/04/xmlds | HmacSHA38 | 1.2.840.11354 |
| 84 | ig-more#hmac-sha384 | 4 | 9.2.10 |
| HS5 | http://www.w3.org/2001/04/xmlds | HmacSHA51 | 1.2.840.11354 |
| 12 | ig-more#hmac-sha512 | 2 | 9.2.11 |
| RS2 | http://www.w3.org/2001/04/xmlds | SHA256wit | 1.2.840.11354 |
| 56 | ig-more#rsa-sha256 | hRSA | 9.1.1.11 |
| RS3 | http://www.w3.org/2001/04/xmlds | SHA384wit | 1.2.840.11354 |
| 84 | ig-more#rsa-sha384 | hRSA | 9.1.1.12 |
| RS5 | http://www.w3.org/2001/04/xmlds | SHA512wit | 1.2.840.11354 |
| 12 | ig-more#rsa-sha512 | hRSA | 9.1.1.13 |
| ES2 | http://www.w3.org/2001/04/xmlds | SHA256wit | 1.2.840.10045 |
| 56 | ig-more#ecdsa-sha256 | hECDSA | .4.3.2 |
| ES3 | http://www.w3.org/2001/04/xmlds | SHA384wit | 1.2.840.10045 |
| 84 | ig-more#ecdsa-sha384 | hECDSA | .4.3.3 |
| ES5 | http://www.w3.org/2001/04/xmlds | SHA512wit | 1.2.840.10045 |
| 12 | ig-more#ecdsa-sha512 | hECDSA | .4.3.4 |
| PS2 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| 56 | ig-more#sha256-rsa-MGF1 | | 9.1.1.10 |
| PS3 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| 84 | ig-more#sha384-rsa-MGF1 | | 9.1.1.10 |
| PS5 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| 12 | ig-more#sha512-rsa-MGF1 | | 9.1.1.10 |
+-----+---------------------------------+-----------+---------------+
Appendix B. Encryption Algorithm Identifier Cross-Reference
This appendix contains a table cross-referencing the "alg" This section contains a table cross-referencing the JWS digital
(algorithm) and "enc" (encryption method) values used in this signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards specification with the equivalent identifiers used by other standards
and software packages. See XML Encryption and software packages.
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture
[JCA] for more information about the names defined by those +-----+-------------------------------+--------------+--------------+
documents. | JWS | XML DSIG | JCA | OID |
+-----+-------------------------------+--------------+--------------+
| HS2 | http://www.w3.org/2001/04/xml | HmacSHA256 | 1.2.840.1135 |
| 56 | dsig-more#hmac-sha256 | | 49.2.9 |
| HS3 | http://www.w3.org/2001/04/xml | HmacSHA384 | 1.2.840.1135 |
| 84 | dsig-more#hmac-sha384 | | 49.2.10 |
| HS5 | http://www.w3.org/2001/04/xml | HmacSHA512 | 1.2.840.1135 |
| 12 | dsig-more#hmac-sha512 | | 49.2.11 |
| RS2 | http://www.w3.org/2001/04/xml | SHA256withRS | 1.2.840.1135 |
| 56 | dsig-more#rsa-sha256 | A | 49.1.1.11 |
| RS3 | http://www.w3.org/2001/04/xml | SHA384withRS | 1.2.840.1135 |
| 84 | dsig-more#rsa-sha384 | A | 49.1.1.12 |
| RS5 | http://www.w3.org/2001/04/xml | SHA512withRS | 1.2.840.1135 |
| 12 | dsig-more#rsa-sha512 | A | 49.1.1.13 |
| ES2 | http://www.w3.org/2001/04/xml | SHA256withEC | 1.2.840.1004 |
| 56 | dsig-more#ecdsa-sha256 | DSA | 5.4.3.2 |
| ES3 | http://www.w3.org/2001/04/xml | SHA384withEC | 1.2.840.1004 |
| 84 | dsig-more#ecdsa-sha384 | DSA | 5.4.3.3 |
| ES5 | http://www.w3.org/2001/04/xml | SHA512withEC | 1.2.840.1004 |
| 12 | dsig-more#ecdsa-sha512 | DSA | 5.4.3.4 |
| PS2 | http://www.w3.org/2007/05/xml | SHA256withRS | 1.2.840.1135 |
| 56 | dsig-more#sha256-rsa-MGF1 | AandMGF1 | 49.1.1.10 |
| PS3 | http://www.w3.org/2007/05/xml | SHA384withRS | 1.2.840.1135 |
| 84 | dsig-more#sha384-rsa-MGF1 | AandMGF1 | 49.1.1.10 |
| PS5 | http://www.w3.org/2007/05/xml | SHA512withRS | 1.2.840.1135 |
| 12 | dsig-more#sha512-rsa-MGF1 | AandMGF1 | 49.1.1.10 |
+-----+-------------------------------+--------------+--------------+
A.2. Key Management Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
identifiers used by other standards and software packages.
+------+------------------------+--------------------+--------------+
| JWE | XML ENC | JCA | OID |
+------+------------------------+--------------------+--------------+
| RSA1 | http://www.w3.org/2001 | RSA/ECB/PKCS1Paddi | 1.2.840.1135 |
| _5 | /04/xmlenc#rsa-1_5 | ng | 49.1.1.1 |
| RSA- | http://www.w3.org/2001 | RSA/ECB/OAEPWithSH | 1.2.840.1135 |
| OAEP | /04/xmlenc#rsa-oaep-mg | A-1AndMGF1Padding | 49.1.1.7 |
| | f1p | | |
| ECDH | http://www.w3.org/2009 | | 1.3.132.1.12 |
| -ES | /xmlenc11#ECDH-ES | | |
| A128 | http://www.w3.org/2001 | | 2.16.840.1.1 |
| KW | /04/xmlenc#kw-aes128 | | 01.3.4.1.5 |
| A192 | http://www.w3.org/2001 | | 2.16.840.1.1 |
| KW | /04/xmlenc#kw-aes192 | | 01.3.4.1.25 |
| A256 | http://www.w3.org/2001 | | 2.16.840.1.1 |
| KW | /04/xmlenc#kw-aes256 | | 01.3.4.1.45 |
+------+------------------------+--------------------+--------------+
A.3. Content Encryption Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "enc"
(encryption method) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and
"A256CBC-HS512", the corresponding AES CBC algorithm identifiers are "A256CBC-HS512", the corresponding AES CBC algorithm identifiers are
listed. listed.
+--------+-----------------------+-------------------+--------------+ +---------+-------------------------+--------------+----------------+
| JWE | XML ENC | JCA | OID | | JWE | XML ENC | JCA | OID |
+--------+-----------------------+-------------------+--------------+ +---------+-------------------------+--------------+----------------+
| RSA1_5 | http://www.w3.org/200 | RSA/ECB/PKCS1Padd | 1.2.840.1135 | | A128CBC | http://www.w3.org/2001/ | AES/CBC/PKCS | 2.16.840.1.101 |
| | 1/04/xmlenc#rsa-1_5 | ing | 49.1.1.1 | | -HS256 | 04/xmlenc#aes128-cbc | 5Padding | .3.4.1.2 |
| RSA-OA | http://www.w3.org/200 | RSA/ECB/OAEPWithS | 1.2.840.1135 | | A192CBC | http://www.w3.org/2001/ | AES/CBC/PKCS | 2.16.840.1.101 |
| EP | 1/04/xmlenc#rsa-oaep- | HA-1AndMGF1Paddin | 49.1.1.7 | | -HS384 | 04/xmlenc#aes192-cbc | 5Padding | .3.4.1.22 |
| | mgf1p | g | | | A256CBC | http://www.w3.org/2001/ | AES/CBC/PKCS | 2.16.840.1.101 |
| ECDH-E | http://www.w3.org/200 | | 1.3.132.1.12 | | -HS512 | 04/xmlenc#aes256-cbc | 5Padding | .3.4.1.42 |
| S | 9/xmlenc11#ECDH-ES | | | | A128GCM | http://www.w3.org/2009/ | AES/GCM/NoPa | 2.16.840.1.101 |
| A128KW | http://www.w3.org/200 | | 2.16.840.1.1 | | | xmlenc11#aes128-gcm | dding | .3.4.1.6 |
| | 1/04/xmlenc#kw-aes128 | | 01.3.4.1.5 | | A192GCM | http://www.w3.org/2009/ | AES/GCM/NoPa | 2.16.840.1.101 |
| A192KW | http://www.w3.org/200 | | 2.16.840.1.1 | | | xmlenc11#aes192-gcm | dding | .3.4.1.26 |
| | 1/04/xmlenc#kw-aes192 | | 01.3.4.1.25 | | A256GCM | http://www.w3.org/2009/ | AES/GCM/NoPa | 2.16.840.1.101 |
| A256KW | http://www.w3.org/200 | | 2.16.840.1.1 | | | xmlenc11#aes256-gcm | dding | .3.4.1.46 |
| | 1/04/xmlenc#kw-aes256 | | 01.3.4.1.45 | +---------+-------------------------+--------------+----------------+
| A128CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| C-HS25 | 1/04/xmlenc#aes128-cb | ing | 01.3.4.1.2 |
| 6 | c | | |
| A192CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| C-HS38 | 1/04/xmlenc#aes192-cb | ing | 01.3.4.1.22 |
| 4 | c | | |
| A256CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| C-HS51 | 1/04/xmlenc#aes256-cb | ing | 01.3.4.1.42 |
| 2 | c | | |
| A128GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| M | 9/xmlenc11#aes128-gcm | | 01.3.4.1.6 |
| A192GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| M | 9/xmlenc11#aes192-gcm | | 01.3.4.1.26 |
| A256GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| M | 9/xmlenc11#aes256-gcm | | 01.3.4.1.46 |
+--------+-----------------------+-------------------+--------------+
Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 4.10. They are 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 also intended to correspond to test cases that may appear in a future
version of [I-D.mcgrew-aead-aes-cbc-hmac-sha2], demonstrating that version of [I-D.mcgrew-aead-aes-cbc-hmac-sha2], demonstrating that
the cryptographic computations performed are the same. the cryptographic computations performed are the same.
The variable names are those defined in Section 4.10. All values are The variable names are those defined in Section 5.2. All values are
hexadecimal. hexadecimal.
C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256
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 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 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
skipping to change at page 56, line 5 skipping to change at page 56, line 5
6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 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 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 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 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 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 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
C.2. Test Cases for AES_192_CBC_HMAC_SHA_384 B.2. Test Cases for AES_192_CBC_HMAC_SHA_384
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 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 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 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 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 10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 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 28 29 2a 2b 2c 2d 2e 2f
skipping to change at page 57, line 5 skipping to change at page 57, line 5
c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 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 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
M = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 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 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 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 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 75 16 80 39 cc c7 33 d7
C.3. Test Cases for AES_256_CBC_HMAC_SHA_512 B.3. Test Cases for AES_256_CBC_HMAC_SHA_512
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 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 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 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 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 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 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
skipping to change at page 58, line 5 skipping to change at page 58, line 5
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
M = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 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 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 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 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 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 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
Appendix D. Example ECDH-ES Key Agreement Computation Appendix C. Example ECDH-ES Key Agreement Computation
This example uses ECDH-ES Key Agreement and the Concat KDF to derive This example uses ECDH-ES Key Agreement and the Concat KDF to derive
the Content Encryption Key (CEK) in the manner described in the Content Encryption Key (CEK) in the manner described in
Section 4.7. In this example, the ECDH-ES Direct Key Agreement mode 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 ("alg" value "ECDH-ES") is used to produce an agreed upon key for AES
GCM with 128 bit keys ("enc" value "A128GCM"). GCM with a 128 bit key ("enc" value "A128GCM").
In this example, a sender Alice is encrypting content to a recipient In this example, a sender Alice is encrypting content to a recipient
Bob. The sender (Alice) generates an ephemeral key for the key Bob. The sender (Alice) generates an ephemeral key for the key
agreement computation. Alice's ephemeral key (in JWK format) used agreement computation. Alice's ephemeral key (in JWK format) used
for the key agreement computation in this example (including the for the key agreement computation in this example (including the
private part) is: private part) is:
{"kty":"EC", {"kty":"EC",
"crv":"P-256", "crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
skipping to change at page 60, line 26 skipping to change at page 60, line 26
The resulting derived key, which is the first 128 bits of the round 1 The resulting derived key, which is the first 128 bits of the round 1
hash output is: hash output is:
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16, [86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26] 26]
The base64url encoded representation of this derived key is: The base64url encoded representation of this derived key is:
VqqN6vgjbSBcIijNcacQGg VqqN6vgjbSBcIijNcacQGg
Appendix E. Acknowledgements Appendix D. Acknowledgements
Solutions for signing and encrypting JSON content were previously Solutions for signing and encrypting JSON content were previously
explored by Magic Signatures [MagicSignatures], JSON Simple Sign explored by Magic Signatures [MagicSignatures], JSON Simple Sign
[JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE], [JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE],
and JavaScript Message Security Format [I-D.rescorla-jsms], all of and JavaScript Message Security Format [I-D.rescorla-jsms], all of
which influenced this draft. which influenced this draft.
The Authenticated Encryption with AES-CBC and HMAC-SHA The Authenticated Encryption with AES-CBC and HMAC-SHA
[I-D.mcgrew-aead-aes-cbc-hmac-sha2] specification, upon which the [I-D.mcgrew-aead-aes-cbc-hmac-sha2] specification, upon which the
AES_CBC_HMAC_SHA2 algorithms are based, was written by David A. AES_CBC_HMAC_SHA2 algorithms are based, was written by David A.
skipping to change at page 61, line 4 skipping to change at page 61, line 4
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects Encryption (JWE) for Protecting JSON Web Key (JWK) Objects
[I-D.miller-jose-jwe-protected-jwk], which the password-based [I-D.miller-jose-jwe-protected-jwk], which the password-based
encryption content of this draft is based upon. encryption content of this draft is based upon.
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de
Medeiros, Yaron Y. Goland, Dick Hardt, Jeff Hodges, Edmund Jay, James Medeiros, Vladimir Dzhuvinov, Yaron Y. Goland, Dick Hardt, Jeff
Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Panzer, Hodges, Edmund Jay, James Manger, Matt Miller, Tony Nadalin, Axel
Emmanuel Raviart, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Nennker, John Panzer, Emmanuel Raviart, Nat Sakimura, Jim Schaad,
Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix F. Document History Appendix E. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-18
o Changes to address editorial and minor issues #129, #134, #135,
#158, #161, #185, #186, and #187.
o Added and used Description registry fields.
-17 -17
o Explicitly named all the logical components of a JWS and JWE and o Explicitly named all the logical components of a JWS and JWE and
defined the processing rules and serializations in terms of those defined the processing rules and serializations in terms of those
components, addressing issues #60, #61, and #62. components, addressing issues #60, #61, and #62.
o Removed processing steps in algorithm definitions that duplicated o Removed processing steps in algorithm definitions that duplicated
processing steps in JWS or JWE, addressing issue #56. processing steps in JWS or JWE, addressing issue #56.
o Replaced verbose repetitive phases such as "base64url encode the o Replaced verbose repetitive phases such as "base64url encode the
 End of changes. 281 change blocks. 
656 lines changed or deleted 697 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/