 1/draftietfjosejsonwebalgorithms34.txt 20141017 18:14:49.914014659 0700
+++ 2/draftietfjosejsonwebalgorithms35.txt 20141017 18:14:50.050017953 0700
@@ 1,18 +1,18 @@
JOSE Working Group M. Jones
InternetDraft Microsoft
Intended status: Standards Track October 14, 2014
Expires: April 17, 2015
+Intended status: Standards Track October 17, 2014
+Expires: April 20, 2015
JSON Web Algorithms (JWA)
 draftietfjosejsonwebalgorithms34
+ draftietfjosejsonwebalgorithms35
Abstract
The JSON Web Algorithms (JWA) specification registers cryptographic
algorithms and identifiers to be used with the JSON Web Signature
(JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. It defines several IANA registries for these
identifiers.
Status of this Memo
@@ 23,21 +23,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on April 17, 2015.
+ This InternetDraft will expire on April 20, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 51,117 +51,117 @@
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Cryptographic Algorithms for Digital Signatures and MACs . . . 6
3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 6
3.2. HMAC with SHA2 Functions . . . . . . . . . . . . . . . . 7
3.3. Digital Signature with RSASSAPKCS1V1_5 . . . . . . . . . 8
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 9
3.5. Digital Signature with RSASSAPSS . . . . . . . . . . . . 11
 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11
+ 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 12
4. Cryptographic Algorithms for Key Management . . . . . . . . . 12
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12
4.2. Key Encryption with RSAESPKCS1V1_5 . . . . . . . . . . . 14
4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 14
4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 15
4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 15
4.6. Key Agreement with Elliptic Curve DiffieHellman
Ephemeral Static (ECDHES) . . . . . . . . . . . . . . . . 15
4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 16
 4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 17
+ 4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 16
4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 17
4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 17
4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 17
4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 19
4.7.1. Header Parameters Used for AES GCM Key Encryption . . 19
4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 19
4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 20
4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 20
4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 21
4.8.1.1. "p2s" (PBES2 salt input) Parameter . . . . . . . . 21
4.8.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 21
5. Cryptographic Algorithms for Content Encryption . . . . . . . 21
5.1. "enc" (Encryption Algorithm) Header Parameter Values
for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 22
5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 23
5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 23
 5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 25
+ 5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 24
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 26
5.2.6. Content Encryption with AES_CBC_HMAC_SHA2 . . . . . . 26
5.3. Content Encryption with AES GCM . . . . . . . . . . . . . 27
 6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 28
+ 6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 27
6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28
6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 28
6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28
 6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 29
+ 6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 28
6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 29
6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 29
6.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 29
6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29
6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30
6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 30
6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30
6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 30
6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 30
 6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 31
+ 6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 30
6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 31
6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31
6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 31
6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31
6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 31
 6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 32
+ 6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 31
6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32
 6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 33
 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
 7.1. JSON Web Signature and Encryption Algorithms Registry . . 34
 7.1.1. Registration Template . . . . . . . . . . . . . . . . 35
 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 36
+ 6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 32
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
+ 7.1. JSON Web Signature and Encryption Algorithms Registry . . 33
+ 7.1.1. Registration Template . . . . . . . . . . . . . . . . 34
+ 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35
7.2. Header Parameter Names Registration . . . . . . . . . . . 41
 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 42
+ 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 41
7.3. JSON Web Encryption Compression Algorithms Registry . . . 42
 7.3.1. Registration Template . . . . . . . . . . . . . . . . 43
+ 7.3.1. Registration Template . . . . . . . . . . . . . . . . 42
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 43
7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 43
 7.4.1. Registration Template . . . . . . . . . . . . . . . . 44
+ 7.4.1. Registration Template . . . . . . . . . . . . . . . . 43
7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 44
 7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 45
 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 45
+ 7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 44
+ 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 44
7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 47
 7.6.1. Registration Template . . . . . . . . . . . . . . . . 48
+ 7.6.1. Registration Template . . . . . . . . . . . . . . . . 47
7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 48
 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
 8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 49
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
+ 8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 48
8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 49
8.3. RSAESPKCS1v1_5 Security Considerations . . . . . . . . . 49
 8.4. AES GCM Security Considerations . . . . . . . . . . . . . 50
 8.5. Unsecured JWS Security Considerations . . . . . . . . . . 50
 8.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 51
 8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 51
+ 8.4. AES GCM Security Considerations . . . . . . . . . . . . . 49
+ 8.5. Unsecured JWS Security Considerations . . . . . . . . . . 49
+ 8.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 50
+ 8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 50
8.8. Password Considerations . . . . . . . . . . . . . . . . . 51
 8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 52
 8.10. Differences between Digital Signatures and MACs . . . . . 52
 8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 52
+ 8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 51
+ 8.10. Differences between Digital Signatures and MACs . . . . . 51
+ 8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 51
8.12. Adaptive ChosenCiphertext Attacks . . . . . . . . . . . . 52
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 52
8.14. RSA Private Key Representations and Blinding . . . . . . . 52
9. Internationalization Considerations . . . . . . . . . . . . . 52
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
 10.1. Normative References . . . . . . . . . . . . . . . . . . . 53
 10.2. Informative References . . . . . . . . . . . . . . . . . . 55
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Algorithm Identifier CrossReference . . . . . . . . 56
A.1. Digital Signature/MAC Algorithm Identifier
 CrossReference . . . . . . . . . . . . . . . . . . . . . 57
+ CrossReference . . . . . . . . . . . . . . . . . . . . . 56
A.2. Key Management Algorithm Identifier CrossReference . . . 57
A.3. Content Encryption Algorithm Identifier CrossReference . 58
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 59
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 60
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 61
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 62
Appendix C. Example ECDHES Key Agreement Computation . . . . . . 63
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 65
Appendix E. Document History . . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76
@@ 195,22 +195,22 @@
words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
these words are used without being spelled in uppercase then they are
to be interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2 of [JWS].
UTF8(STRING) denotes the octets of the UTF8 [RFC3629] representation
of STRING.
 ASCII(STRING) denotes the octets of the ASCII [USASCII]
 representation of STRING.
+ ASCII(STRING) denotes the octets of the ASCII [RFC20] representation
+ of STRING.
The concatenation of two values A and B is denoted as A  B.
2. Terminology
These terms defined by the JSON Web Signature (JWS) [JWS]
specification are incorporated into this specification: "JSON Web
Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE
Header", "JWS Payload", "JWS Protected Header", "JWS Signature", "JWS
Signing Input", and "Unsecured JWS".
@@ 222,63 +222,68 @@
Encryption", "Direct Key Agreement", "JWE Authentication Tag", "JWE
Ciphertext", "JWE Encrypted Key", "JWE Initialization Vector", "JWE
Protected Header", "Key Agreement with Key Wrapping", "Key
Encryption", "Key Management Mode", and "Key Wrapping".
These terms defined by the JSON Web Key (JWK) [JWK] specification are
incorporated into this specification: "JSON Web Key (JWK)" and "JSON
Web Key Set (JWK Set)".
These terms defined by the Internet Security Glossary, Version 2
 [RFC4949] are incorporated into this specification: "Ciphertext" and
+ [RFC4949] are incorporated into this specification: "Ciphertext",
+ "Digital Signature", "Message Authentication Code (MAC)", and
"Plaintext".
+ This term is defined by this specification:
+
+ Base64urlUInt
+ The representation of a positive or zero integer value as the
+ base64url encoding of the value's unsigned big endian
+ representation as an octet sequence. The octet sequence MUST
+ utilize the minimum number of octets needed to represent the
+ value. Zero is represented as BASE64URL(single zerovalued
+ octet), which is "AA".
+
3. Cryptographic Algorithms for Digital Signatures and MACs
JWS uses cryptographic algorithms to digitally sign or create a
Message Authentication Code (MAC) of the contents of the JWS
Protected Header and the JWS Payload.
3.1. "alg" (Algorithm) Header Parameter Values for JWS
The table below is the set of "alg" (algorithm) header parameter
values defined by this specification for use with JWS, each of which
is explained in more detail in the following sections:
 ++++
  alg Parameter  Digital Signature or MAC  Implementation 
+ ++++
+  alg Param  Digital Signature or MAC  Implementation 
 Value  Algorithm  Requirements 
 ++++
+ ++++
 HS256  HMAC using SHA256  Required 
 HS384  HMAC using SHA384  Optional 
 HS512  HMAC using SHA512  Optional 
  RS256  RSASSAPKCSv1_5 using  Recommended 
   SHA256  
  RS384  RSASSAPKCSv1_5 using  Optional 
   SHA384  
  RS512  RSASSAPKCSv1_5 using  Optional 
   SHA512  
  ES256  ECDSA using P256 and  Recommended+ 
   SHA256  
  ES384  ECDSA using P384 and  Optional 
   SHA384  
  ES512  ECDSA using P521 and  Optional 
   SHA512  
  PS256  RSASSAPSS using SHA256 and  Optional 
   MGF1 with SHA256  
  PS384  RSASSAPSS using SHA384 and  Optional 
   MGF1 with SHA384  
  PS512  RSASSAPSS using SHA512 and  Optional 
   MGF1 with SHA512  
+  RS256  RSASSAPKCSv1_5 using SHA256  Recommended 
+  RS384  RSASSAPKCSv1_5 using SHA384  Optional 
+  RS512  RSASSAPKCSv1_5 using SHA512  Optional 
+  ES256  ECDSA using P256 and SHA256  Recommended+ 
+  ES384  ECDSA using P384 and SHA384  Optional 
+  ES512  ECDSA using P521 and SHA512  Optional 
+  PS256  RSASSAPSS using SHA256 and MGF1  Optional 
+   with SHA256  
+  PS384  RSASSAPSS using SHA384 and MGF1  Optional 
+   with SHA384  
+  PS512  RSASSAPSS using SHA512 and MGF1  Optional 
+   with SHA512  
 none  No digital signature or MAC  Optional 
  performed  
 ++++
+ ++++
The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of
the specification.
See Appendix A.1 for a table crossreferencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.
@@ 290,37 +295,36 @@
whoever generated the MAC was in possession of the MAC key. The
algorithm for implementing and validating HMACs is provided in RFC
2104 [RFC2104].
A key of the same size as the hash output (for instance, 256 bits for
"HS256") or larger MUST be used with this algorithm. (This
requirement is based on Section 5.3.4 (Security Effect of the HMAC
Key) of NIST SP 800117 [NIST.800107], which states that the
effective security strength is the minimum of the security strength
of the key and two times the size of the internal hash value.)

The HMAC SHA256 MAC is generated per RFC 2104, using SHA256 as the
hash algorithm "H", using the JWS Signing Input as the "text" value,
and using the shared key. The HMAC output value is the JWS
Signature.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWS Signature is an HMAC value computed using the
corresponding algorithm:
 +++
  alg Parameter Value  MAC Algorithm 
 +++
+ +++
+  alg Param Value  MAC Algorithm 
+ +++
 HS256  HMAC using SHA256 
 HS384  HMAC using SHA384 
 HS512  HMAC using SHA512 
 +++
+ +++
The HMAC SHA256 MAC for a JWS is validated by computing an HMAC
value per RFC 2104, using SHA256 as the hash algorithm "H", using
the received JWS Signing Input as the "text" value, and using the
shared key. This computed HMAC value is then compared to the result
of base64url decoding the received encoded JWS Signature value. The
comparison of the computed HMAC value to the JWS Signature value MUST
be done in a constanttime manner to thwart timing attacks.
Alternatively, the computed HMAC value can be base64url encoded and
compared to the received encoded JWS Signature value (also in a
@@ 346,27 +350,27 @@
The RSASSAPKCS1V1_5 SHA256 digital signature is generated as
follows: Generate a digital signature of the JWS Signing Input using
RSASSAPKCS1V1_5SIGN and the SHA256 hash function with the desired
private key. This is the JWS Signature value.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWS Signature is a digital signature value computed
using the corresponding algorithm:
 +++
  alg Parameter Value  Digital Signature Algorithm 
 +++
+ +++
+  alg Param Value  Digital Signature Algorithm 
+ +++
 RS256  RSASSAPKCSv1_5 using SHA256 
 RS384  RSASSAPKCSv1_5 using SHA384 
 RS512  RSASSAPKCSv1_5 using SHA512 
 +++
+ +++
The RSASSAPKCS1V1_5 SHA256 digital signature for a JWS is
validated as follows: Submit the JWS Signing Input, the JWS
Signature, and the public key corresponding to the private key used
by the signer to the RSASSAPKCS1V1_5VERIFY algorithm using SHA256
as the hash function.
Signing and validation with the RSASSAPKCS1V1_5 SHA384 and RSASSA
PKCS1V1_5 SHA512 algorithms is performed identically to the
procedure for RSASSAPKCS1V1_5 SHA256  just using the
@@ 403,27 +407,27 @@
3. Concatenate the two octet sequences in the order R and then S.
(Note that many ECDSA implementations will directly produce this
concatenation as their output.)
4. The resulting 64 octet sequence is the JWS Signature value.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWS Signature is a digital signature value computed
using the corresponding algorithm:
 +++
  alg Parameter Value  Digital Signature Algorithm 
 +++
+ +++
+  alg Param Value  Digital Signature Algorithm 
+ +++
 ES256  ECDSA using P256 and SHA256 
 ES384  ECDSA using P384 and SHA384 
 ES512  ECDSA using P521 and SHA512 
 +++
+ +++
The ECDSA P256 SHA256 digital signature for a JWS is validated as
follows:
1. The JWS Signature value MUST be a 64 octet sequence. If it is
not a 64 octet sequence, the validation has failed.
2. Split the 64 octet sequence into two 32 octet sequences. The
first octet sequence represents R and the second S. The values R
and S are represented as octet sequences using the Integerto
@@ 463,30 +467,27 @@
The RSASSAPSS SHA256 digital signature is generated as follows:
Generate a digital signature of the JWS Signing Input using RSASSA
PSSSIGN, the SHA256 hash function, and the MGF1 mask generation
function with SHA256 with the desired private key. This is the JWS
signature value.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWS Signature is a digital signature value computed
using the corresponding algorithm:
 +++
  alg Parameter Value  Digital Signature Algorithm 
 +++
  PS256  RSASSAPSS using SHA256 and MGF1 with 
   SHA256 
  PS384  RSASSAPSS using SHA384 and MGF1 with 
   SHA384 
  PS512  RSASSAPSS using SHA512 and MGF1 with 
   SHA512 
 +++
+ +++
+  alg Param Value  Digital Signature Algorithm 
+ +++
+  PS256  RSASSAPSS using SHA256 and MGF1 with SHA256 
+  PS384  RSASSAPSS using SHA384 and MGF1 with SHA384 
+  PS512  RSASSAPSS using SHA512 and MGF1 with SHA512 
+ +++
The RSASSAPSS SHA256 digital signature for a JWS is validated as
follows: Submit the JWS Signing Input, the JWS Signature, and the
public key corresponding to the private key used by the signer to the
RSASSAPSSVERIFY algorithm using SHA256 as the hash function and
using MGF1 as the mask generation function with SHA256.
Signing and validation with the RSASSAPSS SHA384 and RSASSAPSS
SHA512 algorithms is performed identically to the procedure for
RSASSAPSS SHA256  just using the alternative hash algorithm in
@@ 507,100 +508,86 @@
JWE uses cryptographic algorithms to encrypt or determine the Content
Encryption Key (CEK).
4.1. "alg" (Algorithm) Header Parameter Values for JWE
The table below is the set of "alg" (algorithm) Header Parameter
values that are defined by this specification for use with JWE.
These algorithms are used to encrypt the CEK, producing the JWE
Encrypted Key, or to use key agreement to agree upon the CEK.
 +++++
  alg Parameter  Key Management  Additional  Implementation 
  Value  Algorithm  Header  Requirements 
    Parameters  
 +++++
  RSA1_5  RSAESPKCS1V1_  (none)  Recommended 
   5   
  RSAOAEP  RSAES OAEP  (none)  Recommended+ 
   using default   
   parameters   
  RSAOAEP256  RSAES OAEP  (none)  Optional 
   using SHA256   
   and MGF1 with   
   SHA256   
  A128KW  AES Key Wrap  (none)  Recommended 
   with default   
   initial value   
   using 128 bit   
   key   
  A192KW  AES Key Wrap  (none)  Optional 
   with default   
   initial value   
   using 192 bit   
   key   
  A256KW  AES Key Wrap  (none)  Recommended 
   with default   
   initial value   
   using 256 bit   
   key   
+ +++++
+  alg Param Value  Key Management  More  Implementation 
+   Algorithm  Header  Requirements 
+    Params  
+ +++++
+  RSA1_5  RSAESPKCS1V1_5  (none)  Recommended 
+  RSAOAEP  RSAES OAEP using  (none)  Recommended+ 
+   default parameters   
+  RSAOAEP256  RSAES OAEP using  (none)  Optional 
+   SHA256 and MGF1   
+   with SHA256   
+  A128KW  AES Key Wrap with  (none)  Recommended 
+   default initial   
+   value using 128   
+   bit key   
+  A192KW  AES Key Wrap with  (none)  Optional 
+   default initial   
+   value using 192   
+   bit key   
+  A256KW  AES Key Wrap with  (none)  Recommended 
+   default initial   
+   value using 256   
+   bit key   
 dir  Direct use of a  (none)  Recommended 
   shared   
   symmetric key   
   as the CEK   
+   shared symmetric   
+   key as the CEK   
 ECDHES  Elliptic Curve  "epk",  Recommended+ 
  DiffieHellman  "apu",  
   Ephemeral  "apv"  
   Static key   
   agreement using   
   Concat KDF   
+   Ephemeral Static  "apv"  
+   key agreement   
+   using Concat KDF   
 ECDHES+A128KW  ECDHES using  "epk",  Recommended 
   Concat KDF and  "apu",  
   CEK wrapped  "apv"  
   with "A128KW"   
  ECDHES+A192KW  ECDHES using  "epk",  Optional 
   Concat KDF and  "apu",  
   CEK wrapped  "apv"  
   with "A192KW"   
  ECDHES+A256KW  ECDHES using  "epk",  Recommended 
   Concat KDF and  "apu",  
   CEK wrapped  "apv"  
   with "A256KW"   
  A128GCMKW  Key wrapping  "iv",  Optional 
   with AES GCM  "tag"  
   using 128 bit   
   key   
  A192GCMKW  Key wrapping  "iv",  Optional 
   with AES GCM  "tag"  
   using 192 bit   
   key   
  A256GCMKW  Key wrapping  "iv",  Optional 
   with AES GCM  "tag"  
   using 256 bit   
   key   
  PBES2HS256+A128K  PBES2 with HMAC  "p2s",  Optional 
  W  SHA256 and  "p2c"  
+   Concat KDF and CEK  "apu",  
+   wrapped with  "apv"  
  "A128KW"   
   wrapping   
  PBES2HS384+A192K  PBES2 with HMAC  "p2s",  Optional 
  W  SHA384 and  "p2c"  
+  ECDHES+A192KW  ECDHES using  "epk",  Optional 
+   Concat KDF and CEK  "apu",  
+   wrapped with  "apv"  
  "A192KW"   
   wrapping   
  PBES2HS512+A256K  PBES2 with HMAC  "p2s",  Optional 
  W  SHA512 and  "p2c"  
+  ECDHES+A256KW  ECDHES using  "epk",  Recommended 
+   Concat KDF and CEK  "apu",  
+   wrapped with  "apv"  
  "A256KW"   
   wrapping   
 +++++
 The Additional Header Parameters column indicates what additional
 Header Parameters are used by the algorithm, beyond "alg", which all
 use. All but "dir" and "ECDHES" also produce a JWE Encrypted Key
 value.
+  A128GCMKW  Key wrapping with  "iv",  Optional 
+   AES GCM using 128  "tag"  
+   bit key   
+  A192GCMKW  Key wrapping with  "iv",  Optional 
+   AES GCM using 192  "tag"  
+   bit key   
+  A256GCMKW  Key wrapping with  "iv",  Optional 
+   AES GCM using 256  "tag"  
+   bit key   
+  PBES2HS256+A128KW  PBES2 with HMAC  "p2s",  Optional 
+   SHA256 and  "p2c"  
+   "A128KW" wrapping   
+  PBES2HS384+A192KW  PBES2 with HMAC  "p2s",  Optional 
+   SHA384 and  "p2c"  
+   "A192KW" wrapping   
+  PBES2HS512+A256KW  PBES2 with HMAC  "p2s",  Optional 
+   SHA512 and  "p2c"  
+   "A256KW" wrapping   
+ +++++
+
+ The More Header Params column indicates what additional Header
+ Parameters are used by the algorithm, beyond "alg", which all use.
+ All but "dir" and "ECDHES" also produce a JWE Encrypted Key value.
The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of
the specification.
See Appendix A.2 for a table crossreferencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
identifiers used by other standards and software packages.
4.2. Key Encryption with RSAESPKCS1V1_5
@@ 621,58 +608,57 @@
hash functions. In the first case, the default parameters specified
by RFC 3447 in Section A.2.1 are used. (Those default parameters are
the SHA1 hash function and the MGF1 with SHA1 mask generation
function.) In the second case, the SHA256 hash function and the
MGF1 with SHA256 mask generation function are used.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWE Encrypted Key is the result of encrypting the
CEK using the corresponding algorithm:
 +++
  alg Parameter Value  Key Management Algorithm 
 +++
+ +++
+  alg Param Value  Key Management Algorithm 
+ +++
 RSAOAEP  RSAES OAEP using default parameters 
  RSAOAEP256  RSAES OAEP using SHA256 and MGF1 with 
   SHA256 
 +++
+  RSAOAEP256  RSAES OAEP using SHA256 and MGF1 with SHA256 
+ +++
A key of size 2048 bits or larger MUST be used with these algorithms.
(This requirement is based on Table 4 (Securitystrength time frames)
of NIST SP 80057 [NIST.80057], which requires 112 bits of security
for new uses, and Table 2 (Comparable strengths) of the same, which
states that 2048 bit RSA keys provide 112 bits of security.)
An example using RSAES OAEP with the default parameters is shown in
Appendix A.1 of [JWE].
4.4. Key Wrapping with AES Key Wrap
This section defines the specifics of encrypting a JWE CEK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
the default initial value specified in Section 2.2.3.1.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWE Encrypted Key is the result of encrypting the
CEK using the corresponding algorithm and key size:
 +++
  alg Parameter  Key Management Algorithm 
+ +++
+  alg Param  Key Management Algorithm 
 Value  
 +++
  A128KW  AES Key Wrap with default initial value using 
   128 bit key 
  A192KW  AES Key Wrap with default initial value using 
   192 bit key 
  A256KW  AES Key Wrap with default initial value using 
   256 bit key 
 +++
+ +++
+  A128KW  AES Key Wrap with default initial value using 128 
+   bit key 
+  A192KW  AES Key Wrap with default initial value using 192 
+   bit key 
+  A256KW  AES Key Wrap with default initial value using 256 
+   bit key 
+ +++
An example using this algorithm is shown in Appendix A.3 of [JWE].
4.5. Direct Encryption with a Shared Symmetric Key
This section defines the specifics of directly performing symmetric
key encryption without performing a key wrapping step. In this case,
the shared symmetric key is used directly as the Content Encryption
Key (CEK) value for the "enc" algorithm. An empty octet sequence is
used as the JWE Encrypted Key value. The "alg" Header Parameter
@@ 709,31 +695,31 @@
In Key Agreement with Key Wrapping mode, the output of the Concat KDF
MUST be a key of the length needed for the specified key wrapping
algorithm. In this case, the JWE Encrypted Key is the CEK wrapped
with the agreed upon key.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWE Encrypted Key is the result of encrypting the
CEK using the result of the key agreement algorithm as the key
encryption key for the corresponding key wrapping algorithm:
 +++
  alg Parameter  Key Management Algorithm 
+ +++
+  alg Param  Key Management Algorithm 
 Value  
 +++
+ +++
 ECDHES+A128KW  ECDHES using Concat KDF and CEK wrapped with 
  "A128KW" 
 ECDHES+A192KW  ECDHES using Concat KDF and CEK wrapped with 
  "A192KW" 
 ECDHES+A256KW  ECDHES using Concat KDF and CEK wrapped with 
  "A256KW" 
 +++
+ +++
4.6.1. Header Parameters Used for ECDH Key Agreement
The following Header Parameter names are used for key agreement as
defined below.
4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter
The "epk" (ephemeral public key) value created by the originator for
the use in key agreement algorithms. This key is represented as a
@@ 853,27 +839,27 @@
The JWE Encrypted Key value is the Ciphertext output.
The Authentication Tag output is represented in base64url encoded
form as the "tag" (authentication tag) Header Parameter value.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWE Encrypted Key is the result of encrypting the
CEK using the corresponding algorithm and key size:
 +++
  alg Parameter Value  Key Management Algorithm 
 +++
+ +++
+  alg Param Value  Key Management Algorithm 
+ +++
 A128GCMKW  Key wrapping with AES GCM using 128 bit key 
 A192GCMKW  Key wrapping with AES GCM using 192 bit key 
 A256GCMKW  Key wrapping with AES GCM using 256 bit key 
 +++
+ +++
4.7.1. Header Parameters Used for AES GCM Key Encryption
The following Header Parameters are used for AES GCM key encryption.
4.7.1.1. "iv" (Initialization Vector) Header Parameter
The "iv" (initialization vector) Header Parameter value is the
base64url encoded representation of the 96 bit Initialization Vector
value used for the key encryption operation. This Header Parameter
@@ 909,30 +895,30 @@
respectively use HMAC SHA256, HMAC SHA384, and HMAC SHA512 as the
PRF and use 128, 192, and 256 bit AES Key Wrap keys. Their derived
key lengths respectively are 16, 24, and 32 octets.
The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWE Encrypted Key is the result of encrypting the
CEK using the result of the corresponding passwordbased encryption
algorithm as the key encryption key for the corresponding key
wrapping algorithm:
 +++
  alg Parameter Value  Key Management Algorithm 
 +++
+ +++
+  alg Param Value  Key Management Algorithm 
+ +++
 PBES2HS256+A128KW  PBES2 with HMAC SHA256 and "A128KW" 
  wrapping 
 PBES2HS384+A192KW  PBES2 with HMAC SHA384 and "A192KW" 
  wrapping 
 PBES2HS512+A256KW  PBES2 with HMAC SHA512 and "A256KW" 
  wrapping 
 +++
+ +++
See Appendix C of JSON Web Key (JWK) [JWK] for an example key
encryption computation using "PBES2HS256+A128KW".
4.8.1. Header Parameters Used for PBES2 Key Encryption
The following Header Parameters are used for Key Encryption with
PBES2.
4.8.1.1. "p2s" (PBES2 salt input) Parameter
@@ 946,88 +932,79 @@
The salt expands the possible keys that can be derived from a given
password. A Salt Input value containing 8 or more octets MUST be
used. A new Salt Input value MUST be generated randomly for every
encryption operation; see RFC 4086 [RFC4086] for considerations on
generating random values. The salt value used is (UTF8(Alg)  0x00
 Salt Input), where Alg is the "alg" Header Parameter value.
4.8.1.2. "p2c" (PBES2 count) Parameter
The "p2c" (PBES2 count) Header Parameter contains the PBKDF2
 iteration count, represented as a positive integer. This Header
+ iteration count, represented as a positive JSON integer. This Header
Parameter MUST be present and MUST be understood and processed by
implementations when these algorithms are used.
The iteration count adds computational expense, ideally compounded by
the possible range of keys introduced by the salt. A minimum
iteration count of 1000 is RECOMMENDED.
5. Cryptographic Algorithms for Content Encryption
JWE uses cryptographic algorithms to encrypt and integrity protect
the Plaintext and to also integrity protect additional authenticated
data.
5.1. "enc" (Encryption Algorithm) Header Parameter Values for JWE
The table below is the set of "enc" (encryption algorithm) Header
Parameter values that are defined by this specification for use with
JWE.
 +++++
  enc  Content Encryption  Additional  Implementatio 
  Parameter  Algorithm  Header  nRequirements 
  Value   Parameters  
 +++++
  A128CBCHS2  AES_128_CBC_HMAC_SHA_2  (none)  Required 
  56  56 authenticated   
   encryption algorithm,   
   as defined in   
   Section 5.2.3   
  A192CBCHS3  AES_192_CBC_HMAC_SHA_3  (none)  Optional 
  84  84 authenticated   
   encryption algorithm,   
   as defined in   
   Section 5.2.4   
  A256CBCHS5  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   
 +++++
+ ++++
+  enc Param  Content Encryption Algorithm  Implementation 
+  Value   Requirements 
+ ++++
+  A128CBCHS256  AES_128_CBC_HMAC_SHA_256  Required 
+   authenticated encryption  
+   algorithm, as defined in  
+   Section 5.2.3  
+  A192CBCHS384  AES_192_CBC_HMAC_SHA_384  Optional 
+   authenticated encryption  
+   algorithm, as defined in  
+   Section 5.2.4  
+  A256CBCHS512  AES_256_CBC_HMAC_SHA_512  Required 
+   authenticated encryption  
+   algorithm, as defined in  
+   Section 5.2.5  
+  A128GCM  AES GCM using 128 bit key  Recommended 
+  A192GCM  AES GCM using 192 bit key  Optional 
+  A256GCM  AES GCM using 256 bit key  Recommended 
+ ++++
 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
+ All also use a JWE Initialization Vector value and produce JWE
Ciphertext and JWE Authentication Tag values.
See Appendix A.3 for a table crossreferencing the JWE "enc"
(encryption algorithm) 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
 built using a composition of Advanced Encryption Standard (AES) in
 Cipher Block Chaining (CBC) mode with PKCS #7 padding [AES,
 NIST.80038A] operations and HMAC [RFC2104, SHS] operations. This
 algorithm family is called AES_CBC_HMAC_SHA2. It also defines three
 instances of this family, the first using 128 bit CBC keys and HMAC
 SHA256, the second using 192 bit CBC keys and HMAC SHA384, and the
 third using 256 bit CBC keys and HMAC SHA512. Test cases for these
 algorithms can be found in Appendix B.
+ built using a composition of Advanced Encryption Standard (AES) [AES]
+ in Cipher Block Chaining (CBC) mode [NIST.80038A] with PKCS #7
+ padding [RFC5652], Section 6.3 operations and HMAC [RFC2104, SHS]
+ operations. This algorithm family is called AES_CBC_HMAC_SHA2. It
+ also defines three instances of this family, the first using 128 bit
+ CBC keys and HMAC SHA256, the second using 192 bit CBC keys and HMAC
+ SHA384, and the third using 256 bit CBC keys and HMAC SHA512. Test
+ cases for these algorithms can be found in Appendix B.
These algorithms are based upon Authenticated Encryption with AESCBC
and HMACSHA [ID.mcgrewaeadaescbchmacsha2], performing the same
cryptographic computations, but with the Initialization Vector and
Authentication Tag values remaining separate, rather than being
concatenated with the Ciphertext value in the output representation.
This option is discussed in Appendix B of that specification. This
algorithm family is a generalization of the algorithm family in
[ID.mcgrewaeadaescbchmacsha2], and can be used to implement
those algorithms.
@@ 1136,23 +1114,23 @@
computing an HMAC with the inputs as in Step 5 of
Section 5.2.2.1. The value T, from the previous step, is
compared to the first MAC_KEY length bits of the HMAC output. If
those values are identical, then A and E are considered valid,
and processing is continued. Otherwise, all of the data used in
the MAC validation are discarded, and the Authenticated
Encryption decryption operation returns an indication that it
failed, and the operation halts. (But see Section 11.5 of [JWE]
for security considerations on thwarting timing attacks.)
 3. The value E is decrypted and the PKCS #7 padding is removed. The
 value IV is used as the initialization vector. The value ENC_KEY
 is used as the decryption key.
+ 3. The value E is decrypted and the PKCS #7 padding is checked and
+ removed. The value IV is used as the initialization vector. The
+ value ENC_KEY is used as the decryption key.
4. The plaintext value is returned.
5.2.3. AES_128_CBC_HMAC_SHA_256
This algorithm is a concrete instantiation of the generic
AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message
authentication code [RFC2104] with the SHA256 hash function [SHS] to
provide message authentication, with the HMAC output truncated to 128
bits, corresponding to the HMACSHA256128 algorithm defined in
@@ 1211,21 +1189,21 @@
This section defines the specifics of performing authenticated
encryption with the AES_CBC_HMAC_SHA2 algorithms.
The CEK is used as the secret key K.
The following "enc" (encryption algorithm) Header Parameter values
are used to indicate that the JWE Ciphertext and JWE Authentication
Tag values have been computed using the corresponding algorithm:
+++
  enc Parameter  Content Encryption Algorithm 
+  enc Param  Content Encryption Algorithm 
 Value  
+++
 A128CBCHS256  AES_128_CBC_HMAC_SHA_256 authenticated encryption 
  algorithm, as defined in Section 5.2.3 
 A192CBCHS384  AES_192_CBC_HMAC_SHA_384 authenticated encryption 
  algorithm, as defined in Section 5.2.4 
 A256CBCHS512  AES_256_CBC_HMAC_SHA_512 authenticated encryption 
  algorithm, as defined in Section 5.2.5 
+++
@@ 1241,90 +1219,95 @@
algorithm.
The requested size of the Authentication Tag output MUST be 128 bits,
regardless of the key size.
The following "enc" (encryption algorithm) Header Parameter values
are used to indicate that the JWE Ciphertext and JWE Authentication
Tag values have been computed using the corresponding algorithm and
key size:
 +++
  enc Parameter Value  Content Encryption Algorithm 
 +++
+ +++
+  enc Param Value  Content Encryption Algorithm 
+ +++
 A128GCM  AES GCM using 128 bit key 
 A192GCM  AES GCM using 192 bit key 
 A256GCM  AES GCM using 256 bit key 
 +++
+ +++
An example using this algorithm is shown in Appendix A.1 of [JWE].
6. Cryptographic Algorithms for Keys
A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a
cryptographic key. These keys can be either asymmetric or symmetric.
They can hold both public and private information about the key.
This section defines the parameters for keys using the algorithms
specified by this document.
6.1. "kty" (Key Type) Parameter Values
The table below is the set of "kty" (key type) parameter values that
are defined by this specification for use in JWKs.
 ++++
  kty  Key Type  Implementation 
  Parameter   Requirements 
  Value   
 ++++
+ ++++
+  kty Param  Key Type  Implementation 
+  Value   Requirements 
+ ++++
 EC  Elliptic Curve [DSS]  Recommended+ 
 RSA  RSA [RFC3447]  Required 
  oct  Octet sequence (used to  Required 
   represent symmetric keys)  
 ++++
+  oct  Octet sequence (used to represent  Required 
+   symmetric keys)  
+ ++++
The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of
the specification.
6.2. Parameters for Elliptic Curve Keys
JWKs can represent Elliptic Curve [DSS] keys. In this case, the
"kty" member value is "EC".
6.2.1. Parameters for Elliptic Curve Public Keys
An elliptic curve public key is represented by a pair of coordinates
drawn from a finite field, which together define a point on an
 elliptic curve. The following members MUST be present for elliptic
 curve public keys:
+ elliptic curve. The following members MUST be present for all
+ elliptic curve public keys:
o "crv"
o "x"
 o "y"
 SEC1 [SEC1] point compression is not supported for any values.
+ The following member MUST also be present for elliptic curve public
+ keys for the three curves defined in the following section:
+
+ o "y"
6.2.1.1. "crv" (Curve) Parameter
The "crv" (curve) member identifies the cryptographic curve used with
the key. Curve values from [DSS] used by this specification are:
o "P256"
o "P384"
o "P521"
These values are registered in the IANA JSON Web Key Elliptic Curve
registry defined in Section 7.6. Additional "crv" values can be
 registered by other specifications. Additional "crv" values MAY be
 used, provided they are understood by implementations using that
 Elliptic Curve key. The "crv" value is a casesensitive string.
+ registered by other specifications. Specifications registering
+ additional curves must define what parameters are used to represent
+ keys for the curves registered. The "crv" value is a casesensitive
+ string.
+
+ SEC1 [SEC1] point compression is not supported for any of these three
+ curves.
6.2.1.2. "x" (X Coordinate) Parameter
The "x" (x coordinate) member contains the x coordinate for the
elliptic curve point. It is represented as the base64url encoding of
the octet string representation of the coordinate, as defined in
Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST
be the full size of a coordinate for the curve specified in the "crv"
parameter. For example, if the value of "crv" is "P521", the octet
string must be 66 octets long.
@@ 1342,162 +1325,128 @@
6.2.2. Parameters for Elliptic Curve Private Keys
In addition to the members used to represent Elliptic Curve public
keys, the following member MUST be present to represent Elliptic
Curve private keys.
6.2.2.1. "d" (ECC Private Key) Parameter
The "d" (ECC private key) member contains the Elliptic Curve private
key value. It is represented as the base64url encoding of the octet
 string representation of the private key value, as defined in
 Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet
 string MUST be ceiling(logbase2(n)/8) octets (where n is the order
 of the curve).
+ string representation of the private key value, as defined in Section
+ 2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be
+ ceiling(logbase2(n)/8) octets (where n is the order of the curve).
6.3. Parameters for RSA Keys
JWKs can represent RSA [RFC3447] keys. In this case, the "kty"
member value is "RSA".
6.3.1. Parameters for RSA Public Keys
The following members MUST be present for RSA public keys.
6.3.1.1. "n" (Modulus) Parameter
The "n" (modulus) member contains the modulus value for the RSA
 public key. It is represented as the base64url encoding of the
 value's unsigned big endian representation as an octet sequence. The
 octet sequence MUST utilize the minimum number of octets to represent
 the value.
+ public key. It is represented as a Base64urlUInt encoded value.
Note that implementers have found that some cryptographic libraries
prefix an extra zerovalued octet to the modulus representations they
return, for instance, returning 257 octets for a 2048 bit key, rather
than 256. Implementations using such libraries will need to take
care to omit the extra octet from the base64url encoded
representation.
6.3.1.2. "e" (Exponent) Parameter
The "e" (exponent) member contains the exponent value for the RSA
 public key. It is represented as the base64url encoding of the
 value's unsigned big endian representation as an octet sequence. The
 octet sequence MUST utilize the minimum number of octets to represent
 the value. For instance, when representing the value 65537, the
 octet sequence to be base64url encoded MUST consist of the three
 octets [1, 0, 1].
+ public key. It is represented as a Base64urlUInt encoded value.
+
+ For instance, when representing the value 65537, the octet sequence
+ to be base64url encoded MUST consist of the three octets [1, 0, 1];
+ the resulting representation for this value is "AQAB".
6.3.2. Parameters for RSA Private Keys
In addition to the members used to represent RSA public keys, the
following members are used to represent RSA private keys. The
parameter "d" is REQUIRED for RSA private keys. The others enable
optimizations and SHOULD be included by producers of JWKs
representing RSA private keys. If the producer includes any of the
other private key parameters, then all of the others MUST be present,
with the exception of "oth", which MUST only be present when more
 than two prime factors were used. The consumer of a JWK MAY choose
 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
 "d" is the only RSA private key parameter included.
+ than two prime factors were used.
6.3.2.1. "d" (Private Exponent) Parameter
The "d" (private exponent) member contains the private exponent value
 for the RSA private key. It is represented as the base64url encoding
 of the value's unsigned big endian representation as an octet
 sequence. The octet sequence MUST utilize the minimum number of
 octets to represent the value.
+ for the RSA private key. It is represented as a Base64urlUInt
+ encoded value.
6.3.2.2. "p" (First Prime Factor) Parameter
 The "p" (first prime factor) member contains the first prime factor,
 a positive integer. It is represented as the base64url encoding of
 the value's unsigned big endian representation as an octet sequence.
 The octet sequence MUST utilize the minimum number of octets to
 represent the value.
+ The "p" (first prime factor) member contains the first prime factor.
+ It is represented as a Base64urlUInt encoded value.
6.3.2.3. "q" (Second Prime Factor) Parameter
The "q" (second prime factor) member contains the second prime
 factor, a positive integer. It is represented as the base64url
 encoding of the value's unsigned big endian representation as an
 octet sequence. The octet sequence MUST utilize the minimum number
 of octets to represent the value.
+ factor. It is represented as a Base64urlUInt encoded value.
6.3.2.4. "dp" (First Factor CRT Exponent) Parameter
The "dp" (first factor CRT exponent) member contains the Chinese
 Remainder Theorem (CRT) exponent of the first factor, a positive
 integer. It is represented as the base64url encoding of the value's
 unsigned big endian representation as an octet sequence. The octet
 sequence MUST utilize the minimum number of octets to represent the
 value.
+ Remainder Theorem (CRT) exponent of the first factor. It is
+ represented as a Base64urlUInt encoded value.
6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter
The "dq" (second factor CRT exponent) member contains the Chinese
 Remainder Theorem (CRT) exponent of the second factor, a positive
 integer. It is represented as the base64url encoding of the value's
 unsigned big endian representation as an octet sequence. The octet
 sequence MUST utilize the minimum number of octets to represent the
 value.
+ Remainder Theorem (CRT) exponent of the second factor. It is
+ represented as a Base64urlUInt encoded value.
6.3.2.6. "qi" (First CRT Coefficient) Parameter
The "qi" (first CRT coefficient) member contains the Chinese
 Remainder Theorem (CRT) coefficient of the second factor, a positive
 integer. It is represented as the base64url encoding of the value's
 unsigned big endian representation as an octet sequence. The octet
 sequence MUST utilize the minimum number of octets to represent the
 value.
+ Remainder Theorem (CRT) coefficient of the second factor. It is
+ represented as a Base64urlUInt encoded value.
6.3.2.7. "oth" (Other Primes Info) Parameter
The "oth" (other primes info) member contains an array of information
about any third and subsequent primes, should they exist. When only
two primes have been used (the normal case), this parameter MUST be
omitted. When three or more primes have been used, the number of
array elements MUST be the number of primes used minus two. For more
information on this case, see the description of the OtherPrimeInfo
parameters in Section A.1.2 of RFC 3447 [RFC3447], upon which the
following parameters are modelled. Each array element MUST be an
object with the following members:
6.3.2.7.1. "r" (Prime Factor)
The "r" (prime factor) parameter within an "oth" array member
 represents the value of a subsequent prime factor, a positive
 integer. It is represented as the base64url encoding of the value's
 unsigned big endian representation as an octet sequence. The octet
 sequence MUST utilize the minimum number of octets to represent the
 value.
+ represents the value of a subsequent prime factor. It is represented
+ as a Base64urlUInt encoded value.
6.3.2.7.2. "d" (Factor CRT Exponent)
The "d" (Factor CRT Exponent) parameter within an "oth" array member
 represents the CRT exponent of the corresponding prime factor, a
 positive integer. It is represented as the base64url encoding of the
 value's unsigned big endian representation as an octet sequence. The
 octet sequence MUST utilize the minimum number of octets to represent
 the value.
+ represents the CRT exponent of the corresponding prime factor. It is
+ represented as a Base64urlUInt encoded value.
6.3.2.7.3. "t" (Factor CRT Coefficient)
The "t" (factor CRT coefficient) parameter within an "oth" array
member represents the CRT coefficient of the corresponding prime
 factor, a positive integer. It is represented as the base64url
 encoding of the value's unsigned big endian representation as an
 octet sequence. The octet sequence MUST utilize the minimum number
 of octets to represent the value.
+ factor. It is represented as a Base64urlUInt encoded value.
6.4. Parameters for Symmetric Keys
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
is a single octet sequence). An "alg" member SHOULD also be present
to identify the algorithm intended to be used with the key, unless
the application uses another means or convention to determine the
algorithm used.
@@ 1595,28 +1544,27 @@
the status of an algorithm to Deprecated, or to change the status of
an algorithm from Optional to Recommended+ or Required. Changes of
implementation requirements are only permitted on a Specification
Required basis after review by the Designated Experts(s), with the
new specification defining the revised implementation requirements
level.
7.1.1. Registration Template
Algorithm Name:
 The name requested (e.g., "example"). This name is case
 sensitive. Names may not match other registered names in a case
 insensitive manner unless the Designated Expert(s) state that
 there is a compelling reason to allow an exception in this
 particular case.
