idnits 2.17.00 (12 Aug 2021) /tmp/idnits11380/draft-ietf-jose-json-web-encryption-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 27, 2012) is 3431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2015 -- Looks like a reference, but probably isn't: '0' on line 2030 -- Looks like a reference, but probably isn't: '227' on line 1280 -- Looks like a reference, but probably isn't: '197' on line 1280 -- Looks like a reference, but probably isn't: '117' on line 1280 -- Looks like a reference, but probably isn't: '252' on line 1280 -- Looks like a reference, but probably isn't: '2' on line 1280 -- Looks like a reference, but probably isn't: '219' on line 1280 -- Looks like a reference, but probably isn't: '233' on line 1280 -- Looks like a reference, but probably isn't: '68' on line 1280 -- Looks like a reference, but probably isn't: '180' on line 1280 -- Looks like a reference, but probably isn't: '225' on line 1280 -- Looks like a reference, but probably isn't: '77' on line 1280 -- Looks like a reference, but probably isn't: '253' on line 1751 -- Looks like a reference, but probably isn't: '220' on line 1751 -- Looks like a reference, but probably isn't: '80' on line 1751 -- Looks like a reference, but probably isn't: '25' on line 1751 -- Looks like a reference, but probably isn't: '166' on line 1751 -- Looks like a reference, but probably isn't: '152' on line 1751 -- Looks like a reference, but probably isn't: '178' on line 1751 -- Looks like a reference, but probably isn't: '168' on line 1751 -- Looks like a reference, but probably isn't: '97' on line 1751 -- Looks like a reference, but probably isn't: '99' on line 1984 -- Looks like a reference, but probably isn't: '67' on line 1751 -- Looks like a reference, but probably isn't: '89' on line 1751 -- Looks like a reference, but probably isn't: '69' on line 1984 -- Looks like a reference, but probably isn't: '110' on line 2033 -- Looks like a reference, but probably isn't: '114' on line 2033 -- Looks like a reference, but probably isn't: '121' on line 2033 -- Looks like a reference, but probably isn't: '112' on line 1984 -- Looks like a reference, but probably isn't: '116' on line 2033 -- Looks like a reference, but probably isn't: '105' on line 2033 -- Looks like a reference, but probably isn't: '111' on line 1984 -- Looks like a reference, but probably isn't: '73' on line 2033 -- Looks like a reference, but probably isn't: '101' on line 2033 -- Looks like a reference, but probably isn't: '103' on line 2033 == Unused Reference: 'RFC3629' is defined on line 1086, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' == Outdated reference: draft-ietf-jose-json-web-algorithms has been published as RFC 7518 == Outdated reference: draft-ietf-jose-json-web-key has been published as RFC 7517 == Outdated reference: draft-ietf-jose-json-web-signature has been published as RFC 7515 ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 38 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track E. Rescorla 5 Expires: June 30, 2013 RTFM 6 J. Hildebrand 7 Cisco 8 December 27, 2012 10 JSON Web Encryption (JWE) 11 draft-ietf-jose-json-web-encryption-08 13 Abstract 15 JSON Web Encryption (JWE) is a means of representing encrypted 16 content using JavaScript Object Notation (JSON) data structures. 17 Cryptographic algorithms and identifiers for use with this 18 specification are described in the separate JSON Web Algorithms (JWA) 19 specification. Related digital signature and MAC capabilities are 20 described in the separate JSON Web Signature (JWS) specification. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 30, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 7 60 3.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 8 61 3.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC . . . . . . 9 62 4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 12 64 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 12 65 4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 12 66 4.1.3. "epk" (Ephemeral Public Key) Header Parameter . . . . 13 67 4.1.4. "zip" (Compression Algorithm) Header Parameter . . . . 13 68 4.1.5. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 13 69 4.1.6. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13 70 4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13 71 4.1.8. "x5t" (X.509 Certificate Thumbprint) Header 72 Parameter . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1.9. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14 74 4.1.10. "kid" (Key ID) Header Parameter . . . . . . . . . . . 15 75 4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 15 76 4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 15 77 4.1.13. "apu" (Agreement PartyUInfo) Header Parameter . . . . 15 78 4.1.14. "apv" (Agreement PartyVInfo) Header Parameter . . . . 15 79 4.1.15. "epu" (Encryption PartyUInfo) Header Parameter . . . . 16 80 4.1.16. "epv" (Encryption PartyVInfo) Header Parameter . . . . 16 81 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 16 82 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 16 83 5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . . 16 84 5.1. Message Encryption . . . . . . . . . . . . . . . . . . . . 16 85 5.2. Message Decryption . . . . . . . . . . . . . . . . . . . . 18 86 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 19 87 6. Encrypting JWEs with Cryptographic Algorithms . . . . . . . . 20 88 6.1. CMK Encryption . . . . . . . . . . . . . . . . . . . . . . 20 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 7.1. Registration of JWE Header Parameter Names . . . . . . . . 20 91 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 92 7.2. JSON Web Signature and Encryption Type Values 93 Registration . . . . . . . . . . . . . . . . . . . . . . . 22 94 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 95 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 23 96 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 101 Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 25 102 A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 26 103 A.1.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 26 104 A.1.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 26 105 A.1.3. Content Master Key (CMK) . . . . . . . . . . . . . . . 26 106 A.1.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 26 107 A.1.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 29 108 A.1.6. Initialization Vector . . . . . . . . . . . . . . . . 29 109 A.1.7. "Additional Authenticated Data" Parameter . . . . . . 29 110 A.1.8. Plaintext Encryption . . . . . . . . . . . . . . . . . 30 111 A.1.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 30 112 A.1.10. Encoded JWE Integrity Value . . . . . . . . . . . . . 31 113 A.1.11. Complete Representation . . . . . . . . . . . . . . . 31 114 A.1.12. Validation . . . . . . . . . . . . . . . . . . . . . . 31 115 A.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC . . . . . . 31 116 A.2.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 32 117 A.2.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 32 118 A.2.3. Content Master Key (CMK) . . . . . . . . . . . . . . . 32 119 A.2.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 32 120 A.2.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 35 121 A.2.6. Key Derivation . . . . . . . . . . . . . . . . . . . . 35 122 A.2.7. Initialization Vector . . . . . . . . . . . . . . . . 35 123 A.2.8. Plaintext Encryption . . . . . . . . . . . . . . . . . 35 124 A.2.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 36 125 A.2.10. Secured Input Value . . . . . . . . . . . . . . . . . 36 126 A.2.11. JWE Integrity Value . . . . . . . . . . . . . . . . . 37 127 A.2.12. Encoded JWE Integrity Value . . . . . . . . . . . . . 37 128 A.2.13. Complete Representation . . . . . . . . . . . . . . . 37 129 A.2.14. Validation . . . . . . . . . . . . . . . . . . . . . . 38 130 A.3. Example JWE using AES Key Wrap and AES GCM . . . . . . . . 38 131 A.3.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 38 132 A.3.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 39 133 A.3.3. Content Master Key (CMK) . . . . . . . . . . . . . . . 39 134 A.3.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 39 135 A.3.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 39 136 A.3.6. Initialization Vector . . . . . . . . . . . . . . . . 39 137 A.3.7. "Additional Authenticated Data" Parameter . . . . . . 40 138 A.3.8. Plaintext Encryption . . . . . . . . . . . . . . . . . 40 139 A.3.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 40 140 A.3.10. Encoded JWE Integrity Value . . . . . . . . . . . . . 41 141 A.3.11. Complete Representation . . . . . . . . . . . . . . . 41 142 A.3.12. Validation . . . . . . . . . . . . . . . . . . . . . . 41 143 A.4. Example Key Derivation for "enc" value "A128CBC+HS256" . . 41 144 A.4.1. CEK Generation . . . . . . . . . . . . . . . . . . . . 42 145 A.4.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 43 146 A.5. Example Key Derivation for "enc" value "A256CBC+HS512" . . 44 147 A.5.1. CEK Generation . . . . . . . . . . . . . . . . . . . . 44 148 A.5.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 45 149 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 46 150 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 47 151 Appendix D. Document History . . . . . . . . . . . . . . . . . . 47 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 154 1. Introduction 156 JSON Web Encryption (JWE) is a compact encryption format intended for 157 space constrained environments such as HTTP Authorization headers and 158 URI query parameters. It represents this content using JavaScript 159 Object Notation (JSON) [RFC4627] based data structures. The JWE 160 cryptographic mechanisms encrypt and provide integrity protection for 161 arbitrary sequences of bytes. 163 Cryptographic algorithms and identifiers for use with this 164 specification are described in the separate JSON Web Algorithms (JWA) 165 [JWA] specification. Related digital signature and MAC capabilities 166 are described in the separate JSON Web Signature (JWS) [JWS] 167 specification. 169 1.1. Notational Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in Key words for use in 174 RFCs to Indicate Requirement Levels [RFC2119]. 176 2. Terminology 178 JSON Web Encryption (JWE) A data structure representing an encrypted 179 message. The structure consists of five parts: the JWE Header, 180 the JWE Encrypted Key, the JWE Initialization Vector, the JWE 181 Ciphertext, and the JWE Integrity Value. 183 Plaintext The bytes to be encrypted -- a.k.a., the message. The 184 plaintext can contain an arbitrary sequence of bytes. 186 Ciphertext An encrypted representation of the Plaintext. 188 Content Encryption Key (CEK) A symmetric key used to encrypt the 189 Plaintext for the recipient to produce the Ciphertext. 191 Content Integrity Key (CIK) A key used with a MAC function to ensure 192 the integrity of the Ciphertext and the parameters used to create 193 it. 195 Content Master Key (CMK) A key from which the CEK and CIK are 196 derived. When key wrapping or key encryption are employed, the 197 CMK is randomly generated and encrypted to the recipient as the 198 JWE Encrypted Key. When direct encryption with a shared symmetric 199 key is employed, the CMK is the shared key. When key agreement 200 without key wrapping is employed, the CMK is the result of the key 201 agreement algorithm. 203 JSON Text Object A UTF-8 encoded text string representing a JSON 204 object; the syntax of JSON objects is defined in Section 2.2 of 205 [RFC4627]. 207 JWE Header A JSON Text Object that describes the encryption 208 operations applied to create the JWE Encrypted Key, the JWE 209 Ciphertext, and the JWE Integrity Value. 211 JWE Encrypted Key When key wrapping or key encryption are employed, 212 the Content Master Key (CMK) is encrypted with the intended 213 recipient's key and the resulting encrypted content is recorded as 214 a byte array, which is referred to as the JWE Encrypted Key. 215 Otherwise, when direct encryption with a shared or agreed upon 216 symmetric key is employed, the JWE Encrypted Key is the empty byte 217 array. 219 JWE Initialization Vector A byte array containing the Initialization 220 Vector used when encrypting the Plaintext. 222 JWE Ciphertext A byte array containing the Ciphertext. 224 JWE Integrity Value A byte array containing a MAC value that ensures 225 the integrity of the Ciphertext and the parameters used to create 226 it. 228 Base64url Encoding The URL- and filename-safe Base64 encoding 229 described in RFC 4648 [RFC4648], Section 5, with the (non URL- 230 safe) '=' padding characters omitted, as permitted by Section 3.2. 231 (See Appendix C of [JWS] for notes on implementing base64url 232 encoding without padding.) 234 Encoded JWE Header Base64url encoding of the JWE Header. 236 Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted 237 Key. 239 Encoded JWE Initialization Vector Base64url encoding of the JWE 240 Initialization Vector. 242 Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext. 244 Encoded JWE Integrity Value Base64url encoding of the JWE Integrity 245 Value. 247 Header Parameter Name The name of a member of the JWE Header. 249 Header Parameter Value The value of a member of the JWE Header. 251 JWE Compact Serialization A representation of the JWE as the 252 concatenation of the Encoded JWE Header, the Encoded JWE Encrypted 253 Key, the Encoded JWE Initialization Vector, the Encoded JWE 254 Ciphertext, and the Encoded JWE Integrity Value in that order, 255 with the five strings being separated by four period ('.') 256 characters. 258 Authenticated Encryption An Authenticated Encryption algorithm is 259 one that provides an integrated content integrity check. 260 Authenticated Encryption algorithms accept two inputs, the 261 plaintext and the "additional authenticated data" value, and 262 produce two outputs, the ciphertext and the "authentication tag" 263 value. AES Galois/Counter Mode (GCM) is one such algorithm. 265 Collision Resistant Namespace A namespace that allows names to be 266 allocated in a manner such that they are highly unlikely to 267 collide with other names. For instance, collision resistance can 268 be achieved through administrative delegation of portions of the 269 namespace or through use of collision-resistant name allocation 270 functions. Examples of Collision Resistant Namespaces include: 271 Domain Names, Object Identifiers (OIDs) as defined in the ITU-T 272 X.660 and X.670 Recommendation series, and Universally Unique 273 IDentifiers (UUIDs) [RFC4122]. When using an administratively 274 delegated namespace, the definer of a name needs to take 275 reasonable precautions to ensure they are in control of the 276 portion of the namespace they use to define the name. 278 StringOrURI A JSON string value, with the additional requirement 279 that while arbitrary string values MAY be used, any value 280 containing a ":" character MUST be a URI [RFC3986]. StringOrURI 281 values are compared as case-sensitive strings with no 282 transformations or canonicalizations applied. 284 3. JSON Web Encryption (JWE) Overview 286 JWE represents encrypted content using JSON data structures and 287 base64url encoding. The representation consists of five parts: the 288 JWE Header, the JWE Encrypted Key, the JWE Initialization Vector, the 289 JWE Ciphertext, and the JWE Integrity Value. In the Compact 290 Serialization, the five parts are base64url-encoded for transmission, 291 and represented as the concatenation of the encoded strings in that 292 order, with the five strings being separated by four period ('.') 293 characters. (A JSON Serialization for this information is defined in 294 the separate JSON Web Encryption JSON Serialization (JWE-JS) [JWE-JS] 295 specification.) 297 JWE utilizes encryption to ensure the confidentiality of the 298 Plaintext. JWE adds a content integrity check if not provided by the 299 underlying encryption algorithm. 301 3.1. Example JWE using RSAES OAEP and AES GCM 303 This example encrypts the plaintext "Live long and prosper." to the 304 recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an 305 integrated integrity check. 307 The following example JWE Header declares that: 309 o the Content Master Key is encrypted to the recipient using the 310 RSAES OAEP algorithm to produce the JWE Encrypted Key and 312 o the Plaintext is encrypted using the AES GCM algorithm with a 256 313 bit key to produce the Ciphertext. 315 {"alg":"RSA-OAEP","enc":"A256GCM"} 317 Base64url encoding the bytes of the UTF-8 representation of the JWE 318 Header yields this Encoded JWE Header value: 320 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ 322 The remaining steps to finish creating this JWE are: 324 o Generate a random Content Master Key (CMK) 326 o Encrypt the CMK with the recipient's public key using the RSAES 327 OAEP algorithm to produce the JWE Encrypted Key 329 o Base64url encode the JWE Encrypted Key to produce the Encoded JWE 330 Encrypted Key 332 o Generate a random JWE Initialization Vector 334 o Base64url encode the JWE Initialization Vector to produce the 335 Encoded JWE Initialization Vector 337 o Concatenate the Encoded JWE Header value, a period character 338 ('.'), the Encoded JWE Encrypted Key, a second period character 339 ('.'), and the Encoded JWE Initialization Vector to create the 340 "additional authenticated data" parameter for the AES GCM 341 algorithm 343 o Encrypt the Plaintext with AES GCM, using the CMK as the 344 encryption key, the JWE Initialization Vector, and the "additional 345 authenticated data" value above, requesting a 128 bit 346 "authentication tag" output 348 o Base64url encode the resulting Ciphertext to create the Encoded 349 JWE Ciphertext 351 o Base64url encode the resulting "authentication tag" to create the 352 Encoded JWE Integrity Value 354 o Assemble the final representation: The Compact Serialization of 355 this result is the concatenation of the Encoded JWE Header, the 356 Encoded JWE Encrypted Key, the Encoded JWE Initialization Vector, 357 the Encoded JWE Ciphertext, and the Encoded JWE Integrity Value in 358 that order, with the five strings being separated by four period 359 ('.') characters. 361 The final result in this example (with line breaks for display 362 purposes only) is: 364 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. 365 M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m 366 rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA 367 O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj 368 zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN 369 SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG 370 6BBBbR37pHcyzext9epOAQ. 371 48V1_ALb6US04U3b. 372 _e21tGGhac_peEFkLXr2dMPUZiUkrw. 373 7V5ZDko0v_mf2PAc4JMiUg 375 See Appendix A.1 for the complete details of computing this JWE. 377 3.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC 379 This example encrypts the plaintext "No matter where you go, there 380 you are." to the recipient using RSAES-PKCS1-V1_5 and AES CBC. AES 381 CBC does not have an integrated integrity check, so a separate 382 integrity check calculation is performed using HMAC SHA-256, with 383 separate encryption and integrity keys being derived from a master 384 key using the Concat KDF with the SHA-256 digest function. 386 The following example JWE Header (with line breaks for display 387 purposes only) declares that: 389 o the Content Master Key is encrypted to the recipient using the 390 RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and 392 o the Plaintext is encrypted using the AES CBC algorithm with a 128 393 bit key to produce the Ciphertext, with the integrity of the 394 Ciphertext and the parameters used to create it being secured 395 using the HMAC SHA-256 algorithm. 397 {"alg":"RSA1_5","enc":"A128CBC+HS256"} 399 Base64url encoding the bytes of the UTF-8 representation of the JWE 400 Header yields this Encoded JWE Header value: 402 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0 404 The remaining steps to finish creating this JWE are like the previous 405 example, but with an additional step to compute the separate 406 integrity value: 408 o Generate a random Content Master Key (CMK) 410 o Encrypt the CMK with the recipient's public key using the RSAES- 411 PKCS1-V1_5 algorithm to produce the JWE Encrypted Key 413 o Base64url encode the JWE Encrypted Key to produce the Encoded JWE 414 Encrypted Key 416 o Generate a random JWE Initialization Vector 418 o Base64url encode the JWE Initialization Vector to produce the 419 Encoded JWE Initialization Vector 421 o Use the Concat key derivation function to derive Content 422 Encryption Key (CEK) and Content Integrity Key (CIK) values from 423 the CMK 425 o Encrypt the Plaintext with AES CBC using the CEK and JWE 426 Initialization Vector to produce the Ciphertext 428 o Base64url encode the resulting Ciphertext to create the Encoded 429 JWE Ciphertext 431 o Concatenate the Encoded JWE Header value, a period character 432 ('.'), the Encoded JWE Encrypted Key, a second period character 433 ('.'), the Encoded JWE Initialization Vector, a third period ('.') 434 character, and the Encoded JWE Ciphertext to create the value to 435 integrity protect 437 o Compute the HMAC SHA-256 of this value using the CIK to create the 438 JWE Integrity Value 440 o Base64url encode the resulting JWE Integrity Value to create the 441 Encoded JWE Integrity Value 443 o Assemble the final representation: The Compact Serialization of 444 this result is the concatenation of the Encoded JWE Header, the 445 Encoded JWE Encrypted Key, the Encoded JWE Initialization Vector, 446 the Encoded JWE Ciphertext, and the Encoded JWE Integrity Value in 447 that order, with the five strings being separated by four period 448 ('.') characters. 450 The final result in this example (with line breaks for display 451 purposes only) is: 453 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0. 454 O6AqXqgVlJJ4c4lp5sXZd7bpGHAw6ARkHUeXQxD1cAW4-X1x0qtj_AN0mukqEOl4 455 Y6UOwJXIJY9-G1ELK-RQWrKH_StR-AM9H7GpKmSEji8QYOcMOjr-u9H1Lt_pBEie 456 G802SxWz0rbFTXRcj4BWLxcpCtjUZ31AP-sc-L_eCZ5UNl0aSRNqFskuPkzRsFZR 457 DJqSSJeVOyJ7pZCQ83fli19Vgi_3R7XMUqluQuuc7ZHOWixi47jXlBTlWRZ5iFxa 458 S8G6J8wUrd4BKggAw3qX5XoIfXQVlQZE0Vmkq_zQSIo5LnFKyowooRcdsEuNh9B9 459 Mkyt0ZQElG-jGdtHWjZSOA. 460 AxY8DCtDaGlsbGljb3RoZQ. 461 1eBWFgcrz40wC88cgv8rPgu3EfmC1p4zT0kIxxfSF2zDJcQ-iEHk1jQM95xAdr5Z. 462 RBGhYzE8_cZLHjJqqHuLhzbgWgL_wV3LDSUrcbkOiIA 464 See Appendix A.2 for the complete details of computing this JWE. 466 4. JWE Header 468 The members of the JSON object represented by the JWE Header describe 469 the encryption applied to the Plaintext and optionally additional 470 properties of the JWE. The Header Parameter Names within this object 471 MUST be unique; JWEs with duplicate Header Parameter Names MUST be 472 rejected. Implementations MUST understand the entire contents of the 473 header; otherwise, the JWE MUST be rejected. 475 There are two ways of distinguishing whether a header is a JWS Header 476 or a JWE Header. The first is by examining the "alg" (algorithm) 477 header value. If the value represents a digital signature or MAC 478 algorithm, or is the value "none", it is for a JWS; if it represents 479 an encryption or key agreement algorithm, it is for a JWE. A second 480 method is determining whether an "enc" (encryption method) member 481 exists. If the "enc" member exists, it is a JWE; otherwise, it is a 482 JWS. Both methods will yield the same result for all legal input 483 values. 485 There are three classes of Header Parameter Names: Reserved Header 486 Parameter Names, Public Header Parameter Names, and Private Header 487 Parameter Names. 489 4.1. Reserved Header Parameter Names 491 The following Header Parameter Names are reserved with meanings as 492 defined below. All the names are short because a core goal of JWE is 493 for the representations to be compact. 495 Additional reserved Header Parameter Names MAY be defined via the 496 IANA JSON Web Signature and Encryption Header Parameters registry 497 [JWS]. As indicated by the common registry, JWSs and JWEs share a 498 common header parameter space; when a parameter is used by both 499 specifications, its usage must be compatible between the 500 specifications. 502 4.1.1. "alg" (Algorithm) Header Parameter 504 The "alg" (algorithm) header parameter identifies the cryptographic 505 algorithm used to encrypt or determine the value of the Content 506 Master Key (CMK). The algorithm specified by the "alg" value MUST be 507 supported by the implementation and there MUST be a key for use with 508 that algorithm associated with the intended recipient or the JWE MUST 509 be rejected. "alg" values SHOULD either be registered in the IANA 510 JSON Web Signature and Encryption Algorithms registry [JWA] or be a 511 value that contains a Collision Resistant Namespace. The "alg" value 512 is a case sensitive string containing a StringOrURI value. Use of 513 this header parameter is REQUIRED. 515 A list of defined "alg" values can be found in the IANA JSON Web 516 Signature and Encryption Algorithms registry [JWA]; the initial 517 contents of this registry are the values defined in Section 4.1 of 518 the JSON Web Algorithms (JWA) [JWA] specification. 520 4.1.2. "enc" (Encryption Method) Header Parameter 522 The "enc" (encryption method) header parameter identifies the block 523 encryption algorithm used to encrypt the Plaintext to produce the 524 Ciphertext. This algorithm MUST be an Authenticated Encryption 525 algorithm with a specified key length. The algorithm specified by 526 the "enc" value MUST be supported by the implementation or the JWE 527 MUST be rejected. "enc" values SHOULD either be registered in the 528 IANA JSON Web Signature and Encryption Algorithms registry [JWA] or 529 be a value that contains a Collision Resistant Namespace. The "enc" 530 value is a case sensitive string containing a StringOrURI value. Use 531 of this header parameter is REQUIRED. 533 A list of defined "enc" values can be found in the IANA JSON Web 534 Signature and Encryption Algorithms registry [JWA]; the initial 535 contents of this registry are the values defined in Section 4.2 of 536 the JSON Web Algorithms (JWA) [JWA] specification. 538 4.1.3. "epk" (Ephemeral Public Key) Header Parameter 540 The "epk" (ephemeral public key) value created by the originator for 541 the use in key agreement algorithms. This key is represented as a 542 JSON Web Key [JWK] value. Use of this header parameter is OPTIONAL, 543 although its use is REQUIRED with some "alg" algorithms. 545 4.1.4. "zip" (Compression Algorithm) Header Parameter 547 The "zip" (compression algorithm) applied to the Plaintext before 548 encryption, if any. If present, the value of the "zip" header 549 parameter MUST be the case sensitive string "DEF". Compression is 550 performed with the DEFLATE [RFC1951] algorithm. If no "zip" 551 parameter is present, no compression is applied to the Plaintext 552 before encryption. Use of this header parameter is OPTIONAL. 554 4.1.5. "jku" (JWK Set URL) Header Parameter 556 The "jku" (JWK Set URL) header parameter is a URI [RFC3986] that 557 refers to a resource for a set of JSON-encoded public keys, one of 558 which corresponds to the key used to encrypt the JWE; this can be 559 used to determine the private key needed to decrypt the JWE. The 560 keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The 561 protocol used to acquire the resource MUST provide integrity 562 protection; an HTTP GET request to retrieve the certificate MUST use 563 TLS [RFC2818] [RFC5246]; the identity of the server MUST be 564 validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of 565 this header parameter is OPTIONAL. 567 4.1.6. "jwk" (JSON Web Key) Header Parameter 569 The "jwk" (JSON Web Key) header parameter is a public key that 570 corresponds to the key used to encrypt the JWE; this can be used to 571 determine the private key needed to decrypt the JWE. This key is 572 represented as a JSON Web Key [JWK]. Use of this header parameter is 573 OPTIONAL. 575 4.1.7. "x5u" (X.509 URL) Header Parameter 577 The "x5u" (X.509 URL) header parameter is a URI [RFC3986] that refers 578 to a resource for the X.509 public key certificate or certificate 579 chain [RFC5280] corresponding to the key used to encrypt the JWE; 580 this can be used to determine the private key needed to decrypt the 581 JWE. The identified resource MUST provide a representation of the 582 certificate or certificate chain that conforms to RFC 5280 [RFC5280] 583 in PEM encoded form [RFC1421]. The certificate containing the public 584 key of the entity that encrypted the JWE MUST be the first 585 certificate. This MAY be followed by additional certificates, with 586 each subsequent certificate being the one used to certify the 587 previous one. The protocol used to acquire the resource MUST provide 588 integrity protection; an HTTP GET request to retrieve the certificate 589 MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be 590 validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of 591 this header parameter is OPTIONAL. 593 4.1.8. "x5t" (X.509 Certificate Thumbprint) Header Parameter 595 The "x5t" (X.509 Certificate Thumbprint) header parameter provides a 596 base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER 597 encoding of the X.509 certificate [RFC5280] corresponding to the key 598 used to encrypt the JWE; this can be used to determine the private 599 key needed to decrypt the JWE. Use of this header parameter is 600 OPTIONAL. 602 If, in the future, certificate thumbprints need to be computed using 603 hash functions other than SHA-1, it is suggested that additional 604 related header parameters be defined for that purpose. For example, 605 it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint 606 using SHA-256) header parameter could be defined by registering it in 607 the IANA JSON Web Signature and Encryption Header Parameters registry 608 [JWS]. 610 4.1.9. "x5c" (X.509 Certificate Chain) Header Parameter 612 The "x5c" (X.509 Certificate Chain) header parameter contains the 613 X.509 public key certificate or certificate chain [RFC5280] 614 corresponding to the key used to encrypt the JWE; this can be used to 615 determine the private key needed to decrypt the JWE. The certificate 616 or certificate chain is represented as an array of certificate value 617 strings. Each string is a base64 encoded ([RFC4648] Section 4 -- not 618 base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The 619 certificate containing the public key of the entity that encrypted 620 the JWE MUST be the first certificate. This MAY be followed by 621 additional certificates, with each subsequent certificate being the 622 one used to certify the previous one. The recipient MUST verify the 623 certificate chain according to [RFC5280] and reject the JWE if any 624 validation failure occurs. Use of this header parameter is OPTIONAL. 626 See Appendix B of [JWS] for an example "x5c" value. 628 4.1.10. "kid" (Key ID) Header Parameter 630 The "kid" (key ID) header parameter is a hint indicating which key 631 was used to encrypt the JWE; this can be used to determine the 632 private key needed to decrypt the JWE. This parameter allows 633 originators to explicitly signal a change of key to recipients. 634 Should the recipient be unable to locate a key corresponding to the 635 "kid" value, they SHOULD treat that condition as an error. The 636 interpretation of the "kid" value is unspecified. Its value MUST be 637 a string. Use of this header parameter is OPTIONAL. 639 When used with a JWK, the "kid" value MAY be used to match a JWK 640 "kid" parameter value. 642 4.1.11. "typ" (Type) Header Parameter 644 The "typ" (type) header parameter is used to declare the type of this 645 object. The type value "JWE" MAY be used to indicate that this 646 object is a JWE. The "typ" value is a case sensitive string. Use of 647 this header parameter is OPTIONAL. 649 MIME Media Type [RFC2046] values MAY be used as "typ" values. 651 "typ" values SHOULD either be registered in the IANA JSON Web 652 Signature and Encryption Type Values registry [JWS] or be a value 653 that contains a Collision Resistant Namespace. 655 4.1.12. "cty" (Content Type) Header Parameter 657 The "cty" (content type) header parameter is used to declare the type 658 of the encrypted content (the Plaintext). The "cty" value is a case 659 sensitive string. Use of this header parameter is OPTIONAL. 661 The values used for the "cty" header parameter come from the same 662 value space as the "typ" header parameter, with the same rules 663 applying. 665 4.1.13. "apu" (Agreement PartyUInfo) Header Parameter 667 The "apu" (agreement PartyUInfo) value for key agreement algorithms 668 using it (such as "ECDH-ES"), represented as a base64url encoded 669 string. Use of this header parameter is OPTIONAL. 671 4.1.14. "apv" (Agreement PartyVInfo) Header Parameter 673 The "apv" (agreement PartyVInfo) value for key agreement algorithms 674 using it (such as "ECDH-ES"), represented as a base64url encoded 675 string. Use of this header parameter is OPTIONAL. 677 4.1.15. "epu" (Encryption PartyUInfo) Header Parameter 679 The "epu" (encryption PartyUInfo) value for plaintext encryption 680 algorithms using it (such as "A128CBC+HS256"), represented as a 681 base64url encoded string. Use of this header parameter is OPTIONAL. 683 4.1.16. "epv" (Encryption PartyVInfo) Header Parameter 685 The "epv" (encryption PartyVInfo) value for plaintext encryption 686 algorithms using it (such as "A128CBC+HS256"), represented as a 687 base64url encoded string. Use of this header parameter is OPTIONAL. 689 4.2. Public Header Parameter Names 691 Additional Header Parameter Names can be defined by those using JWEs. 692 However, in order to prevent collisions, any new Header Parameter 693 Name SHOULD either be registered in the IANA JSON Web Signature and 694 Encryption Header Parameters registry [JWS] or be a Public Name: a 695 value that contains a Collision Resistant Namespace. In each case, 696 the definer of the name or value needs to take reasonable precautions 697 to make sure they are in control of the part of the namespace they 698 use to define the Header Parameter Name. 700 New header parameters should be introduced sparingly, as they can 701 result in non-interoperable JWEs. 703 4.3. Private Header Parameter Names 705 A producer and consumer of a JWE may agree to use Header Parameter 706 Names that are Private Names: names that are not Reserved Names 707 Section 4.1 or Public Names Section 4.2. Unlike Public Names, 708 Private Names are subject to collision and should be used with 709 caution. 711 5. Producing and Consuming JWEs 713 5.1. Message Encryption 715 The message encryption process is as follows. The order of the steps 716 is not significant in cases where there are no dependencies between 717 the inputs and outputs of the steps. 719 1. When key wrapping, key encryption, or key agreement with key 720 wrapping are employed, generate a random Content Master Key 721 (CMK). See RFC 4086 [RFC4086] for considerations on generating 722 random values. The CMK MUST have a length equal to that 723 required for the block encryption algorithm. 725 2. When key agreement is employed, use the key agreement algorithm 726 to compute the value of the agreed upon key. When key agreement 727 without key wrapping is employed, let the Content Master Key 728 (CMK) be the agreed upon key. When key agreement with key 729 wrapping is employed, the agreed upon key will be used to wrap 730 the CMK. 732 3. When key wrapping, key encryption, or key agreement with key 733 wrapping are employed, encrypt the CMK for the recipient (see 734 Section 6.1) and let the result be the JWE Encrypted Key. 735 Otherwise, when direct encryption with a shared or agreed upon 736 symmetric key is employed, let the JWE Encrypted Key be the 737 empty byte array. 739 4. When direct encryption with a shared symmetric key is employed, 740 let the Content Master Key (CMK) be the shared key. 742 5. Base64url encode the JWE Encrypted Key to create the Encoded JWE 743 Encrypted Key. 745 6. Generate a random JWE Initialization Vector of the correct size 746 for the block encryption algorithm (if required for the 747 algorithm); otherwise, let the JWE Initialization Vector be the 748 empty byte string. 750 7. Base64url encode the JWE Initialization Vector to create the 751 Encoded JWE Initialization Vector. 753 8. Compress the Plaintext if a "zip" parameter was included. 755 9. Serialize the (compressed) Plaintext into a byte sequence M. 757 10. Create a JWE Header containing the encryption parameters used. 758 Note that white space is explicitly allowed in the 759 representation and no canonicalization need be performed before 760 encoding. 762 11. Base64url encode the bytes of the UTF-8 representation of the 763 JWE Header to create the Encoded JWE Header. 765 12. Let the "additional authenticated data" value be the bytes of 766 the ASCII representation of the concatenation of the Encoded JWE 767 Header, a period ('.') character, the Encoded JWE Encrypted Key, 768 a second period character ('.'), and the Encoded JWE 769 Initialization Vector. 771 13. Encrypt M using the CMK, the JWE Initialization Vector, and the 772 "additional authenticated data" value using the specified block 773 encryption algorithm to create the JWE Ciphertext value and the 774 JWE Integrity Value (which is the "authentication tag" output 775 from the calculation). 777 14. Base64url encode the JWE Ciphertext to create the Encoded JWE 778 Ciphertext. 780 15. Base64url encode the JWE Integrity Value to create the Encoded 781 JWE Integrity Value. 783 16. The five encoded parts, taken together, are the result. 785 17. The Compact Serialization of this result is the concatenation of 786 the Encoded JWE Header, the Encoded JWE Encrypted Key, the 787 Encoded JWE Initialization Vector, the Encoded JWE Ciphertext, 788 and the Encoded JWE Integrity Value in that order, with the five 789 strings being separated by four period ('.') characters. 791 5.2. Message Decryption 793 The message decryption process is the reverse of the encryption 794 process. The order of the steps is not significant in cases where 795 there are no dependencies between the inputs and outputs of the 796 steps. If any of these steps fails, the JWE MUST be rejected. 798 1. Determine the Encoded JWE Header, the Encoded JWE Encrypted Key, 799 the Encoded JWE Initialization Vector, the Encoded JWE 800 Ciphertext, and the Encoded JWE Integrity Value values contained 801 in the JWE. When using the Compact Serialization, these five 802 values are represented in that order, separated by four period 803 ('.') characters. 805 2. The Encoded JWE Header, the Encoded JWE Encrypted Key, the 806 Encoded JWE Initialization Vector, the Encoded JWE Ciphertext, 807 and the Encoded JWE Integrity Value MUST be successfully 808 base64url decoded following the restriction that no padding 809 characters have been used. 811 3. The resulting JWE Header MUST be completely valid JSON syntax 812 conforming to RFC 4627 [RFC4627]. 814 4. The resulting JWE Header MUST be validated to only include 815 parameters and values whose syntax and semantics are both 816 understood and supported. 818 5. Verify that the JWE uses a key known to the recipient. 820 6. When key agreement is employed, use the key agreement algorithm 821 to compute the value of the agreed upon key. When key agreement 822 without key wrapping is employed, let the Content Master Key 823 (CMK) be the agreed upon key. When key agreement with key 824 wrapping is employed, the agreed upon key will be used to 825 decrypt the JWE Encrypted Key. 827 7. When key wrapping, key encryption, or key agreement with key 828 wrapping are employed, decrypt the JWE Encrypted Key to produce 829 the Content Master Key (CMK). The CMK MUST have a length equal 830 to that required for the block encryption algorithm. 832 8. When direct encryption with a shared symmetric key is employed, 833 let the Content Master Key (CMK) be the shared key. 835 9. Let the "additional authenticated data" value be the bytes of 836 the ASCII representation of the concatenation of the Encoded JWE 837 Header, a period ('.') character, the Encoded JWE Encrypted Key, 838 a second period character ('.'), and the Encoded JWE 839 Initialization Vector. 841 10. Decrypt the JWE Ciphertext using the CMK, the JWE Initialization 842 Vector, the "additional authenticated data" value, and the JWE 843 Integrity Value (which is the "authentication tag" input to the 844 calculation) using the specified block encryption algorithm, 845 returning the decrypted plaintext and verifying the JWE 846 Integrity Value in the manner specified for the algorithm, 847 rejecting the input without emitting any decrypted output if the 848 JWE Integrity Value is incorrect. 850 11. Uncompress the decrypted plaintext if a "zip" parameter was 851 included. 853 12. Output the resulting Plaintext. 855 5.3. String Comparison Rules 857 Processing a JWE inevitably requires comparing known strings to 858 values in JSON objects. For example, in checking what the encryption 859 method is, the Unicode string encoding "enc" will be checked against 860 the member names in the JWE Header to see if there is a matching 861 Header Parameter Name. 863 Comparisons between JSON strings and other Unicode strings MUST be 864 performed by comparing Unicode code points without normalization as 865 specified in the String Comparison Rules in Section 5.3 of [JWS]. 867 6. Encrypting JWEs with Cryptographic Algorithms 869 JWE uses cryptographic algorithms to encrypt the Plaintext and the 870 Content Encryption Key (CMK) and to provide integrity protection for 871 the JWE Header, JWE Encrypted Key, and JWE Ciphertext. The JSON Web 872 Algorithms (JWA) [JWA] specification specifies a set of cryptographic 873 algorithms and identifiers to be used with this specification and 874 defines registries for additional such algorithms. Specifically, 875 Section 4.1 specifies a set of "alg" (algorithm) header parameter 876 values and Section 4.2 specifies a set of "enc" (encryption method) 877 header parameter values intended for use this specification. It also 878 describes the semantics and operations that are specific to these 879 algorithms. 881 Public keys employed for encryption can be identified using the 882 Header Parameter methods described in Section 4.1 or can be 883 distributed using methods that are outside the scope of this 884 specification. 886 6.1. CMK Encryption 888 JWE supports three forms of Content Master Key (CMK) encryption: 890 o Asymmetric encryption under the recipient's public key. 892 o Symmetric encryption under a key shared between the sender and 893 receiver. 895 o Symmetric encryption under a key agreed upon between the sender 896 and receiver. 898 See the algorithms registered for "enc" usage in the IANA JSON Web 899 Signature and Encryption Algorithms registry [JWA] and Section 4.1 of 900 the JSON Web Algorithms (JWA) [JWA] specification for lists of 901 encryption algorithms that can be used for CMK encryption. 903 7. IANA Considerations 905 7.1. Registration of JWE Header Parameter Names 907 This specification registers the Header Parameter Names defined in 908 Section 4.1 in the IANA JSON Web Signature and Encryption Header 909 Parameters registry [JWS]. 911 7.1.1. Registry Contents 913 o Header Parameter Name: "alg" 914 o Header Parameter Usage Location(s): JWE 915 o Change Controller: IETF 916 o Specification Document(s): Section 4.1.1 of [[ this document ]] 918 o Header Parameter Name: "enc" 919 o Header Parameter Usage Location(s): JWE 920 o Change Controller: IETF 921 o Specification Document(s): Section 4.1.2 of [[ this document ]] 923 o Header Parameter Name: "epk" 924 o Header Parameter Usage Location(s): JWE 925 o Change Controller: IETF 926 o Specification Document(s): Section 4.1.3 of [[ this document ]] 928 o Header Parameter Name: "zip" 929 o Header Parameter Usage Location(s): JWE 930 o Change Controller: IETF 931 o Specification Document(s): Section 4.1.4 of [[ this document ]] 933 o Header Parameter Name: "jku" 934 o Header Parameter Usage Location(s): JWE 935 o Change Controller: IETF 936 o Specification Document(s): Section 4.1.5 of [[ this document ]] 938 o Header Parameter Name: "jwk" 939 o Header Parameter Usage Location(s): JWE 940 o Change Controller: IETF 941 o Specification document(s): Section 4.1.6 of [[ this document ]] 943 o Header Parameter Name: "x5u" 944 o Header Parameter Usage Location(s): JWE 945 o Change Controller: IETF 946 o Specification Document(s): Section 4.1.7 of [[ this document ]] 948 o Header Parameter Name: "x5t" 949 o Header Parameter Usage Location(s): JWE 950 o Change Controller: IETF 951 o Specification Document(s): Section 4.1.8 of [[ this document ]] 953 o Header Parameter Name: "x5c" 954 o Header Parameter Usage Location(s): JWE 955 o Change Controller: IETF 956 o Specification Document(s): Section 4.1.9 of [[ this document ]] 957 o Header Parameter Name: "kid" 958 o Header Parameter Usage Location(s): JWE 959 o Change Controller: IETF 960 o Specification Document(s): Section 4.1.10 of [[ this document ]] 962 o Header Parameter Name: "typ" 963 o Header Parameter Usage Location(s): JWE 964 o Change Controller: IETF 965 o Specification Document(s): Section 4.1.11 of [[ this document ]] 967 o Header Parameter Name: "cty" 968 o Header Parameter Usage Location(s): JWE 969 o Change Controller: IETF 970 o Specification Document(s): Section 4.1.12 of [[ this document ]] 972 o Header Parameter Name: "apu" 973 o Header Parameter Usage Location(s): JWE 974 o Change Controller: IETF 975 o Specification Document(s): Section 4.1.13 of [[ this document ]] 977 o Header Parameter Name: "apv" 978 o Header Parameter Usage Location(s): JWE 979 o Change Controller: IETF 980 o Specification Document(s): Section 4.1.14 of [[ this document ]] 982 o Header Parameter Name: "epu" 983 o Header Parameter Usage Location(s): JWE 984 o Change Controller: IETF 985 o Specification Document(s): Section 4.1.15 of [[ this document ]] 987 o Header Parameter Name: "epv" 988 o Header Parameter Usage Location(s): JWE 989 o Change Controller: IETF 990 o Specification Document(s): Section 4.1.16 of [[ this document ]] 992 7.2. JSON Web Signature and Encryption Type Values Registration 994 7.2.1. Registry Contents 996 This specification registers the "JWE" type value in the IANA JSON 997 Web Signature and Encryption Type Values registry [JWS]: 999 o "typ" Header Parameter Value: "JWE" 1000 o Abbreviation for MIME Type: application/jwe 1001 o Change Controller: IETF 1002 o Specification Document(s): Section 4.1.11 of [[ this document ]] 1004 7.3. Media Type Registration 1006 7.3.1. Registry Contents 1008 This specification registers the "application/jwe" Media Type 1009 [RFC2046] in the MIME Media Type registry [RFC4288] to indicate that 1010 the content is a JWE using the Compact Serialization. 1012 o Type Name: application 1013 o Subtype Name: jwe 1014 o Required Parameters: n/a 1015 o Optional Parameters: n/a 1016 o Encoding considerations: JWE values are encoded as a series of 1017 base64url encoded values (some of which may be the empty string) 1018 separated by period ('.') characters 1019 o Security Considerations: See the Security Considerations section 1020 of this document 1021 o Interoperability Considerations: n/a 1022 o Published Specification: [[ this document ]] 1023 o Applications that use this media type: OpenID Connect and other 1024 applications using encrypted JWTs 1025 o Additional Information: Magic number(s): n/a, File extension(s): 1026 n/a, Macintosh file type code(s): n/a 1027 o Person & email address to contact for further information: Michael 1028 B. Jones, mbj@microsoft.com 1029 o Intended Usage: COMMON 1030 o Restrictions on Usage: none 1031 o Author: Michael B. Jones, mbj@microsoft.com 1032 o Change Controller: IETF 1034 8. Security Considerations 1036 All of the security issues faced by any cryptographic application 1037 must be faced by a JWS/JWE/JWK agent. Among these issues are 1038 protecting the user's private and symmetric keys, preventing various 1039 attacks, and helping the user avoid mistakes such as inadvertently 1040 encrypting a message for the wrong recipient. The entire list of 1041 security considerations is beyond the scope of this document. 1043 All the security considerations in the JWS specification also apply 1044 to this specification. Likewise, all the security considerations in 1045 XML Encryption 1.1 [W3C.CR-xmlenc-core1-20120313] also apply to JWE, 1046 other than those that are XML specific. 1048 9. References 1049 9.1. Normative References 1051 [ITU.X690.1994] 1052 International Telecommunications Union, "Information 1053 Technology - ASN.1 encoding rules: Specification of Basic 1054 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1055 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1056 X.690, 1994. 1058 [JWA] Jones, M., "JSON Web Algorithms (JWA)", 1059 draft-ietf-jose-json-web-algorithms (work in progress), 1060 December 2012. 1062 [JWK] Jones, M., "JSON Web Key (JWK)", 1063 draft-ietf-jose-json-web-key (work in progress), 1064 December 2012. 1066 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1067 Signature (JWS)", draft-ietf-jose-json-web-signature (work 1068 in progress), December 2012. 1070 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1071 Mail: Part I: Message Encryption and Authentication 1072 Procedures", RFC 1421, February 1993. 1074 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1075 version 1.3", RFC 1951, May 1996. 1077 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1078 Extensions (MIME) Part Two: Media Types", RFC 2046, 1079 November 1996. 1081 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1082 Requirement Levels", BCP 14, RFC 2119, March 1997. 1084 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1086 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1087 10646", STD 63, RFC 3629, November 2003. 1089 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1090 Resource Identifier (URI): Generic Syntax", STD 66, 1091 RFC 3986, January 2005. 1093 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1094 Requirements for Security", BCP 106, RFC 4086, June 2005. 1096 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1097 Registration Procedures", BCP 13, RFC 4288, December 2005. 1099 [RFC4627] Crockford, D., "The application/json Media Type for 1100 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1102 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1103 Encodings", RFC 4648, October 2006. 1105 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1106 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1108 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1109 Housley, R., and W. Polk, "Internet X.509 Public Key 1110 Infrastructure Certificate and Certificate Revocation List 1111 (CRL) Profile", RFC 5280, May 2008. 1113 [W3C.CR-xmlenc-core1-20120313] 1114 Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, 1115 "XML Encryption Syntax and Processing Version 1.1", World 1116 Wide Web Consortium CR CR-xmlenc-core1-20120313, 1117 March 2012, 1118 . 1120 9.2. Informative References 1122 [I-D.rescorla-jsms] 1123 Rescorla, E. and J. Hildebrand, "JavaScript Message 1124 Security Format", draft-rescorla-jsms-00 (work in 1125 progress), March 2011. 1127 [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple 1128 Encryption", September 2010. 1130 [JWE-JS] Jones, M., "JSON Web Encryption JSON Serialization 1131 (JWE-JS)", draft-jones-jose-jwe-json-serialization (work 1132 in progress), December 2012. 1134 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1135 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1136 July 2005. 1138 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1139 RFC 5652, September 2009. 1141 Appendix A. JWE Examples 1143 This section provides examples of JWE computations. 1145 A.1. Example JWE using RSAES OAEP and AES GCM 1147 This example encrypts the plaintext "Live long and prosper." to the 1148 recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an 1149 integrated integrity check. The representation of this plaintext is: 1151 [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 1152 112, 114, 111, 115, 112, 101, 114, 46] 1154 A.1.1. JWE Header 1156 The following example JWE Header declares that: 1158 o the Content Master Key is encrypted to the recipient using the 1159 RSAES OAEP algorithm to produce the JWE Encrypted Key and 1161 o the Plaintext is encrypted using the AES GCM algorithm with a 256 1162 bit key to produce the Ciphertext. 1164 {"alg":"RSA-OAEP","enc":"A256GCM"} 1166 A.1.2. Encoded JWE Header 1168 Base64url encoding the bytes of the UTF-8 representation of the JWE 1169 Header yields this Encoded JWE Header value: 1171 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ 1173 A.1.3. Content Master Key (CMK) 1175 Generate a 256 bit random Content Master Key (CMK). In this example, 1176 the value is: 1178 [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 1179 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 1180 234, 64, 252] 1182 A.1.4. Key Encryption 1184 Encrypt the CMK with the recipient's public key using the RSAES OAEP 1185 algorithm to produce the JWE Encrypted Key. In this example, the RSA 1186 key parameters are: 1188 +-----------+-------------------------------------------------------+ 1189 | Parameter | Value | 1190 | Name | | 1191 +-----------+-------------------------------------------------------+ 1192 | Modulus | [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, | 1193 | | 110, 57, 30, 135, 227, 9, 31, 226, 128, 84, 92, 116, | 1194 | | 241, 70, 248, 27, 227, 193, 62, 5, 91, 241, 145, 224, | 1195 | | 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161, | 1196 | | 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, | 1197 | | 69, 78, 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, | 1198 | | 22, 167, 8, 212, 56, 35, 79, 210, 222, 192, 208, 252, | 1199 | | 49, 109, 138, 173, 253, 210, 166, 201, 63, 102, 74, | 1200 | | 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, | 1201 | | 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, | 1202 | | 121, 118, 196, 17, 146, 10, 244, 188, 72, 113, 55, | 1203 | | 221, 162, 217, 171, 27, 57, 233, 210, 101, 236, 154, | 1204 | | 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, | 1205 | | 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, | 1206 | | 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, 163, | 1207 | | 18, 180, 251, 58, 153, 46, 151, 174, 12, 103, 197, | 1208 | | 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, | 1209 | | 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, | 1210 | | 195, 20, 108, 202, 176, 214, 187, 45, 146, 182, 118, | 1211 | | 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37, | 1212 | | 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, | 1213 | | 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, | 1214 | | 190, 253, 186, 186, 27] | 1215 | Exponent | [1, 0, 1] | 1216 | Private | [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, | 1217 | Exponent | 66, 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, | 1218 | | 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191, | 1219 | | 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, | 1220 | | 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, | 1221 | | 231, 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, | 1222 | | 211, 245, 250, 112, 71, 243, 61, 129, 95, 39, 244, | 1223 | | 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, | 1224 | | 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, | 1225 | | 187, 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, | 1226 | | 1, 146, 43, 3, 108, 64, 194, 121, 182, 95, 187, 134, | 1227 | | 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, | 1228 | | 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, | 1229 | | 112, 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, | 1230 | | 157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241, | 1231 | | 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153, | 1232 | | 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, | 1233 | | 38, 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, | 1234 | | 131, 137, 175, 72, 126, 43, 229, 69, 179, 117, 82, | 1235 | | 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, | 1236 | | 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, | 1237 | | 210, 7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, | 1238 | | 224, 173, 56, 224, 201] | 1239 +-----------+-------------------------------------------------------+ 1241 The resulting JWE Encrypted Key value is: 1243 [51, 101, 241, 165, 179, 145, 41, 236, 202, 75, 60, 208, 47, 255, 1244 121, 248, 104, 226, 185, 212, 65, 78, 169, 255, 162, 100, 188, 207, 1245 220, 96, 161, 22, 251, 47, 66, 112, 229, 75, 4, 111, 25, 173, 200, 1246 121, 246, 79, 189, 102, 173, 146, 228, 142, 14, 12, 167, 200, 27, 1247 133, 138, 37, 180, 249, 4, 56, 123, 192, 162, 156, 246, 231, 235, 1248 217, 240, 45, 158, 213, 195, 154, 2, 142, 86, 61, 198, 210, 34, 225, 1249 92, 7, 128, 227, 4, 227, 55, 183, 69, 0, 59, 162, 71, 145, 98, 238, 1250 0, 70, 40, 123, 159, 37, 115, 18, 16, 157, 236, 138, 117, 166, 18, 1251 45, 181, 125, 112, 170, 168, 82, 129, 80, 166, 242, 150, 97, 17, 217, 1252 109, 251, 51, 35, 39, 236, 107, 95, 43, 154, 4, 227, 206, 187, 75, 1253 13, 51, 231, 115, 79, 67, 72, 145, 54, 225, 164, 60, 195, 120, 188, 1254 69, 113, 3, 182, 21, 189, 79, 82, 122, 46, 196, 199, 254, 252, 7, 1255 119, 5, 32, 144, 143, 173, 11, 99, 205, 120, 106, 231, 51, 231, 77, 1256 73, 252, 197, 221, 142, 254, 151, 7, 6, 203, 65, 108, 117, 121, 15, 1257 95, 43, 111, 13, 94, 242, 226, 150, 94, 121, 72, 144, 251, 69, 93, 1258 137, 178, 13, 216, 8, 227, 125, 110, 180, 157, 250, 207, 184, 232, 1259 222, 164, 193, 70, 232, 16, 65, 109, 29, 251, 164, 119, 50, 205, 236, 1260 109, 245, 234, 78, 1] 1262 A.1.5. Encoded JWE Encrypted Key 1264 Base64url encode the JWE Encrypted Key to produce the Encoded JWE 1265 Encrypted Key. This result (with line breaks for display purposes 1266 only) is: 1268 M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m 1269 rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA 1270 O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj 1271 zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN 1272 SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG 1273 6BBBbR37pHcyzext9epOAQ 1275 A.1.6. Initialization Vector 1277 Generate a random 96 bit JWE Initialization Vector. In this example, 1278 the value is: 1280 [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219] 1282 Base64url encoding this value yields the Encoded JWE Initialization 1283 Vector value: 1285 48V1_ALb6US04U3b 1287 A.1.7. "Additional Authenticated Data" Parameter 1289 Concatenate the Encoded JWE Header value, a period character ('.'), 1290 the Encoded JWE Encrypted Key, a second period character ('.'), and 1291 the Encoded JWE Initialization Vector to create the "additional 1292 authenticated data" parameter for the AES GCM algorithm. This result 1293 (with line breaks for display purposes only) is: 1295 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. 1296 M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m 1297 rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA 1298 O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj 1299 zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN 1300 SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG 1301 6BBBbR37pHcyzext9epOAQ. 1302 48V1_ALb6US04U3b 1304 The representation of this value is: 1306 [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 1307 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 1308 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81, 46, 1309 77, 50, 88, 120, 112, 98, 79, 82, 75, 101, 122, 75, 83, 122, 122, 81, 1310 76, 95, 57, 53, 45, 71, 106, 105, 117, 100, 82, 66, 84, 113, 110, 95, 1311 111, 109, 83, 56, 122, 57, 120, 103, 111, 82, 98, 55, 76, 48, 74, 1312 119, 53, 85, 115, 69, 98, 120, 109, 116, 121, 72, 110, 50, 84, 55, 1313 49, 109, 114, 90, 76, 107, 106, 103, 52, 77, 112, 56, 103, 98, 104, 1314 89, 111, 108, 116, 80, 107, 69, 79, 72, 118, 65, 111, 112, 122, 50, 1315 53, 45, 118, 90, 56, 67, 50, 101, 49, 99, 79, 97, 65, 111, 53, 87, 1316 80, 99, 98, 83, 73, 117, 70, 99, 66, 52, 68, 106, 66, 79, 77, 51, 1317 116, 48, 85, 65, 79, 54, 74, 72, 107, 87, 76, 117, 65, 69, 89, 111, 1318 101, 53, 56, 108, 99, 120, 73, 81, 110, 101, 121, 75, 100, 97, 89, 1319 83, 76, 98, 86, 57, 99, 75, 113, 111, 85, 111, 70, 81, 112, 118, 75, 1320 87, 89, 82, 72, 90, 98, 102, 115, 122, 73, 121, 102, 115, 97, 49, 56, 1321 114, 109, 103, 84, 106, 122, 114, 116, 76, 68, 84, 80, 110, 99, 48, 1322 57, 68, 83, 74, 69, 50, 52, 97, 81, 56, 119, 51, 105, 56, 82, 88, 69, 1323 68, 116, 104, 87, 57, 84, 49, 74, 54, 76, 115, 84, 72, 95, 118, 119, 1324 72, 100, 119, 85, 103, 107, 73, 45, 116, 67, 50, 80, 78, 101, 71, 1325 114, 110, 77, 45, 100, 78, 83, 102, 122, 70, 51, 89, 55, 45, 108, 1326 119, 99, 71, 121, 48, 70, 115, 100, 88, 107, 80, 88, 121, 116, 118, 1327 68, 86, 55, 121, 52, 112, 90, 101, 101, 85, 105, 81, 45, 48, 86, 100, 1328 105, 98, 73, 78, 50, 65, 106, 106, 102, 87, 54, 48, 110, 102, 114, 1329 80, 117, 79, 106, 101, 112, 77, 70, 71, 54, 66, 66, 66, 98, 82, 51, 1330 55, 112, 72, 99, 121, 122, 101, 120, 116, 57, 101, 112, 79, 65, 81, 1331 46, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85, 83, 48, 52, 85, 51, 98] 1333 A.1.8. Plaintext Encryption 1335 Encrypt the Plaintext with AES GCM using the CMK as the encryption 1336 key, the JWE Initialization Vector, and the "additional authenticated 1337 data" value above, requesting a 128 bit "authentication tag" output. 1338 The resulting Ciphertext is: 1340 [253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 1341 246, 116, 195, 212, 102, 37, 36, 175] 1343 The resulting "authentication tag" value is: 1345 [237, 94, 89, 14, 74, 52, 191, 249, 159, 216, 240, 28, 224, 147, 34, 1346 82] 1348 A.1.9. Encoded JWE Ciphertext 1350 Base64url encode the resulting Ciphertext to create the Encoded JWE 1351 Ciphertext. This result is: 1353 _e21tGGhac_peEFkLXr2dMPUZiUkrw 1355 A.1.10. Encoded JWE Integrity Value 1357 Base64url encode the resulting "authentication tag" to create the 1358 Encoded JWE Integrity Value. This result is: 1360 7V5ZDko0v_mf2PAc4JMiUg 1362 A.1.11. Complete Representation 1364 Assemble the final representation: The Compact Serialization of this 1365 result is the concatenation of the Encoded JWE Header, the Encoded 1366 JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded 1367 JWE Ciphertext, and the Encoded JWE Integrity Value in that order, 1368 with the five strings being separated by four period ('.') 1369 characters. 1371 The final result in this example (with line breaks for display 1372 purposes only) is: 1374 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. 1375 M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m 1376 rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA 1377 O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj 1378 zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN 1379 SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG 1380 6BBBbR37pHcyzext9epOAQ. 1381 48V1_ALb6US04U3b. 1382 _e21tGGhac_peEFkLXr2dMPUZiUkrw. 1383 7V5ZDko0v_mf2PAc4JMiUg 1385 A.1.12. Validation 1387 This example illustrates the process of creating a JWE with an 1388 Authenticated Encryption algorithm. These results can be used to 1389 validate JWE decryption implementations for these algorithms. Note 1390 that since the RSAES OAEP computation includes random values, the 1391 encryption results above will not be completely reproducible. 1392 However, since the AES GCM computation is deterministic, the JWE 1393 Encrypted Ciphertext values will be the same for all encryptions 1394 performed using these inputs. 1396 A.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC 1398 This example encrypts the plaintext "No matter where you go, there 1399 you are." to the recipient using RSAES-PKCS1-V1_5 and AES CBC. AES 1400 CBC does not have an integrated integrity check, so a separate 1401 integrity check calculation is performed using HMAC SHA-256, with 1402 separate encryption and integrity keys being derived from a master 1403 key using the Concat KDF with the SHA-256 digest function. The 1404 representation of this plaintext is: 1406 [78, 111, 32, 109, 97, 116, 116, 101, 114, 32, 119, 104, 101, 114, 1407 101, 32, 121, 111, 117, 32, 103, 111, 44, 32, 116, 104, 101, 114, 1408 101, 32, 121, 111, 117, 32, 97, 114, 101, 46] 1410 A.2.1. JWE Header 1412 The following example JWE Header (with line breaks for display 1413 purposes only) declares that: 1415 o the Content Master Key is encrypted to the recipient using the 1416 RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and 1418 o the Plaintext is encrypted using the AES CBC algorithm with a 128 1419 bit key to produce the Ciphertext, with the integrity of the 1420 Ciphertext and the parameters used to create it being secured with 1421 the HMAC SHA-256 algorithm. 1423 {"alg":"RSA1_5","enc":"A128CBC+HS256"} 1425 A.2.2. Encoded JWE Header 1427 Base64url encoding the bytes of the UTF-8 representation of the JWE 1428 Header yields this Encoded JWE Header value: 1430 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0 1432 A.2.3. Content Master Key (CMK) 1434 Generate a 256 bit random Content Master Key (CMK). In this example, 1435 the key value is: 1437 [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 1438 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 1439 44, 207] 1441 A.2.4. Key Encryption 1443 Encrypt the CMK with the recipient's public key using the RSAES- 1444 PKCS1-V1_5 algorithm to produce the JWE Encrypted Key. In this 1445 example, the RSA key parameters are: 1447 +-----------+-------------------------------------------------------+ 1448 | Parameter | Value | 1449 | Name | | 1450 +-----------+-------------------------------------------------------+ 1451 | Modulus | [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, | 1452 | | 242, 12, 224, 19, 226, 198, 134, 17, 71, 173, 75, 42, | 1453 | | 61, 48, 162, 206, 161, 97, 108, 185, 234, 226, 219, | 1454 | | 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, | 1455 | | 6, 224, 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, | 1456 | | 4, 85, 220, 144, 215, 110, 130, 17, 68, 228, 129, | 1457 | | 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, 124, | 1458 | | 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, | 1459 | | 73, 211, 113, 9, 33, 178, 80, 13, 25, 21, 25, 153, | 1460 | | 212, 206, 67, 154, 147, 70, 194, 192, 183, 160, 83, | 1461 | | 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, | 1462 | | 253, 206, 32, 179, 254, 236, 190, 82, 73, 67, 129, | 1463 | | 253, 252, 220, 108, 136, 138, 11, 192, 1, 36, 239, | 1464 | | 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, | 1465 | | 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, | 1466 | | 92, 112, 72, 99, 97, 26, 87, 187, 123, 46, 50, 90, | 1467 | | 202, 117, 73, 10, 153, 47, 224, 178, 163, 77, 48, 46, | 1468 | | 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, | 1469 | | 127, 68, 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, | 1470 | | 254, 85, 55, 75, 213, 86, 194, 218, 215, 163, 189, | 1471 | | 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, 35, 66, | 1472 | | 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, | 1473 | | 239, 71] | 1474 | Exponent | [1, 0, 1] | 1475 | Private | [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, | 1476 | Exponent | 154, 36, 181, 221, 156, 211, 215, 100, 164, 90, 88, | 1477 | | 40, 228, 83, 148, 54, 122, 4, 16, 165, 48, 76, 194, | 1478 | | 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, | 1479 | | 56, 97, 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, | 1480 | | 214, 252, 120, 67, 180, 167, 3, 82, 243, 25, 97, 214, | 1481 | | 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, 164, 187, | 1482 | | 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, | 1483 | | 45, 148, 58, 23, 62, 227, 74, 52, 117, 42, 90, 41, | 1484 | | 249, 130, 154, 80, 119, 61, 26, 193, 40, 125, 10, | 1485 | | 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, 99, | 1486 | | 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, | 1487 | | 69, 1, 80, 171, 167, 20, 196, 156, 109, 249, 88, 0, | 1488 | | 3, 152, 38, 165, 72, 87, 6, 152, 71, 156, 214, 16, | 1489 | | 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, | 1490 | | 91, 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, | 1491 | | 135, 105, 127, 84, 171, 181, 152, 210, 183, 126, 24, | 1492 | | 46, 196, 90, 173, 38, 245, 219, 186, 222, 27, 240, | 1493 | | 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, | 1494 | | 65, 224, 81, 100, 85, 25, 204, 165, 203, 187, 175, | 1495 | | 84, 100, 82, 15, 11, 23, 202, 151, 107, 54, 41, 207, | 1496 | | 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, | 1497 | | 130, 89] | 1498 +-----------+-------------------------------------------------------+ 1500 The resulting JWE Encrypted Key value is: 1502 [102, 105, 229, 169, 104, 35, 95, 42, 176, 142, 190, 220, 92, 124, 1503 172, 240, 94, 253, 106, 114, 20, 35, 162, 118, 81, 103, 64, 201, 20, 1504 4, 112, 96, 84, 248, 163, 199, 177, 227, 204, 247, 93, 63, 70, 132, 1505 195, 26, 237, 72, 91, 141, 3, 159, 71, 111, 113, 213, 68, 142, 146, 1506 92, 60, 243, 72, 111, 53, 156, 51, 16, 226, 215, 125, 68, 141, 232, 1507 62, 111, 197, 98, 91, 150, 23, 230, 132, 93, 97, 216, 145, 226, 3, 1508 18, 12, 48, 119, 153, 185, 8, 156, 195, 84, 21, 63, 143, 43, 144, 1509 174, 101, 25, 199, 7, 106, 212, 43, 151, 225, 62, 225, 122, 92, 90, 1510 139, 45, 144, 134, 229, 15, 235, 38, 110, 132, 189, 236, 126, 92, 1511 183, 13, 64, 2, 77, 107, 95, 186, 8, 133, 53, 217, 104, 247, 152, 1512 241, 49, 199, 15, 111, 110, 123, 16, 13, 78, 193, 224, 23, 230, 133, 1513 220, 162, 126, 82, 192, 236, 7, 185, 100, 106, 21, 70, 93, 192, 255, 1514 252, 139, 61, 124, 81, 140, 113, 97, 164, 231, 131, 167, 246, 157, 1515 199, 195, 114, 122, 49, 121, 115, 63, 114, 12, 165, 11, 186, 3, 108, 1516 12, 199, 101, 29, 226, 80, 56, 193, 149, 45, 134, 146, 102, 221, 202, 1517 63, 166, 150, 53, 42, 133, 3, 83, 199, 14, 15, 181, 209, 199, 174, 1518 76, 75, 106, 254, 243, 196, 227, 225, 173, 122, 254, 13, 224, 174, 4, 1519 185, 217, 99, 225] 1521 A.2.5. Encoded JWE Encrypted Key 1523 Base64url encode the JWE Encrypted Key to produce the Encoded JWE 1524 Encrypted Key. This result (with line breaks for display purposes 1525 only) is: 1527 ZmnlqWgjXyqwjr7cXHys8F79anIUI6J2UWdAyRQEcGBU-KPHsePM910_RoTDGu1I 1528 W40Dn0dvcdVEjpJcPPNIbzWcMxDi131Ejeg-b8ViW5YX5oRdYdiR4gMSDDB3mbkI 1529 nMNUFT-PK5CuZRnHB2rUK5fhPuF6XFqLLZCG5Q_rJm6Evex-XLcNQAJNa1-6CIU1 1530 2Wj3mPExxw9vbnsQDU7B4BfmhdyiflLA7Ae5ZGoVRl3A__yLPXxRjHFhpOeDp_ad 1531 x8NyejF5cz9yDKULugNsDMdlHeJQOMGVLYaSZt3KP6aWNSqFA1PHDg-10ceuTEtq 1532 _vPE4-Gtev4N4K4Eudlj4Q 1534 A.2.6. Key Derivation 1536 Use the Concat key derivation function to derive Content Encryption 1537 Key (CEK) and Content Integrity Key (CIK) values from the CMK. The 1538 details of this derivation are shown in Appendix A.4. The resulting 1539 CEK value is: 1541 [203, 165, 180, 113, 62, 195, 22, 98, 91, 153, 210, 38, 112, 35, 230, 1542 236] 1544 The resulting CIK value is: 1546 [218, 24, 160, 17, 160, 50, 235, 35, 216, 209, 100, 174, 155, 163, 1547 10, 117, 180, 111, 172, 200, 127, 201, 206, 173, 40, 45, 58, 170, 35, 1548 93, 9, 60] 1550 A.2.7. Initialization Vector 1552 Generate a random 128 bit JWE Initialization Vector. In this 1553 example, the value is: 1555 [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 1556 101] 1558 Base64url encoding this value yields the Encoded JWE Initialization 1559 Vector value: 1561 AxY8DCtDaGlsbGljb3RoZQ 1563 A.2.8. Plaintext Encryption 1565 Encrypt the Plaintext with AES CBC using the CEK and the JWE 1566 Initialization Vector to produce the Ciphertext. The resulting 1567 Ciphertext is: 1569 [71, 27, 35, 131, 163, 200, 19, 23, 38, 25, 33, 123, 46, 116, 132, 1570 144, 58, 150, 32, 167, 192, 195, 92, 25, 207, 101, 233, 105, 181, 1571 121, 63, 4, 44, 162, 82, 176, 17, 171, 150, 97, 147, 68, 245, 13, 97, 1572 100, 145, 25] 1574 A.2.9. Encoded JWE Ciphertext 1576 Base64url encode the resulting Ciphertext to create the Encoded JWE 1577 Ciphertext. This result is: 1579 Rxsjg6PIExcmGSF7LnSEkDqWIKfAw1wZz2XpabV5PwQsolKwEauWYZNE9Q1hZJEZ 1581 A.2.10. Secured Input Value 1583 Concatenate the Encoded JWE Header value, a period character ('.'), 1584 the Encoded JWE Encrypted Key, a second period character, the Encoded 1585 JWE Initialization Vector, a third period ('.') character, and the 1586 Encoded JWE Ciphertext to create the value to integrity protect. 1587 This result (with line breaks for display purposes only) is: 1589 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0. 1590 ZmnlqWgjXyqwjr7cXHys8F79anIUI6J2UWdAyRQEcGBU-KPHsePM910_RoTDGu1I 1591 W40Dn0dvcdVEjpJcPPNIbzWcMxDi131Ejeg-b8ViW5YX5oRdYdiR4gMSDDB3mbkI 1592 nMNUFT-PK5CuZRnHB2rUK5fhPuF6XFqLLZCG5Q_rJm6Evex-XLcNQAJNa1-6CIU1 1593 2Wj3mPExxw9vbnsQDU7B4BfmhdyiflLA7Ae5ZGoVRl3A__yLPXxRjHFhpOeDp_ad 1594 x8NyejF5cz9yDKULugNsDMdlHeJQOMGVLYaSZt3KP6aWNSqFA1PHDg-10ceuTEtq 1595 _vPE4-Gtev4N4K4Eudlj4Q. 1596 AxY8DCtDaGlsbGljb3RoZQ. 1597 Rxsjg6PIExcmGSF7LnSEkDqWIKfAw1wZz2XpabV5PwQsolKwEauWYZNE9Q1hZJEZ 1599 The representation of this value is: 1601 [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 1602 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 1603 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 75, 48, 104, 84, 77, 106, 85, 1604 50, 73, 110, 48, 46, 90, 109, 110, 108, 113, 87, 103, 106, 88, 121, 1605 113, 119, 106, 114, 55, 99, 88, 72, 121, 115, 56, 70, 55, 57, 97, 1606 110, 73, 85, 73, 54, 74, 50, 85, 87, 100, 65, 121, 82, 81, 69, 99, 1607 71, 66, 85, 45, 75, 80, 72, 115, 101, 80, 77, 57, 49, 48, 95, 82, 1608 111, 84, 68, 71, 117, 49, 73, 87, 52, 48, 68, 110, 48, 100, 118, 99, 1609 100, 86, 69, 106, 112, 74, 99, 80, 80, 78, 73, 98, 122, 87, 99, 77, 1610 120, 68, 105, 49, 51, 49, 69, 106, 101, 103, 45, 98, 56, 86, 105, 87, 1611 53, 89, 88, 53, 111, 82, 100, 89, 100, 105, 82, 52, 103, 77, 83, 68, 1612 68, 66, 51, 109, 98, 107, 73, 110, 77, 78, 85, 70, 84, 45, 80, 75, 1613 53, 67, 117, 90, 82, 110, 72, 66, 50, 114, 85, 75, 53, 102, 104, 80, 1614 117, 70, 54, 88, 70, 113, 76, 76, 90, 67, 71, 53, 81, 95, 114, 74, 1615 109, 54, 69, 118, 101, 120, 45, 88, 76, 99, 78, 81, 65, 74, 78, 97, 1616 49, 45, 54, 67, 73, 85, 49, 50, 87, 106, 51, 109, 80, 69, 120, 120, 1617 119, 57, 118, 98, 110, 115, 81, 68, 85, 55, 66, 52, 66, 102, 109, 1618 104, 100, 121, 105, 102, 108, 76, 65, 55, 65, 101, 53, 90, 71, 111, 1619 86, 82, 108, 51, 65, 95, 95, 121, 76, 80, 88, 120, 82, 106, 72, 70, 1620 104, 112, 79, 101, 68, 112, 95, 97, 100, 120, 56, 78, 121, 101, 106, 1621 70, 53, 99, 122, 57, 121, 68, 75, 85, 76, 117, 103, 78, 115, 68, 77, 1622 100, 108, 72, 101, 74, 81, 79, 77, 71, 86, 76, 89, 97, 83, 90, 116, 1623 51, 75, 80, 54, 97, 87, 78, 83, 113, 70, 65, 49, 80, 72, 68, 103, 45, 1624 49, 48, 99, 101, 117, 84, 69, 116, 113, 95, 118, 80, 69, 52, 45, 71, 1625 116, 101, 118, 52, 78, 52, 75, 52, 69, 117, 100, 108, 106, 52, 81, 1626 46, 65, 120, 89, 56, 68, 67, 116, 68, 97, 71, 108, 115, 98, 71, 108, 1627 106, 98, 51, 82, 111, 90, 81, 46, 82, 120, 115, 106, 103, 54, 80, 73, 1628 69, 120, 99, 109, 71, 83, 70, 55, 76, 110, 83, 69, 107, 68, 113, 87, 1629 73, 75, 102, 65, 119, 49, 119, 90, 122, 50, 88, 112, 97, 98, 86, 53, 1630 80, 119, 81, 115, 111, 108, 75, 119, 69, 97, 117, 87, 89, 90, 78, 69, 1631 57, 81, 49, 104, 90, 74, 69, 90] 1633 A.2.11. JWE Integrity Value 1635 Compute the HMAC SHA-256 of this value using the CIK to create the 1636 JWE Integrity Value. This result is: 1638 [240, 181, 234, 49, 221, 9, 44, 107, 49, 49, 160, 121, 186, 131, 90, 1639 50, 152, 59, 185, 69, 191, 167, 141, 17, 149, 166, 71, 11, 3, 8, 203, 1640 57] 1642 A.2.12. Encoded JWE Integrity Value 1644 Base64url encode the resulting JWE Integrity Value to create the 1645 Encoded JWE Integrity Value. This result is: 1647 8LXqMd0JLGsxMaB5uoNaMpg7uUW_p40RlaZHCwMIyzk 1649 A.2.13. Complete Representation 1651 Assemble the final representation: The Compact Serialization of this 1652 result is the concatenation of the Encoded JWE Header, the Encoded 1653 JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded 1654 JWE Ciphertext, and the Encoded JWE Integrity Value in that order, 1655 with the five strings being separated by four period ('.') 1656 characters. 1658 The final result in this example (with line breaks for display 1659 purposes only) is: 1661 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0. 1662 ZmnlqWgjXyqwjr7cXHys8F79anIUI6J2UWdAyRQEcGBU-KPHsePM910_RoTDGu1I 1663 W40Dn0dvcdVEjpJcPPNIbzWcMxDi131Ejeg-b8ViW5YX5oRdYdiR4gMSDDB3mbkI 1664 nMNUFT-PK5CuZRnHB2rUK5fhPuF6XFqLLZCG5Q_rJm6Evex-XLcNQAJNa1-6CIU1 1665 2Wj3mPExxw9vbnsQDU7B4BfmhdyiflLA7Ae5ZGoVRl3A__yLPXxRjHFhpOeDp_ad 1666 x8NyejF5cz9yDKULugNsDMdlHeJQOMGVLYaSZt3KP6aWNSqFA1PHDg-10ceuTEtq 1667 _vPE4-Gtev4N4K4Eudlj4Q. 1668 AxY8DCtDaGlsbGljb3RoZQ. 1669 Rxsjg6PIExcmGSF7LnSEkDqWIKfAw1wZz2XpabV5PwQsolKwEauWYZNE9Q1hZJEZ. 1670 8LXqMd0JLGsxMaB5uoNaMpg7uUW_p40RlaZHCwMIyzk 1672 A.2.14. Validation 1674 This example illustrates the process of creating a JWE with a 1675 composite Authenticated Encryption algorithm created from a non- 1676 Authenticated Encryption algorithm by adding a separate integrity 1677 check calculation. These results can be used to validate JWE 1678 decryption implementations for these algorithms. Note that since the 1679 RSAES-PKCS1-V1_5 computation includes random values, the encryption 1680 results above will not be completely reproducible. However, since 1681 the AES CBC computation is deterministic, the JWE Encrypted 1682 Ciphertext values will be the same for all encryptions performed 1683 using these inputs. 1685 A.3. Example JWE using AES Key Wrap and AES GCM 1687 This example encrypts the plaintext "The true sign of intelligence is 1688 not knowledge but imagination." to the recipient using AES Key Wrap 1689 and AES GCM. The representation of this plaintext is: 1691 [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 1692 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 1693 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 1694 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 1695 110, 97, 116, 105, 111, 110, 46] 1697 A.3.1. JWE Header 1699 The following example JWE Header declares that: 1701 o the Content Master Key is encrypted to the recipient using the AES 1702 Key Wrap algorithm with a 128 bit key to produce the JWE Encrypted 1703 Key and 1705 o the Plaintext is encrypted using the AES GCM algorithm with a 128 1706 bit key to produce the Ciphertext. 1708 {"alg":"A128KW","enc":"A128GCM"} 1710 A.3.2. Encoded JWE Header 1712 Base64url encoding the bytes of the UTF-8 representation of the JWE 1713 Header yields this Encoded JWE Header value: 1715 eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIn0 1717 A.3.3. Content Master Key (CMK) 1719 Generate a 128 bit random Content Master Key (CMK). In this example, 1720 the value is: 1722 [64, 154, 239, 170, 64, 40, 195, 99, 19, 84, 192, 142, 192, 238, 207, 1723 217] 1725 A.3.4. Key Encryption 1727 Encrypt the CMK with the shared symmetric key using the AES Key Wrap 1728 algorithm to produce the JWE Encrypted Key. In this example, the 1729 shared symmetric key value is: 1731 [25, 172, 32, 130, 225, 114, 26, 181, 138, 106, 254, 192, 95, 133, 1732 74, 82] 1734 The resulting JWE Encrypted Key value is: 1736 [164, 255, 251, 1, 64, 200, 65, 200, 34, 197, 81, 143, 43, 211, 240, 1737 38, 191, 161, 181, 117, 119, 68, 44, 80] 1739 A.3.5. Encoded JWE Encrypted Key 1741 Base64url encode the JWE Encrypted Key to produce the Encoded JWE 1742 Encrypted Key. This result is: 1744 pP_7AUDIQcgixVGPK9PwJr-htXV3RCxQ 1746 A.3.6. Initialization Vector 1748 Generate a random 96 bit JWE Initialization Vector. In this example, 1749 the value is: 1751 [253, 220, 80, 25, 166, 152, 178, 168, 97, 99, 67, 89] 1753 Base64url encoding this value yields the Encoded JWE Initialization 1754 Vector value: 1756 _dxQGaaYsqhhY0NZ 1758 A.3.7. "Additional Authenticated Data" Parameter 1760 Concatenate the Encoded JWE Header value, a period character ('.'), 1761 the Encoded JWE Encrypted Key, a second period character ('.'), and 1762 the Encoded JWE Initialization Vector to create the "additional 1763 authenticated data" parameter for the AES GCM algorithm. This result 1764 (with line breaks for display purposes only) is: 1766 eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIn0. 1767 pP_7AUDIQcgixVGPK9PwJr-htXV3RCxQ. 1768 _dxQGaaYsqhhY0NZ 1770 The representation of this value is: 1772 [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 1773 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 1774 77, 84, 73, 52, 82, 48, 78, 78, 73, 110, 48, 46, 112, 80, 95, 55, 65, 1775 85, 68, 73, 81, 99, 103, 105, 120, 86, 71, 80, 75, 57, 80, 119, 74, 1776 114, 45, 104, 116, 88, 86, 51, 82, 67, 120, 81, 46, 95, 100, 120, 81, 1777 71, 97, 97, 89, 115, 113, 104, 104, 89, 48, 78, 90] 1779 A.3.8. Plaintext Encryption 1781 Encrypt the Plaintext with AES GCM using the CMK as the encryption 1782 key, the JWE Initialization Vector, and the "additional authenticated 1783 data" value above, requesting a 128 bit "authentication tag" output. 1784 The resulting Ciphertext is: 1786 [227, 12, 89, 132, 185, 16, 248, 93, 145, 87, 53, 130, 95, 115, 62, 1787 104, 138, 96, 109, 71, 124, 211, 165, 103, 202, 99, 21, 193, 4, 226, 1788 84, 229, 254, 106, 144, 241, 39, 86, 148, 132, 160, 104, 88, 232, 1789 228, 109, 85, 7, 86, 80, 134, 106, 166, 24, 92, 199, 210, 188, 153, 1790 187, 218, 69, 227] 1792 The resulting "authentication tag" value is: 1794 [154, 35, 80, 107, 37, 148, 81, 6, 103, 4, 60, 206, 171, 165, 113, 1795 67] 1797 A.3.9. Encoded JWE Ciphertext 1799 Base64url encode the resulting Ciphertext to create the Encoded JWE 1800 Ciphertext. This result (with line breaks for display purposes only) 1801 is: 1803 4wxZhLkQ-F2RVzWCX3M-aIpgbUd806VnymMVwQTiVOX-apDxJ1aUhKBoWOjkbVUH 1804 VlCGaqYYXMfSvJm72kXj 1806 A.3.10. Encoded JWE Integrity Value 1808 Base64url encode the resulting "authentication tag" to create the 1809 Encoded JWE Integrity Value. This result is: 1811 miNQayWUUQZnBDzOq6VxQw 1813 A.3.11. Complete Representation 1815 Assemble the final representation: The Compact Serialization of this 1816 result is the concatenation of the Encoded JWE Header, the Encoded 1817 JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded 1818 JWE Ciphertext, and the Encoded JWE Integrity Value in that order, 1819 with the five strings being separated by four period ('.') 1820 characters. 1822 The final result in this example (with line breaks for display 1823 purposes only) is: 1825 eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIn0. 1826 pP_7AUDIQcgixVGPK9PwJr-htXV3RCxQ. 1827 _dxQGaaYsqhhY0NZ. 1828 4wxZhLkQ-F2RVzWCX3M-aIpgbUd806VnymMVwQTiVOX-apDxJ1aUhKBoWOjkbVUH 1829 VlCGaqYYXMfSvJm72kXj. 1830 miNQayWUUQZnBDzOq6VxQw 1832 A.3.12. Validation 1834 This example illustrates the process of creating a JWE with symmetric 1835 key wrap and an Authenticated Encryption algorithm. These results 1836 can be used to validate JWE decryption implementations for these 1837 algorithms. Also, since both the AES Key Wrap and AES GCM 1838 computations are deterministic, the resulting JWE value will be the 1839 same for all encryptions performed using these inputs. Since the 1840 computation is reproducible, these results can also be used to 1841 validate JWE encryption implementations for these algorithms. 1843 A.4. Example Key Derivation for "enc" value "A128CBC+HS256" 1845 This example uses the Concat KDF to derive the Content Encryption Key 1846 (CEK) and Content Integrity Key (CIK) from the Content Master Key 1847 (CMK) in the manner described in Section 4.8.1 of [JWA]. In this 1848 example, a 256 bit CMK is used to derive a 128 bit CEK and a 256 bit 1849 CIK. 1851 The CMK value used is: 1853 [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 1854 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 1855 44, 207] 1857 A.4.1. CEK Generation 1859 These values are concatenated to produce the round 1 hash input: 1861 o the round number 1 as a 32 bit big endian integer ([0, 0, 0, 1]), 1863 o the CMK value (as above), 1865 o the output bit size 128 as a 32 bit big endian number ([0, 0, 0, 1866 128]), 1868 o the bytes of the UTF-8 representation of the "enc" value 1869 "A128CBC+HS256" -- [65, 49, 50, 56, 67, 66, 67, 43, 72, 83, 50, 1870 53, 54], 1872 o the Datalen value of zero for the omitted "epu" (encryption 1873 PartyUInfo) value ([0, 0, 0, 0]), 1875 o the Datalen value of zero for the omitted "epv" (encryption 1876 PartyVInfo) value ([0, 0, 0, 0]), 1878 o the bytes of the ASCII representation of the label "Encryption" -- 1879 [69, 110, 99, 114, 121, 112, 116, 105, 111, 110]. 1881 Thus the round 1 hash input is: 1883 [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 1884 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 1885 240, 143, 156, 44, 207, 0, 0, 0, 128, 65, 49, 50, 56, 67, 66, 67, 43, 1886 72, 83, 50, 53, 54, 0, 0, 0, 0, 0, 0, 0, 0, 69, 110, 99, 114, 121, 1887 112, 116, 105, 111, 110] 1889 The SHA-256 hash of this value, which is the round 1 hash output, is: 1891 [203, 165, 180, 113, 62, 195, 22, 98, 91, 153, 210, 38, 112, 35, 230, 1892 236, 181, 193, 129, 233, 251, 107, 70, 80, 36, 150, 216, 251, 182, 1893 29, 104, 150] 1895 Given that 128 bits are needed for the CEK and the hash has produced 1896 256 bits, the CEK value is the first 128 bits of that value: 1898 [203, 165, 180, 113, 62, 195, 22, 98, 91, 153, 210, 38, 112, 35, 230, 1899 236] 1901 A.4.2. CIK Generation 1903 These values are concatenated to produce the round 1 hash input: 1905 o the round number 1 as a 32 bit big endian integer ([0, 0, 0, 1]), 1907 o the CMK value (as above), 1909 o the output bit size 256 as a 32 bit big endian number ([0, 0, 1, 1910 0]), 1912 o the bytes of the UTF-8 representation of the "enc" value 1913 "A128CBC+HS256" -- [65, 49, 50, 56, 67, 66, 67, 43, 72, 83, 50, 1914 53, 54], 1916 o the Datalen value of zero for the omitted "epu" (encryption 1917 PartyUInfo) value ([0, 0, 0, 0]), 1919 o the Datalen value of zero for the omitted "epv" (encryption 1920 PartyVInfo) value ([0, 0, 0, 0]), 1922 o the bytes of the ASCII representation of the label "Integrity" -- 1923 [73, 110, 116, 101, 103, 114, 105, 116, 121]. 1925 Thus the round 1 hash input is: 1927 [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 1928 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 1929 240, 143, 156, 44, 207, 0, 0, 1, 0, 65, 49, 50, 56, 67, 66, 67, 43, 1930 72, 83, 50, 53, 54, 0, 0, 0, 0, 0, 0, 0, 0, 73, 110, 116, 101, 103, 1931 114, 105, 116, 121] 1933 The SHA-256 hash of this value, which is the round 1 hash output, is: 1935 [218, 24, 160, 17, 160, 50, 235, 35, 216, 209, 100, 174, 155, 163, 1936 10, 117, 180, 111, 172, 200, 127, 201, 206, 173, 40, 45, 58, 170, 35, 1937 93, 9, 60] 1939 Given that 256 bits are needed for the CIK and the hash has produced 1940 256 bits, the CIK value is that same value: 1942 [218, 24, 160, 17, 160, 50, 235, 35, 216, 209, 100, 174, 155, 163, 1943 10, 117, 180, 111, 172, 200, 127, 201, 206, 173, 40, 45, 58, 170, 35, 1944 93, 9, 60] 1946 A.5. Example Key Derivation for "enc" value "A256CBC+HS512" 1948 This example uses the Concat KDF to derive the Content Encryption Key 1949 (CEK) and Content Integrity Key (CIK) from the Content Master Key 1950 (CMK) in the manner described in Section 4.8.1 of [JWA]. In this 1951 example, a 512 bit CMK is used to derive a 256 bit CEK and a 512 bit 1952 CIK. 1954 The CMK value used is: 1956 [148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 1957 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 1958 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 1959 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 1960 249, 7, 225, 168] 1962 A.5.1. CEK Generation 1964 These values are concatenated to produce the round 1 hash input: 1966 o the round number 1 as a 32 bit big endian integer ([0, 0, 0, 1]), 1968 o the CMK value (as above), 1970 o the output bit size 256 as a 32 bit big endian number ([0, 0, 1, 1971 0]), 1973 o the bytes of the UTF-8 representation of the "enc" value 1974 "A256CBC+HS512" -- [65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 53, 1975 49, 50], 1977 o the Datalen value of zero for the omitted "epu" (encryption 1978 PartyUInfo) value ([0, 0, 0, 0]), 1980 o the Datalen value of zero for the omitted "epv" (encryption 1981 PartyVInfo) value ([0, 0, 0, 0]), 1983 o the bytes of the ASCII representation of the label "Encryption" -- 1984 [69, 110, 99, 114, 121, 112, 116, 105, 111, 110]. 1986 Thus the round 1 hash input is: 1988 [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 1989 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 1990 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 1991 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 1992 45, 156, 249, 7, 225, 168, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 1993 43, 72, 83, 53, 49, 50, 0, 0, 0, 0, 0, 0, 0, 0, 69, 110, 99, 114, 1994 121, 112, 116, 105, 111, 110] 1996 The SHA-512 hash of this value, which is the round 1 hash output, is: 1998 [157, 19, 75, 205, 31, 190, 110, 46, 117, 217, 137, 19, 116, 166, 1999 126, 60, 18, 244, 226, 114, 38, 153, 78, 198, 26, 0, 181, 168, 113, 2000 45, 149, 89, 107, 213, 109, 183, 207, 164, 86, 131, 51, 105, 214, 29, 2001 229, 32, 243, 46, 40, 53, 123, 4, 13, 7, 250, 48, 227, 207, 167, 211, 2002 147, 91, 0, 171] 2004 Given that 256 bits are needed for the CEK and the hash has produced 2005 512 bits, the CEK value is the first 256 bits of that value: 2007 [157, 19, 75, 205, 31, 190, 110, 46, 117, 217, 137, 19, 116, 166, 2008 126, 60, 18, 244, 226, 114, 38, 153, 78, 198, 26, 0, 181, 168, 113, 2009 45, 149, 89] 2011 A.5.2. CIK Generation 2013 These values are concatenated to produce the round 1 hash input: 2015 o the round number 1 as a 32 bit big endian integer ([0, 0, 0, 1]), 2017 o the CMK value (as above), 2019 o the output bit size 512 as a 32 bit big endian number ([0, 0, 2, 2020 0]), 2022 o the bytes of the UTF-8 representation of the "enc" value 2023 "A256CBC+HS512" -- [65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 53, 2024 49, 50], 2026 o the Datalen value of zero for the omitted "epu" (encryption 2027 PartyUInfo) value ([0, 0, 0, 0]), 2029 o the Datalen value of zero for the omitted "epv" (encryption 2030 PartyVInfo) value ([0, 0, 0, 0]), 2032 o the bytes of the ASCII representation of the label "Integrity" -- 2033 [73, 110, 116, 101, 103, 114, 105, 116, 121]. 2035 Thus the round 1 hash input is: 2037 [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 2038 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 2039 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 2040 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 2041 45, 156, 249, 7, 225, 168, 0, 0, 2, 0, 65, 50, 53, 54, 67, 66, 67, 2042 43, 72, 83, 53, 49, 50, 0, 0, 0, 0, 0, 0, 0, 0, 73, 110, 116, 101, 2043 103, 114, 105, 116, 121] 2045 The SHA-512 hash of this value, which is the round 1 hash output, is: 2047 [81, 249, 131, 194, 25, 166, 147, 155, 47, 249, 146, 160, 200, 236, 2048 115, 72, 103, 248, 228, 30, 130, 225, 164, 61, 105, 172, 198, 31, 2049 137, 170, 215, 141, 27, 247, 73, 236, 125, 113, 151, 33, 0, 251, 72, 2050 53, 72, 63, 146, 117, 247, 13, 49, 20, 210, 169, 232, 156, 118, 1, 2051 16, 45, 29, 21, 15, 208] 2053 Given that 512 bits are needed for the CIK and the hash has produced 2054 512 bits, the CIK value is that same value: 2056 [81, 249, 131, 194, 25, 166, 147, 155, 47, 249, 146, 160, 200, 236, 2057 115, 72, 103, 248, 228, 30, 130, 225, 164, 61, 105, 172, 198, 31, 2058 137, 170, 215, 141, 27, 247, 73, 236, 125, 113, 151, 33, 0, 251, 72, 2059 53, 72, 63, 146, 117, 247, 13, 49, 20, 210, 169, 232, 156, 118, 1, 2060 16, 45, 29, 21, 15, 208] 2062 Appendix B. Acknowledgements 2064 Solutions for encrypting JSON content were also explored by JSON 2065 Simple Encryption [JSE] and JavaScript Message Security Format 2066 [I-D.rescorla-jsms], both of which significantly influenced this 2067 draft. This draft attempts to explicitly reuse as many of the 2068 relevant concepts from XML Encryption 1.1 2069 [W3C.CR-xmlenc-core1-20120313] and RFC 5652 [RFC5652] as possible, 2070 while utilizing simple compact JSON-based data structures. 2072 Special thanks are due to John Bradley and Nat Sakimura for the 2073 discussions that helped inform the content of this specification and 2074 to Eric Rescorla and Joe Hildebrand for allowing the reuse of text 2075 from [I-D.rescorla-jsms] in this document. 2077 Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund 2078 Jay for validating the examples in this specification. 2080 This specification is the work of the JOSE Working Group, which 2081 includes dozens of active and dedicated participants. In particular, 2082 the following individuals contributed ideas, feedback, and wording 2083 that influenced this specification: 2085 Richard Barnes, John Bradley, Brian Campbell, Breno de Medeiros, Dick 2086 Hardt, Jeff Hodges, Edmund Jay, James Manger, Tony Nadalin, Axel 2087 Nennker, Emmanuel Raviart, Nat Sakimura, Jim Schaad, Hannes 2088 Tschofenig, and Sean Turner. 2090 Jim Schaad and Karen O'Donoghue chaired the JOSE working group and 2091 Sean Turner and Stephen Farrell served as Security area directors 2092 during the creation of this specification. 2094 Appendix C. Open Issues 2096 [[ to be removed by the RFC editor before publication as an RFC ]] 2098 The following items remain to be considered or done in this draft: 2100 o Should all header fields continue to be required to be understood 2101 by implementations using them or should a means of declaring that 2102 specific header fields may be safely ignored if not understood 2103 should be defined? 2105 Appendix D. Document History 2107 [[ to be removed by the RFC editor before publication as an RFC ]] 2109 -08 2111 o Replaced uses of the term "AEAD" with "Authenticated Encryption", 2112 since the term AEAD in the RFC 5116 sense implied the use of a 2113 particular data representation, rather than just referring to the 2114 class of algorithms that perform authenticated encryption with 2115 associated data. 2117 o Applied editorial improvements suggested by Jeff Hodges and Hannes 2118 Tschofenig. Many of these simplified the terminology used. 2120 o Clarified statements of the form "This header parameter is 2121 OPTIONAL" to "Use of this header parameter is OPTIONAL". 2123 o Added a Header Parameter Usage Location(s) field to the IANA JSON 2124 Web Signature and Encryption Header Parameters registry. 2126 o Added seriesInfo information to Internet Draft references. 2128 -07 2130 o Added a data length prefix to PartyUInfo and PartyVInfo values. 2132 o Updated values for example AES CBC calculations. 2134 o Made several local editorial changes to clean up loose ends left 2135 over from to the decision to only support block encryption methods 2136 providing integrity. One of these changes was to explicitly state 2137 that the "enc" (encryption method) algorithm must be an 2138 Authenticated Encryption algorithm with a specified key length. 2140 -06 2142 o Removed the "int" and "kdf" parameters and defined the new 2143 composite Authenticated Encryption algorithms "A128CBC+HS256" and 2144 "A256CBC+HS512" to replace the former uses of AES CBC, which 2145 required the use of separate integrity and key derivation 2146 functions. 2148 o Included additional values in the Concat KDF calculation -- the 2149 desired output size and the algorithm value, and optionally 2150 PartyUInfo and PartyVInfo values. Added the optional header 2151 parameters "apu" (agreement PartyUInfo), "apv" (agreement 2152 PartyVInfo), "epu" (encryption PartyUInfo), and "epv" (encryption 2153 PartyVInfo). Updated the KDF examples accordingly. 2155 o Promoted Initialization Vector from being a header parameter to 2156 being a top-level JWE element. This saves approximately 16 bytes 2157 in the compact serialization, which is a significant savings for 2158 some use cases. Promoting the Initialization Vector out of the 2159 header also avoids repeating this shared value in the JSON 2160 serialization. 2162 o Changed "x5c" (X.509 Certificate Chain) representation from being 2163 a single string to being an array of strings, each containing a 2164 single base64 encoded DER certificate value, representing elements 2165 of the certificate chain. 2167 o Added an AES Key Wrap example. 2169 o Reordered the encryption steps so CMK creation is first, when 2170 required. 2172 o Correct statements in examples about which algorithms produce 2173 reproducible results. 2175 -05 2177 o Support both direct encryption using a shared or agreed upon 2178 symmetric key, and the use of a shared or agreed upon symmetric 2179 key to key wrap the CMK. 2181 o Added statement that "StringOrURI values are compared as case- 2182 sensitive strings with no transformations or canonicalizations 2183 applied". 2185 o Updated open issues. 2187 o Indented artwork elements to better distinguish them from the body 2188 text. 2190 -04 2192 o Refer to the registries as the primary sources of defined values 2193 and then secondarily reference the sections defining the initial 2194 contents of the registries. 2196 o Normatively reference XML Encryption 1.1 2197 [W3C.CR-xmlenc-core1-20120313] for its security considerations. 2199 o Reference draft-jones-jose-jwe-json-serialization instead of 2200 draft-jones-json-web-encryption-json-serialization. 2202 o Described additional open issues. 2204 o Applied editorial suggestions. 2206 -03 2208 o Added the "kdf" (key derivation function) header parameter to 2209 provide crypto agility for key derivation. The default KDF 2210 remains the Concat KDF with the SHA-256 digest function. 2212 o Reordered encryption steps so that the Encoded JWE Header is 2213 always created before it is needed as an input to the 2214 Authenticated Encryption "additional authenticated data" 2215 parameter. 2217 o Added the "cty" (content type) header parameter for declaring type 2218 information about the secured content, as opposed to the "typ" 2219 (type) header parameter, which declares type information about 2220 this object. 2222 o Moved description of how to determine whether a header is for a 2223 JWS or a JWE from the JWT spec to the JWE spec. 2225 o Added complete encryption examples for both Authenticated 2226 Encryption and non-Authenticated Encryption algorithms. 2228 o Added complete key derivation examples. 2230 o Added "Collision Resistant Namespace" to the terminology section. 2232 o Reference ITU.X690.1994 for DER encoding. 2234 o Added Registry Contents sections to populate registry values. 2236 o Numerous editorial improvements. 2238 -02 2240 o When using Authenticated Encryption algorithms (such as AES GCM), 2241 use the "additional authenticated data" parameter to provide 2242 integrity for the header, encrypted key, and ciphertext and use 2243 the resulting "authentication tag" value as the JWE Integrity 2244 Value. 2246 o Defined KDF output key sizes. 2248 o Generalized text to allow key agreement to be employed as an 2249 alternative to key wrapping or key encryption. 2251 o Changed compression algorithm from gzip to DEFLATE. 2253 o Clarified that it is an error when a "kid" value is included and 2254 no matching key is found. 2256 o Clarified that JWEs with duplicate Header Parameter Names MUST be 2257 rejected. 2259 o Clarified the relationship between "typ" header parameter values 2260 and MIME types. 2262 o Registered application/jwe MIME type and "JWE" typ header 2263 parameter value. 2265 o Simplified JWK terminology to get replace the "JWK Key Object" and 2266 "JWK Container Object" terms with simply "JSON Web Key (JWK)" and 2267 "JSON Web Key Set (JWK Set)" and to eliminate potential confusion 2268 between single keys and sets of keys. As part of this change, the 2269 Header Parameter Name for a public key value was changed from 2270 "jpk" (JSON Public Key) to "jwk" (JSON Web Key). 2272 o Added suggestion on defining additional header parameters such as 2273 "x5t#S256" in the future for certificate thumbprints using hash 2274 algorithms other than SHA-1. 2276 o Specify RFC 2818 server identity validation, rather than RFC 6125 2277 (paralleling the same decision in the OAuth specs). 2279 o Generalized language to refer to Message Authentication Codes 2280 (MACs) rather than Hash-based Message Authentication Codes (HMACs) 2281 unless in a context specific to HMAC algorithms. 2283 o Reformatted to give each header parameter its own section heading. 2285 -01 2287 o Added an integrity check for non-Authenticated Encryption 2288 algorithms. 2290 o Added "jpk" and "x5c" header parameters for including JWK public 2291 keys and X.509 certificate chains directly in the header. 2293 o Clarified that this specification is defining the JWE Compact 2294 Serialization. Referenced the new JWE-JS spec, which defines the 2295 JWE JSON Serialization. 2297 o Added text "New header parameters should be introduced sparingly 2298 since an implementation that does not understand a parameter MUST 2299 reject the JWE". 2301 o Clarified that the order of the encryption and decryption steps is 2302 not significant in cases where there are no dependencies between 2303 the inputs and outputs of the steps. 2305 o Made other editorial improvements suggested by JOSE working group 2306 participants. 2308 -00 2310 o Created the initial IETF draft based upon 2311 draft-jones-json-web-encryption-02 with no normative changes. 2313 o Changed terminology to no longer call both digital signatures and 2314 HMACs "signatures". 2316 Authors' Addresses 2318 Michael B. Jones 2319 Microsoft 2321 Email: mbj@microsoft.com 2322 URI: http://self-issued.info/ 2323 Eric Rescorla 2324 RTFM, Inc. 2326 Email: ekr@rtfm.com 2328 Joe Hildebrand 2329 Cisco Systems, Inc. 2331 Email: jhildebr@cisco.com