+ The name requested (e.g., "HS256"). This name is casesensitive.
+ Names may not match other registered names in a caseinsensitive
+ manner unless the Designated Expert(s) state that there is a
+ compelling reason to allow an exception in this particular case.
Algorithm Description:
 Brief description of the Algorithm (e.g., "Example description").
+ Brief description of the Algorithm (e.g., "HMAC using SHA256").
Algorithm Usage Location(s):
The algorithm usage location. This must be one or more of the
values "alg" or "enc" if the algorithm is to be used with JWS or
JWE. The value "JWK" is used if the algorithm identifier will be
used as a JWK "alg" member value, but will not be used with JWS or
JWE; this could be the case, for instance, for nonauthenticated
encryption algorithms. Other values may be used with the approval
of a Designated Expert.
@@ 1963,32 +1910,31 @@
7.3. JSON Web Encryption Compression Algorithms Registry
This specification establishes the IANA JSON Web Encryption
Compression Algorithms registry for JWE "zip" member values. The
registry records the compression algorithm value and a reference to
the specification that defines it.
7.3.1. Registration Template
Compression Algorithm Value:
 The name requested (e.g., "example"). Because a core goal of this
+ The name requested (e.g., "DEF"). Because a core goal of this
specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short  not to exceed 8
characters without a compelling reason to do so. This name is
casesensitive. Names may not match other registered names in a
caseinsensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Compression Algorithm Description:
 Brief description of the compression algorithm (e.g., "Example
 description").
+ Brief description of the compression algorithm (e.g., "DEFLATE").
Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
Specification Document(s):
Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also
@@ 2013,31 +1959,31 @@
the status of a key type to Deprecated, or to change the status of a
key type from Optional to Recommended+ or Required. Changes of
implementation requirements are only permitted on a Specification
Required basis after review by the Designated Experts(s), with the
new specification defining the revised implementation requirements
level.
7.4.1. Registration Template
"kty" Parameter Value:
 The name requested (e.g., "example"). Because a core goal of this
+ The name requested (e.g., "EC"). Because a core goal of this
specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short  not to exceed 8
characters without a compelling reason to do so. This name is
casesensitive. Names may not match other registered names in a
caseinsensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Key Type Description:
 Brief description of the Key Type (e.g., "Example description").
+ Brief description of the Key Type (e.g., "Elliptic Curve").
Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
JOSE Implementation Requirements:
The key type implementation requirements for JWS and JWE, which
must be one the words Required, Recommended, Optional, Deprecated,
or Prohibited. Optionally, the word can be followed by a "+" or
@@ 2192,31 +2137,31 @@
as the cryptographic landscape evolves, for instance, to change the
status of a curve to Deprecated, or to change the status of a curve
from Optional to Recommended+ or Required. Changes of implementation
requirements are only permitted on a Specification Required basis
after review by the Designated Experts(s), with the new specification
defining the revised implementation requirements level.
7.6.1. Registration Template
Curve Name:
 The name requested (e.g., "example"). Because a core goal of this
+ The name requested (e.g., "P256"). Because a core goal of this
specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short  not to exceed 8
characters without a compelling reason to do so. This name is
casesensitive. Names may not match other registered names in a
caseinsensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Curve Description:
 Brief description of the curve (e.g., "Example description").
+ Brief description of the curve (e.g., "P256 curve").
JOSE Implementation Requirements:
The curve implementation requirements for JWS and JWE, which must
be one the words Required, Recommended, Optional, Deprecated, or
Prohibited. Optionally, the word can be followed by a "+" or "".
The use of "+" indicates that the requirement strength is likely
to be increased in a future version of the specification. The use
of "" indicates that the requirement strength is likely to be
decreased in a future version of the specification.
@@ 2252,23 +2197,23 @@
o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
8. Security Considerations
All of the security issues that are pertinent to any cryptographic
application must be addressed by JWS/JWE/JWK agents. Among these
issues are protecting the user's asymmetric private and symmetric
secret keys and employing countermeasures to various attacks.
The security considerations in [AES], [DSS], [JWE], [JWK], [JWS],
 [NIST.80038A], [NIST.80038D], [NIST.80056A], [NIST.800107],
 [RFC2104], [RFC3394], [RFC3447], [RFC5116], [RFC6090], and [SHS]
 apply to this specification.
+ [NIST.80038D], [NIST.80056A], [NIST.800107], [RFC2104], [RFC3394],
+ [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this
+ specification.
8.1. Cryptographic Agility
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will be reduced. Therefore, implementers and
deployments must be prepared for the set of algorithms that are
supported and used to change over time. Thus, cryptographic
algorithm implementations should be modular, allowing new algorithms
@@ 2280,22 +2225,22 @@
key lifetimes and/or the number of times that a key may be used.
Those security considerations continue to apply when using those
algorithms with JOSE data structures. See NIST SP 80057
[NIST.80057] for specific guidance on key lifetimes.
8.3. RSAESPKCS1v1_5 Security Considerations
While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
to adopt RSASSAPKCSv1_5 for new applications and instead requests
that people transition to RSASSAPSS, this specification does include
 RSASSAPKCSv1_5, for interoperability reasons, because it commonly
 implemented.
+ RSASSAPKCSv1_5, for interoperability reasons, because it is
+ commonly implemented.
Keys used with RSAESPKCS1v1_5 must follow the constraints in
Section 7.2 of RFC 3447. Also, keys with a low public key exponent
value, as described in Section 3 of Twenty years of attacks on the
RSA cryptosystem [Boneh99], must not be used.
8.4. AES GCM Security Considerations
Keys used with AES GCM must follow the constraints in Section 8.3 of
[NIST.80038D], which states: "The total number of invocations of the
@@ 2353,27 +2298,29 @@
supply content using keys that would result in excessive
cryptographic processing, for example, keys larger than those
mandated in this specification. Implementations should set and
enforce upper limits on the key sizes they accept. Section 5.6.1
(Comparable Algorithm Strengths) of NIST SP 80057 [NIST.80057]
contains statements on largest approved key sizes that may be
applicable.
8.7. Reusing Key Material when Encrypting Keys
 It is NOT RECOMMENDED to reuse the same key material (Key Encryption
 Key, Content Encryption Key, Initialization Vector, etc.) to encrypt
 multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK
 Set object multiple times. One suggestion for preventing reuse is
 to always generate a new set of key material for each encryption
 operation, based on the considerations noted in this document as well
 as from RFC 4086 [RFC4086].
+ It is NOT RECOMMENDED to reuse the same entire set of key material
+ (Key Encryption Key, Content Encryption Key, Initialization Vector,
+ etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the
+ same JWK or JWK Set object multiple times. One suggestion for
+ preventing reuse is to always generate at least one new piece of key
+ material for each encryption operation (e.g., a new Content
+ Encryption Key, a new Initialization Vector, and/or a new PBES2
+ Salt), based on the considerations noted in this document as well as
+ from RFC 4086 [RFC4086].
8.8. Password Considerations
Passwords are vulnerable to a number of attacks. To help mitigate
some of these limitations, this document applies principles from RFC
2898 [RFC2898] to derive cryptographic keys from usersupplied
passwords.
However, the strength of the password still has a significant impact.
A highentropy password has greater resistance to dictionary attacks.
@@ 2479,20 +2426,23 @@
"Recommendation for PairWise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 80056A, Revision 2, May 2013.
[NIST.80057]
National Institute of Standards and Technology (NIST),
"Recommendation for Key Management  Part 1: General
(Revision 3)", NIST Special Publication 80057, Part 1,
Revision 3, July 2012.
+ [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
+ October 1969.
+
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2898] Kaliski, B., "PKCS #5: PasswordBased Cryptography
Specification Version 2.0", RFC 2898, September 2000.
@@ 2505,46 +2455,49 @@
[RFC3629] Yergeau, F., "UTF8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4868] Kelly, S. and S. Frankel, "Using HMACSHA256, HMACSHA
384, and HMACSHA512 with IPsec", RFC 4868, May 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+ RFC 5652, September 2009.
+
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
 Elliptic Curve Cryptography", May 2009.
+ Elliptic Curve Cryptography", Version 2.0, May 2009.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 1804, March 2012.
[USASCII] American National Standards Institute, "Coded Character
Set  7bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
10.2. Informative References
[CanvasApp]
Facebook, "Canvas Applications", 2010.
[ID.ietfprecissaslprepbis]
SaintAndre, P. and A. Melnikov, "Preparation and
Comparison of Internationalized Strings Representing
 Usernames and Passwords", draftietfprecissaslprepbis07
 (work in progress), March 2014.
+ Usernames and Passwords", draftietfprecissaslprepbis08
+ (work in progress), October 2014.
[ID.mcgrewaeadaescbchmacsha2]
McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AESCBC and HMACSHA",
draftmcgrewaeadaescbchmacsha205 (work in progress),
July 2014.
[ID.millerjosejweprotectedjwk]
Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK)
@@ 2630,106 +2582,108 @@
[JCA] for more information about the names defined by those
documents.
A.1. Digital Signature/MAC Algorithm Identifier CrossReference
This section contains a table crossreferencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.
 +++++
+ +++++
 JWS  XML DSIG  JCA  OID 
 +++++
  HS2  http://www.w3.org/2001/04/xml  HmacSHA256  1.2.840.1135 
  56  dsigmore#hmacsha256   49.2.9 
  HS3  http://www.w3.org/2001/04/xml  HmacSHA384  1.2.840.1135 
  84  dsigmore#hmacsha384   49.2.10 
  HS5  http://www.w3.org/2001/04/xml  HmacSHA512  1.2.840.1135 
  12  dsigmore#hmacsha512   49.2.11 
  RS2  http://www.w3.org/2001/04/xml  SHA256withRS  1.2.840.1135 
  56  dsigmore#rsasha256  A  49.1.1.11 
  RS3  http://www.w3.org/2001/04/xml  SHA384withRS  1.2.840.1135 
  84  dsigmore#rsasha384  A  49.1.1.12 
  RS5  http://www.w3.org/2001/04/xml  SHA512withRS  1.2.840.1135 
  12  dsigmore#rsasha512  A  49.1.1.13 
  ES2  http://www.w3.org/2001/04/xml  SHA256withEC  1.2.840.1004 
  56  dsigmore#ecdsasha256  DSA  5.4.3.2 
  ES3  http://www.w3.org/2001/04/xml  SHA384withEC  1.2.840.1004 
  84  dsigmore#ecdsasha384  DSA  5.4.3.3 
  ES5  http://www.w3.org/2001/04/xml  SHA512withEC  1.2.840.1004 
  12  dsigmore#ecdsasha512  DSA  5.4.3.4 
  PS2  http://www.w3.org/2007/05/xml  SHA256withRS  1.2.840.1135 
  56  dsigmore#sha256rsaMGF1  AandMGF1  49.1.1.10 
  PS3  http://www.w3.org/2007/05/xml  SHA384withRS  1.2.840.1135 
  84  dsigmore#sha384rsaMGF1  AandMGF1  49.1.1.10 
  PS5  http://www.w3.org/2007/05/xml  SHA512withRS  1.2.840.1135 
  12  dsigmore#sha512rsaMGF1  AandMGF1  49.1.1.10 
 +++++
+ +++++
+  HS256  http://www.w3.org/2001/04/xm  HmacSHA256  1.2.840.1135 
+   ldsigmore#hmacsha256   49.2.9 
+  HS384  http://www.w3.org/2001/04/xm  HmacSHA384  1.2.840.1135 
+   ldsigmore#hmacsha384   49.2.10 
+  HS512  http://www.w3.org/2001/04/xm  HmacSHA512  1.2.840.1135 
+   ldsigmore#hmacsha512   49.2.11 
+  RS256  http://www.w3.org/2001/04/xm  SHA256withR  1.2.840.1135 
+   ldsigmore#rsasha256  SA  49.1.1.11 
+  RS384  http://www.w3.org/2001/04/xm  SHA384withR  1.2.840.1135 
+   ldsigmore#rsasha384  SA  49.1.1.12 
+  RS512  http://www.w3.org/2001/04/xm  SHA512withR  1.2.840.1135 
+   ldsigmore#rsasha512  SA  49.1.1.13 
+  ES256  http://www.w3.org/2001/04/xm  SHA256withE  1.2.840.1004 
+   ldsigmore#ecdsasha256  CDSA  5.4.3.2 
+  ES384  http://www.w3.org/2001/04/xm  SHA384withE  1.2.840.1004 
+   ldsigmore#ecdsasha384  CDSA  5.4.3.3 
+  ES512  http://www.w3.org/2001/04/xm  SHA512withE  1.2.840.1004 
+   ldsigmore#ecdsasha512  CDSA  5.4.3.4 
+  PS256  http://www.w3.org/2007/05/xm  SHA256withR  1.2.840.1135 
+   ldsigmore#sha256rsaMGF1  SAandMGF1  49.1.1.10 
+  PS384  http://www.w3.org/2007/05/xm  SHA384withR  1.2.840.1135 
+   ldsigmore#sha384rsaMGF1  SAandMGF1  49.1.1.10 
+  PS512  http://www.w3.org/2007/05/xm  SHA512withR  1.2.840.1135 
+   ldsigmore#sha512rsaMGF1  SAandMGF1  49.1.1.10 
+ +++++
A.2. Key Management Algorithm Identifier CrossReference
This section contains a table crossreferencing 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.113 
  5  /04/xmlenc#rsa1_5  ng  549.1.1.1 
  RSAO  http://www.w3.org/2001  RSA/ECB/OAEPWithSH  1.2.840.113 
  AEP  /04/xmlenc#rsaoaepmg  A1AndMGF1Padding  549.1.1.7 
   f1p   
  RSAO  http://www.w3.org/2009  RSA/ECB/OAEPWithSH  1.2.840.113 
  AEP2  /xmlenc11#rsaoaep &  A256AndMGF1Paddin  549.1.1.7 
  56  http://www.w3.org/200  g&  
   9/xmlenc11#mgf1sha256  MGF1ParameterSpec  
    .SHA256  
  ECDH  http://www.w3.org/2009  ECDH  1.3.132.1.1 
  ES  /xmlenc11#ECDHES   2 
  A128K  http://www.w3.org/2001  AESWrap  2.16.840.1. 
  W  /04/xmlenc#kwaes128   101.3.4.1.5 
  A192K  http://www.w3.org/2001  AESWrap  2.16.840.1. 
  W  /04/xmlenc#kwaes192   101.3.4.1.2 
     5 
  A256K  http://www.w3.org/2001  AESWrap  2.16.840.1. 
  W  /04/xmlenc#kwaes256   101.3.4.1.4 
     5 
 +++++
+ +++++
+  RSA1_5  http://www.w3.org/20  RSA/ECB/PKCS1Padd  1.2.840.113 
+   01/04/xmlenc#rsa1_5  ing  549.1.1.1 
+  RSAOAEP  http://www.w3.org/20  RSA/ECB/OAEPWithS  1.2.840.113 
+   01/04/xmlenc#rsaoae  HA1AndMGF1Paddin  549.1.1.7 
+   pmgf1p  g  
+  RSAOAEP  http://www.w3.org/20  RSA/ECB/OAEPWithS  1.2.840.113 
+  256  09/xmlenc11#rsaoaep  HA256AndMGF1Padd  549.1.1.7 
+   &  ing &  
+   http://www.w3.org/2  MGF1ParameterSp  
+   009/xmlenc11#mgf1sha  ec.SHA256  
+   256   
+  ECDHES  http://www.w3.org/20  ECDH  1.3.132.1.1 
+   09/xmlenc11#ECDHES   2 
+  A128KW  http://www.w3.org/20  AESWrap  2.16.840.1. 
+   01/04/xmlenc#kwaes1   101.3.4.1.5 
+   28   
+  A192KW  http://www.w3.org/20  AESWrap  2.16.840.1. 
+   01/04/xmlenc#kwaes1   101.3.4.1.2 
+   92   5 
+  A256KW  http://www.w3.org/20  AESWrap  2.16.840.1. 
+   01/04/xmlenc#kwaes2   101.3.4.1.4 
+   56   5 
+ +++++
A.3. Content Encryption Algorithm Identifier CrossReference
This section contains a table crossreferencing the JWE "enc"
(encryption algorithm) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
For the composite algorithms "A128CBCHS256", "A192CBCHS384", and
"A256CBCHS512", the corresponding AES CBC algorithm identifiers are
listed.
 +++++
+ +++++
 JWE  XML ENC  JCA  OID 
 +++++
  A128CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.101 
  HS256  04/xmlenc#aes128cbc  5Padding  .3.4.1.2 
  A192CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.101 
  HS384  04/xmlenc#aes192cbc  5Padding  .3.4.1.22 
  A256CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.101 
  HS512  04/xmlenc#aes256cbc  5Padding  .3.4.1.42 
  A128GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.101 
   xmlenc11#aes128gcm  dding  .3.4.1.6 
  A192GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.101 
   xmlenc11#aes192gcm  dding  .3.4.1.26 
  A256GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.101 
   xmlenc11#aes256gcm  dding  .3.4.1.46 
 +++++
+ +++++
+  A128CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.10 
+  HS256  04/xmlenc#aes128cbc  5Padding  1.3.4.1.2 
+  A192CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.10 
+  HS384  04/xmlenc#aes192cbc  5Padding  1.3.4.1.22 
+  A256CBC  http://www.w3.org/2001/  AES/CBC/PKCS  2.16.840.1.10 
+  HS512  04/xmlenc#aes256cbc  5Padding  1.3.4.1.42 
+  A128GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.10 
+   xmlenc11#aes128gcm  dding  1.3.4.1.6 
+  A192GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.10 
+   xmlenc11#aes192gcm  dding  1.3.4.1.26 
+  A256GCM  http://www.w3.org/2009/  AES/GCM/NoPa  2.16.840.1.10 
+   xmlenc11#aes256gcm  dding  1.3.4.1.46 
+ +++++
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 5.2. They are
also intended to correspond to test cases that may appear in a future
version of [ID.mcgrewaeadaescbchmacsha2], demonstrating that
the cryptographic computations performed are the same.
The variable names are those defined in Section 5.2. All values are
@@ 3007,36 +2961,42 @@
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects
[ID.millerjosejweprotectedjwk], which the passwordbased
encryption content of this draft is based upon.
This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
that influenced this specification:
 Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Alissa
 Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni Even, Stephen
 Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges,
 Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger, Matt Miller,
 Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel
 Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura, Jim Schaad,
 Hannes Tschofenig, and Sean Turner.
+ Dirk Balfanz, Richard Barnes, Carsten Bormann, John Bradley, Brian
+ Campbell, Alissa Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni
+ Even, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand,
+ Jeff Hodges, Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger,
+ Matt Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John
+ Panzer, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,
+ Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification.
Appendix E. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]]
+ 35
+
+ o Addressed AppsDir reviews by Carsten Bormann.
+
+ o Adjusted some table column widths.
+
34
o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete
Resnick, Stephen Farrell, and Richard Barnes.
33
o Changed the registration review period to three weeks.
o Acknowledged additional contributors.