idnits 2.17.00 (12 Aug 2021) /tmp/idnits25416/draft-ietf-jose-json-web-encryption-04.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 (July 16, 2012) is 3595 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 1774 -- Looks like a reference, but probably isn't: '0' on line 1819 -- Looks like a reference, but probably isn't: '69' on line 1772 -- Looks like a reference, but probably isn't: '110' on line 1772 -- Looks like a reference, but probably isn't: '99' on line 1772 -- Looks like a reference, but probably isn't: '114' on line 1772 -- Looks like a reference, but probably isn't: '121' on line 1772 -- Looks like a reference, but probably isn't: '112' on line 1772 -- Looks like a reference, but probably isn't: '116' on line 1772 -- Looks like a reference, but probably isn't: '105' on line 1772 -- Looks like a reference, but probably isn't: '111' on line 1772 -- Looks like a reference, but probably isn't: '2' on line 1819 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWS' ** 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 (~~), 1 warning (==), 17 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: January 17, 2013 RTFM 6 J. Hildebrand 7 Cisco 8 July 16, 2012 10 JSON Web Encryption (JWE) 11 draft-ietf-jose-json-web-encryption-04 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 January 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 6 60 3.1. Example JWE with an Integrated Integrity Check . . . . . . 6 61 3.2. Example JWE with a Separate Integrity Check . . . . . . . 8 62 4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 10 64 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 11 65 4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 11 66 4.1.3. "int" (Integrity Algorithm) Header Parameter . . . . . 11 67 4.1.4. "kdf" (Key Derivation Function) Header Parameter . . . 12 68 4.1.5. "iv" (Initialization Vector) Header Parameter . . . . 12 69 4.1.6. "epk" (Ephemeral Public Key) Header Parameter . . . . 12 70 4.1.7. "zip" (Compression Algorithm) Header Parameter . . . . 12 71 4.1.8. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 13 72 4.1.9. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13 73 4.1.10. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13 74 4.1.11. "x5t" (X.509 Certificate Thumbprint) Header 75 Parameter . . . . . . . . . . . . . . . . . . . . . . 13 76 4.1.12. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14 77 4.1.13. "kid" (Key ID) Header Parameter . . . . . . . . . . . 14 78 4.1.14. "typ" (Type) Header Parameter . . . . . . . . . . . . 14 79 4.1.15. "cty" (Content Type) Header Parameter . . . . . . . . 15 80 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 15 81 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 15 82 5. Message Encryption . . . . . . . . . . . . . . . . . . . . . . 15 83 6. Message Decryption . . . . . . . . . . . . . . . . . . . . . . 17 84 7. CMK Encryption . . . . . . . . . . . . . . . . . . . . . . . . 18 85 8. Integrity Value Calculation . . . . . . . . . . . . . . . . . 18 86 9. Encrypting JWEs with Cryptographic Algorithms . . . . . . . . 19 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 10.1. Registration of JWE Header Parameter Names . . . . . . . . 19 89 10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 19 90 10.2. JSON Web Signature and Encryption Type Values 91 Registration . . . . . . . . . . . . . . . . . . . . . . . 21 92 10.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 93 10.3. Media Type Registration . . . . . . . . . . . . . . . . . 22 94 10.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 99 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 100 Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 26 101 A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 26 102 A.1.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 26 103 A.1.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 26 104 A.1.3. Content Master Key (CMK) . . . . . . . . . . . . . . . 26 105 A.1.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 27 106 A.1.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 29 107 A.1.6. "Additional Authenticated Data" Parameter . . . . . . 29 108 A.1.7. Plaintext Encryption . . . . . . . . . . . . . . . . . 30 109 A.1.8. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 30 110 A.1.9. Encoded JWE Integrity Value . . . . . . . . . . . . . 30 111 A.1.10. Complete Representation . . . . . . . . . . . . . . . 30 112 A.1.11. Validation . . . . . . . . . . . . . . . . . . . . . . 31 113 A.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC . . . . . . 31 114 A.2.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 31 115 A.2.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 32 116 A.2.3. Content Master Key (CMK) . . . . . . . . . . . . . . . 32 117 A.2.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 32 118 A.2.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 35 119 A.2.6. Key Derivation . . . . . . . . . . . . . . . . . . . . 35 120 A.2.7. Plaintext Encryption . . . . . . . . . . . . . . . . . 35 121 A.2.8. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 35 122 A.2.9. Secured Input Value . . . . . . . . . . . . . . . . . 36 123 A.2.10. JWE Integrity Value . . . . . . . . . . . . . . . . . 37 124 A.2.11. Encoded JWE Integrity Value . . . . . . . . . . . . . 37 125 A.2.12. Complete Representation . . . . . . . . . . . . . . . 37 126 A.2.13. Validation . . . . . . . . . . . . . . . . . . . . . . 37 127 A.3. Example Key Derivation with Outputs <= Hash Size . . . . . 38 128 A.3.1. CEK Generation . . . . . . . . . . . . . . . . . . . . 38 129 A.3.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 38 130 A.4. Example Key Derivation with Outputs >= Hash Size . . . . . 39 131 A.4.1. CEK Generation . . . . . . . . . . . . . . . . . . . . 39 132 A.4.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 40 133 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41 134 Appendix C. Document History . . . . . . . . . . . . . . . . . . 41 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 137 1. Introduction 139 JSON Web Encryption (JWE) is a compact encryption format intended for 140 space constrained environments such as HTTP Authorization headers and 141 URI query parameters. It represents this content using JavaScript 142 Object Notation (JSON) [RFC4627] based data structures. The JWE 143 cryptographic mechanisms encrypt and provide integrity protection for 144 arbitrary sequences of bytes. 146 Cryptographic algorithms and identifiers for use with this 147 specification are described in the separate JSON Web Algorithms (JWA) 148 [JWA] specification. Related digital signature and MAC capabilities 149 are described in the separate JSON Web Signature (JWS) [JWS] 150 specification. 152 1.1. Notational Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in Key words for use in 157 RFCs to Indicate Requirement Levels [RFC2119]. 159 2. Terminology 161 JSON Web Encryption (JWE) A data structure representing an encrypted 162 message. The structure consists of four parts: the JWE Header, 163 the JWE Encrypted Key, the JWE Ciphertext, and the JWE Integrity 164 Value. 166 Plaintext The bytes to be encrypted - a.k.a., the message. The 167 plaintext can contain an arbitrary sequence of bytes. 169 Ciphertext An encrypted representation of the Plaintext. 171 Content Encryption Key (CEK) A symmetric key used to encrypt the 172 Plaintext for the recipient to produce the Ciphertext. 174 Content Integrity Key (CIK) A key used with a MAC function to ensure 175 the integrity of the Ciphertext and the parameters used to create 176 it. 178 Content Master Key (CMK) A key from which the CEK and CIK are 179 derived. When key wrapping or key encryption are employed, the 180 CMK is randomly generated and encrypted to the recipient as the 181 JWE Encrypted Key. When key agreement is employed, the CMK is the 182 result of the key agreement algorithm. 184 JWE Header A string representing a JSON object that describes the 185 encryption operations applied to create the JWE Encrypted Key, the 186 JWE Ciphertext, and the JWE Integrity Value. 188 JWE Encrypted Key When key wrapping or key encryption are employed, 189 the Content Master Key (CMK) is encrypted with the intended 190 recipient's key and the resulting encrypted content is recorded as 191 a byte array, which is referred to as the JWE Encrypted Key. 192 Otherwise, when key agreement is employed, the JWE Encrypted Key 193 is the empty byte array. 195 JWE Ciphertext A byte array containing the Ciphertext. 197 JWE Integrity Value A byte array containing a MAC value that ensures 198 the integrity of the Ciphertext and the parameters used to create 199 it. 201 Base64url Encoding The URL- and filename-safe Base64 encoding 202 described in RFC 4648 [RFC4648], Section 5, with the (non URL- 203 safe) '=' padding characters omitted, as permitted by Section 3.2. 204 (See Appendix C of [JWS] for notes on implementing base64url 205 encoding without padding.) 207 Encoded JWE Header Base64url encoding of the bytes of the UTF-8 208 [RFC3629] representation of the JWE Header. 210 Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted 211 Key. 213 Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext. 215 Encoded JWE Integrity Value Base64url encoding of the JWE Integrity 216 Value. 218 Header Parameter Name The name of a member of the JSON object 219 representing a JWE Header. 221 Header Parameter Value The value of a member of the JSON object 222 representing a JWE Header. 224 JWE Compact Serialization A representation of the JWE as the 225 concatenation of the Encoded JWE Header, the Encoded JWE Encrypted 226 Key, the Encoded JWE Ciphertext, and the Encoded JWE Integrity 227 Value in that order, with the four strings being separated by 228 period ('.') characters. 230 AEAD Algorithm An Authenticated Encryption with Associated Data 231 (AEAD) [RFC5116] encryption algorithm is one that provides an 232 integrated content integrity check. AES Galois/Counter Mode (GCM) 233 is one such algorithm. 235 Collision Resistant Namespace A namespace that allows names to be 236 allocated in a manner such that they are highly unlikely to 237 collide with other names. For instance, collision resistance can 238 be achieved through administrative delegation of portions of the 239 namespace or through use of collision-resistant name allocation 240 functions. Examples of Collision Resistant Namespaces include: 241 Domain Names, Object Identifiers (OIDs) as defined in the ITU-T 242 X.660 and X.670 Recommendation series, and Universally Unique 243 IDentifiers (UUIDs) [RFC4122]. When using an administratively 244 delegated namespace, the definer of a name needs to take 245 reasonable precautions to ensure they are in control of the 246 portion of the namespace they use to define the name. 248 StringOrURI A JSON string value, with the additional requirement 249 that while arbitrary string values MAY be used, any value 250 containing a ":" character MUST be a URI [RFC3986]. 252 3. JSON Web Encryption (JWE) Overview 254 JWE represents encrypted content using JSON data structures and 255 base64url encoding. The representation consists of four parts: the 256 JWE Header, the JWE Encrypted Key, the JWE Ciphertext, and the JWE 257 Integrity Value. In the Compact Serialization, the four parts are 258 base64url-encoded for transmission, and represented as the 259 concatenation of the encoded strings in that order, with the four 260 strings being separated by period ('.') characters. (A JSON 261 Serialization for this information is defined in the separate JSON 262 Web Encryption JSON Serialization (JWE-JS) [JWE-JS] specification.) 264 JWE utilizes encryption to ensure the confidentiality of the 265 Plaintext. JWE adds a content integrity check if not provided by the 266 underlying encryption algorithm. 268 3.1. Example JWE with an Integrated Integrity Check 270 This example encrypts the plaintext "Live long and prosper." to the 271 recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an 272 integrated integrity check. 274 The following example JWE Header declares that: 276 o the Content Master Key is encrypted to the recipient using the 277 RSAES OAEP algorithm to produce the JWE Encrypted Key, 279 o the Plaintext is encrypted using the AES GCM algorithm with a 256 280 bit key to produce the Ciphertext, and 282 o the 96 bit Initialization Vector (IV) with the base64url encoding 283 "48V1_ALb6US04U3b" was used. 285 {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} 287 Base64url encoding the bytes of the UTF-8 representation of the JWE 288 Header yields this Encoded JWE Header value (with line breaks for 289 display purposes only): 290 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxi 291 NlVTMDRVM2IifQ 293 The remaining steps to finish creating this JWE are: 295 o Generate a random Content Master Key (CMK) 297 o Encrypt the CMK with the recipient's public key using the RSAES 298 OAEP algorithm to produce the JWE Encrypted Key 300 o Base64url encode the JWE Encrypted Key to produce the Encoded JWE 301 Encrypted Key 303 o Concatenate the Encoded JWE Header value, a period character 304 ('.'), and the Encoded JWE Encrypted Key to create the "additional 305 authenticated data" parameter for the AES GCM algorithm. 307 o Encrypt the Plaintext with AES GCM, using the IV, the CMK as the 308 encryption key, and the "additional authenticated data" value 309 above, requesting a 128 bit "authentication tag" output 311 o Base64url encode the resulting Ciphertext to create the Encoded 312 JWE Ciphertext 314 o Base64url encode the resulting "authentication tag" to create the 315 Encoded JWE Integrity Value 317 o Assemble the final representation: The Compact Serialization of 318 this result is the concatenation of the Encoded JWE Header, the 319 Encoded JWE Encrypted Key, the Encoded JWE Ciphertext, and the 320 Encoded JWE Integrity Value in that order, with the four strings 321 being separated by three period ('.') characters. 323 The final result in this example (with line breaks for display 324 purposes only) is: 325 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxi 326 NlVTMDRVM2IifQ. 327 jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcR 328 Q8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva 329 w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxN 330 NmXCflYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkA 331 AIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7L 332 e_l5_o-taUG7vaNAl5FjEQ. 333 _e21tGGhac_peEFkLXr2dMPUZiUkrw. 334 YbZSeHCNDZBqAdzpROlyiw 336 See Appendix A.1 for the complete details of computing this JWE. 338 3.2. Example JWE with a Separate Integrity Check 340 This example encrypts the plaintext "Now is the time for all good men 341 to come to the aid of their country." to the recipient using RSAES- 342 PKCS1-V1_5 and AES CBC. AES CBC does not have an integrated 343 integrity check, so a separate integrity check calculation is 344 performed using HMAC SHA-256, with separate encryption and integrity 345 keys being derived from a master key using the Concat KDF with the 346 SHA-256 digest function. 348 The following example JWE Header (with line breaks for display 349 purposes only) declares that: 351 o the Content Master Key is encrypted to the recipient using the 352 RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key, 354 o the Plaintext is encrypted using the AES CBC algorithm with a 128 355 bit key to produce the Ciphertext, 357 o the JWE Integrity Value safeguarding the integrity of the 358 Ciphertext and the parameters used to create it was computed with 359 the HMAC SHA-256 algorithm, and 361 o the 128 bit Initialization Vector (IV) with the base64url encoding 362 "AxY8DCtDaGlsbGljb3RoZQ" was used. 364 {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGls 365 bGljb3RoZQ"} 367 Base64url encoding the bytes of the UTF-8 representation of the JWE 368 Header yields this Encoded JWE Header value (with line breaks for 369 display purposes only): 370 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp 371 diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ 372 The remaining steps to finish creating this JWE are like the previous 373 example, but with an additional step to compute the separate 374 integrity value: 376 o Generate a random Content Master Key (CMK) 378 o Encrypt the CMK with the recipient's public key using the RSAES- 379 PKCS1-V1_5 algorithm to produce the JWE Encrypted Key 381 o Base64url encode the JWE Encrypted Key to produce the Encoded JWE 382 Encrypted Key 384 o Use the Concat key derivation function to derive Content 385 Encryption Key (CEK) and Content Integrity Key (CIK) values from 386 the CMK 388 o Encrypt the Plaintext with AES CBC using the CEK and IV to produce 389 the Ciphertext 391 o Base64url encode the resulting Ciphertext to create the Encoded 392 JWE Ciphertext 394 o Concatenate the Encoded JWE Header value, a period character 395 ('.'), the Encoded JWE Encrypted Key, a second period character, 396 and the Encoded JWE Ciphertext to create the value to integrity 397 protect 399 o Compute the HMAC SHA-256 of this value using the CIK to create the 400 JWE Integrity Value 402 o Base64url encode the resulting JWE Integrity Value to create the 403 Encoded JWE Integrity Value 405 o Assemble the final representation: The Compact Serialization of 406 this result is the concatenation of the Encoded JWE Header, the 407 Encoded JWE Encrypted Key, the Encoded JWE Ciphertext, and the 408 Encoded JWE Integrity Value in that order, with the four strings 409 being separated by three period ('.') characters. 411 The final result in this example (with line breaks for display 412 purposes only) is: 414 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp 415 diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ. 416 IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQ 417 XtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfK 418 KZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz 419 2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9 420 h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK 421 -3T1zYlOIiIKBjsExQKZ-w. 422 _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdF 423 LjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M. 424 c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k 426 See Appendix A.2 for the complete details of computing this JWE. 428 4. JWE Header 430 The members of the JSON object represented by the JWE Header describe 431 the encryption applied to the Plaintext and optionally additional 432 properties of the JWE. The Header Parameter Names within this object 433 MUST be unique; JWEs with duplicate Header Parameter Names MUST be 434 rejected. Implementations MUST understand the entire contents of the 435 header; otherwise, the JWE MUST be rejected. 437 There are two ways of distinguishing whether a header is a JWS Header 438 or a JWE Header. The first is by examining the "alg" (algorithm) 439 header value. If the value represents a digital signature or MAC 440 algorithm, or is the value "none", it is for a JWS; if it represents 441 an encryption or key agreement algorithm, it is for a JWE. A second 442 method is determining whether an "enc" (encryption method) member 443 exists. If the "enc" member exists, it is a JWE; otherwise, it is a 444 JWS. Both methods will yield the same result. 446 There are three classes of Header Parameter Names: Reserved Header 447 Parameter Names, Public Header Parameter Names, and Private Header 448 Parameter Names. 450 4.1. Reserved Header Parameter Names 452 The following header parameter names are reserved with meanings as 453 defined below. All the names are short because a core goal of JWE is 454 for the representations to be compact. 456 Additional reserved header parameter names MAY be defined via the 457 IANA JSON Web Signature and Encryption Header Parameters registry 458 [JWS]. As indicated by the common registry, JWSs and JWEs share a 459 common header parameter space; when a parameter is used by both 460 specifications, its usage must be compatible between the 461 specifications. 463 4.1.1. "alg" (Algorithm) Header Parameter 465 The "alg" (algorithm) header parameter identifies the cryptographic 466 algorithm used to encrypt or reach agreement upon the Content Master 467 Key (CMK). The algorithm specified by the "alg" value MUST be 468 supported by the implementation and there MUST be a key for use with 469 that algorithm associated with the intended recipient or the JWE MUST 470 be rejected. "alg" values SHOULD either be registered in the IANA 471 JSON Web Signature and Encryption Algorithms registry [JWA] or be a 472 URI that contains a Collision Resistant Namespace. The "alg" value 473 is a case sensitive string containing a StringOrURI value. This 474 header parameter is REQUIRED. 476 A list of defined "alg" values can be found in the IANA JSON Web 477 Signature and Encryption Algorithms registry [JWA]; the initial 478 contents of this registry is the values defined in Section 4.1 of the 479 JSON Web Algorithms (JWA) [JWA] specification. 481 4.1.2. "enc" (Encryption Method) Header Parameter 483 The "enc" (encryption method) header parameter identifies the 484 symmetric encryption algorithm used to encrypt the Plaintext to 485 produce the Ciphertext. The algorithm specified by the "enc" value 486 MUST be supported by the implementation or the JWE MUST be rejected. 487 "enc" values SHOULD either be registered in the IANA JSON Web 488 Signature and Encryption Algorithms registry [JWA] or be a URI that 489 contains a Collision Resistant Namespace. The "enc" value is a case 490 sensitive string containing a StringOrURI value. This header 491 parameter is REQUIRED. 493 A list of defined "enc" values can be found in the IANA JSON Web 494 Signature and Encryption Algorithms registry [JWA]; the initial 495 contents of this registry is the values defined in Section 4.2 of the 496 JSON Web Algorithms (JWA) [JWA] specification. 498 4.1.3. "int" (Integrity Algorithm) Header Parameter 500 The "int" (integrity algorithm) header parameter identifies the 501 cryptographic algorithm used to safeguard the integrity of the 502 Ciphertext and the parameters used to create it. The "int" parameter 503 uses the MAC subset of the algorithm values used by the JWS "alg" 504 parameter. "int" values SHOULD either be registered in the IANA JSON 505 Web Signature and Encryption Algorithms registry [JWA] or be a URI 506 that contains a Collision Resistant Namespace. The "int" value is a 507 case sensitive string containing a StringOrURI value. This header 508 parameter is REQUIRED when an AEAD algorithm is not used to encrypt 509 the Plaintext and MUST NOT be present when an AEAD algorithm is used. 511 A list of defined "int" values can be found in the IANA JSON Web 512 Signature and Encryption Algorithms registry [JWA]; the initial 513 contents of this registry is the values defined in Section 4.3 of the 514 JSON Web Algorithms (JWA) [JWA] specification. 516 4.1.4. "kdf" (Key Derivation Function) Header Parameter 518 The "kdf" (key derivation function) header parameter identifies the 519 cryptographic algorithm used to derive the CEK and CIK from the CMK. 520 "kdf" values SHOULD either be registered in the IANA JSON Web 521 Signature and Encryption Algorithms registry [JWA] or be a URI that 522 contains a Collision Resistant Namespace. The "kdf" value is a case 523 sensitive string containing a StringOrURI value. This header 524 parameter is OPTIONAL when an AEAD algorithm is not used to encrypt 525 the Plaintext and MUST NOT be present when an AEAD algorithm is used. 527 When an AEAD algorithm is not used and no "kdf" header parameter is 528 present, the "CS256" KDF [JWA] SHALL be used. 530 A list of defined "kdf" values can be found in the IANA JSON Web 531 Signature and Encryption Algorithms registry [JWA]; the initial 532 contents of this registry is the values defined in Section 4.4 of the 533 JSON Web Algorithms (JWA) [JWA] specification. 535 4.1.5. "iv" (Initialization Vector) Header Parameter 537 The "iv" (initialization vector) value for algorithms requiring it, 538 represented as a base64url encoded string. This header parameter is 539 OPTIONAL, although its use is REQUIRED with some "enc" algorithms. 541 4.1.6. "epk" (Ephemeral Public Key) Header Parameter 543 The "epk" (ephemeral public key) value created by the originator for 544 the use in key agreement algorithms. This key is represented as a 545 JSON Web Key [JWK] value. This header parameter is OPTIONAL, 546 although its use is REQUIRED with some "alg" algorithms. 548 4.1.7. "zip" (Compression Algorithm) Header Parameter 550 The "zip" (compression algorithm) applied to the Plaintext before 551 encryption, if any. If present, the value of the "zip" header 552 parameter MUST be the case sensitive string "DEF". Compression is 553 performed with the DEFLATE [RFC1951] algorithm. If no "zip" 554 parameter is present, no compression is applied to the Plaintext 555 before encryption. This header parameter is OPTIONAL. 557 4.1.8. "jku" (JWK Set URL) Header Parameter 559 The "jku" (JWK Set URL) header parameter is a URI [RFC3986] that 560 refers to a resource for a set of JSON-encoded public keys, one of 561 which corresponds to the key used to encrypt the JWE; this can be 562 used to determine the private key needed to decrypt the JWE. The 563 keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The 564 protocol used to acquire the resource MUST provide integrity 565 protection; an HTTP GET request to retrieve the certificate MUST use 566 TLS [RFC2818] [RFC5246]; the identity of the server MUST be 567 validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. This 568 header parameter is OPTIONAL. 570 4.1.9. "jwk" (JSON Web Key) Header Parameter 572 The "jwk" (JSON Web Key) header parameter is a public key that 573 corresponds to the key used to encrypt the JWE; this can be used to 574 determine the private key needed to decrypt the JWE. This key is 575 represented as a JSON Web Key [JWK]. This header parameter is 576 OPTIONAL. 578 4.1.10. "x5u" (X.509 URL) Header Parameter 580 The "x5u" (X.509 URL) header parameter is a URI [RFC3986] that refers 581 to a resource for the X.509 public key certificate or certificate 582 chain [RFC5280] corresponding to the key used to encrypt the JWE; 583 this can be used to determine the private key needed to decrypt the 584 JWE. The identified resource MUST provide a representation of the 585 certificate or certificate chain that conforms to RFC 5280 [RFC5280] 586 in PEM encoded form [RFC1421]. The certificate containing the public 587 key of the entity that encrypted the JWE MUST be the first 588 certificate. This MAY be followed by additional certificates, with 589 each subsequent certificate being the one used to certify the 590 previous one. The protocol used to acquire the resource MUST provide 591 integrity protection; an HTTP GET request to retrieve the certificate 592 MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be 593 validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. This 594 header parameter is OPTIONAL. 596 4.1.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter 598 The "x5t" (X.509 Certificate Thumbprint) header parameter provides a 599 base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER 600 encoding of the X.509 certificate [RFC5280] corresponding to the key 601 used to encrypt the JWE; this can be used to determine the private 602 key needed to decrypt the JWE. This header parameter is OPTIONAL. 604 If, in the future, certificate thumbprints need to be computed using 605 hash functions other than SHA-1, it is suggested that additional 606 related header parameters be defined for that purpose. For example, 607 it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint 608 using SHA-256) header parameter could be defined by registering it in 609 the IANA JSON Web Signature and Encryption Header Parameters registry 610 [JWS]. 612 4.1.12. "x5c" (X.509 Certificate Chain) Header Parameter 614 The "x5c" (X.509 Certificate Chain) header parameter contains the 615 X.509 public key certificate or certificate chain [RFC5280] 616 corresponding to the key used to encrypt the JWE; this can be used to 617 determine the private key needed to decrypt the JWE. The certificate 618 or certificate chain is represented as an array of certificate 619 values. Each value is a base64 encoded ([RFC4648] Section 4 - not 620 base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The 621 certificate containing the public key of the entity that encrypted 622 the JWE MUST be the first certificate. This MAY be followed by 623 additional certificates, with each subsequent certificate being the 624 one used to certify the previous one. The recipient MUST verify the 625 certificate chain according to [RFC5280] and reject the JWE if any 626 validation failure occurs. This header parameter is OPTIONAL. 628 See Appendix B of [JWS] for an example "x5c" value. 630 4.1.13. "kid" (Key ID) Header Parameter 632 The "kid" (key ID) header parameter is a hint indicating which key 633 was used to encrypt the JWE; this can be used to determine the 634 private key needed to decrypt the JWE. This parameter allows 635 originators to explicitly signal a change of key to recipients. 636 Should the recipient be unable to locate a key corresponding to the 637 "kid" value, they SHOULD treat that condition as an error. The 638 interpretation of the "kid" value is unspecified. Its value MUST be 639 a string. This header parameter is OPTIONAL. 641 When used with a JWK, the "kid" value MAY be used to match a JWK 642 "kid" parameter value. 644 4.1.14. "typ" (Type) Header Parameter 646 The "typ" (type) header parameter is used to declare the type of this 647 object. The type value "JWE" MAY be used to indicate that this 648 object is a JWE. The "typ" value is a case sensitive string. This 649 header parameter is OPTIONAL. 651 MIME Media Type [RFC2046] values MAY be used as "typ" values. 653 "typ" values SHOULD either be registered in the IANA JSON Web 654 Signature and Encryption Type Values registry [JWS] or be a URI that 655 contains a Collision Resistant Namespace. 657 4.1.15. "cty" (Content Type) Header Parameter 659 The "cty" (content type) header parameter is used to declare the type 660 of the encrypted content (the Plaintext). The "cty" value is a case 661 sensitive string. This header parameter is OPTIONAL. 663 The values used for the "cty" header parameter come from the same 664 value space as the "typ" header parameter, with the same rules 665 applying. 667 4.2. Public Header Parameter Names 669 Additional header parameter names can be defined by those using JWEs. 670 However, in order to prevent collisions, any new header parameter 671 name SHOULD either be registered in the IANA JSON Web Signature and 672 Encryption Header Parameters registry [JWS] or be a URI that contains 673 a Collision Resistant Namespace. In each case, the definer of the 674 name or value needs to take reasonable precautions to make sure they 675 are in control of the part of the namespace they use to define the 676 header parameter name. 678 New header parameters should be introduced sparingly, as they can 679 result in non-interoperable JWEs. 681 4.3. Private Header Parameter Names 683 A producer and consumer of a JWE may agree to any header parameter 684 name that is not a Reserved Name Section 4.1 or a Public Name 685 Section 4.2. Unlike Public Names, these private names are subject to 686 collision and should be used with caution. 688 5. Message Encryption 690 The message encryption process is as follows. The order of the steps 691 is not significant in cases where there are no dependencies between 692 the inputs and outputs of the steps. 694 1. When key wrapping or key encryption are employed, generate a 695 random Content Master Key (CMK). See RFC 4086 [RFC4086] for 696 considerations on generating random values. Otherwise, when key 697 agreement is employed, use the key agreement algorithm to 698 compute the value of the Content Master Key (CMK). The CMK MUST 699 have a length equal to that of the larger of the required 700 encryption and integrity keys. 702 2. When key wrapping or key encryption are employed, encrypt the 703 CMK for the recipient (see Section 7) and let the result be the 704 JWE Encrypted Key. Otherwise, when key agreement is employed, 705 let the JWE Encrypted Key be an empty byte array. 707 3. Base64url encode the JWE Encrypted Key to create the Encoded JWE 708 Encrypted Key. 710 4. Generate a random Initialization Vector (IV) of the correct size 711 for the algorithm (if required for the algorithm). 713 5. If not using an AEAD algorithm, run the key derivation algorithm 714 specified by the "kdf" header parameter to generate the Content 715 Encryption Key (CEK) and the Content Integrity Key (CIK); 716 otherwise (when using an AEAD algorithm), set the CEK to be the 717 CMK. 719 6. Compress the Plaintext if a "zip" parameter was included. 721 7. Serialize the (compressed) Plaintext into a byte sequence M. 723 8. Create a JWE Header containing the encryption parameters used. 724 Note that white space is explicitly allowed in the 725 representation and no canonicalization need be performed before 726 encoding. 728 9. Base64url encode the bytes of the UTF-8 representation of the 729 JWE Header to create the Encoded JWE Header. 731 10. Encrypt M using the CEK and IV to form the byte sequence C. If 732 an AEAD algorithm is used, use the bytes of the ASCII 733 representation of the concatenation of the Encoded JWE Header, a 734 period ('.') character, and the Encoded JWE Encrypted Key as the 735 "additional authenticated data" parameter value for the 736 encryption. 738 11. Base64url encode C to create the Encoded JWE Ciphertext. 740 12. If not using an AEAD algorithm, run the integrity algorithm (see 741 Section 8) using the CIK to compute the JWE Integrity Value; 742 otherwise (when using an AEAD algorithm), set the JWE Integrity 743 Value to be the "authentication tag" value produced by the AEAD 744 algorithm. 746 13. Base64url encode the JWE Integrity Value to create the Encoded 747 JWE Integrity Value. 749 14. The four encoded parts, taken together, are the result. 751 15. The Compact Serialization of this result is the concatenation of 752 the Encoded JWE Header, the Encoded JWE Encrypted Key, the 753 Encoded JWE Ciphertext, and the Encoded JWE Integrity Value in 754 that order, with the four strings being separated by period 755 ('.') characters. 757 6. Message Decryption 759 The message decryption process is the reverse of the encryption 760 process. The order of the steps is not significant in cases where 761 there are no dependencies between the inputs and outputs of the 762 steps. If any of these steps fails, the JWE MUST be rejected. 764 1. Determine the Encoded JWE Header, the Encoded JWE Encrypted Key, 765 the Encoded JWE Ciphertext, and the Encoded JWE Integrity Value 766 values contained in the JWE. When using the Compact 767 Serialization, these four values are represented in that order, 768 separated by period characters. 770 2. The Encoded JWE Header, the Encoded JWE Encrypted Key, the 771 Encoded JWE Ciphertext, and the Encoded JWE Integrity Value MUST 772 be successfully base64url decoded following the restriction that 773 no padding characters have been used. 775 3. The resulting JWE Header MUST be completely valid JSON syntax 776 conforming to RFC 4627 [RFC4627]. 778 4. The resulting JWE Header MUST be validated to only include 779 parameters and values whose syntax and semantics are both 780 understood and supported. 782 5. Verify that the JWE Header references a key known to the 783 recipient. 785 6. When key wrapping or key encryption are employed, decrypt the 786 JWE Encrypted Key to produce the Content Master Key (CMK). 787 Otherwise, when key agreement is employed, use the key agreement 788 algorithm to compute the value of the Content Master Key (CMK). 789 The CMK MUST have a length equal to that of the larger of the 790 required encryption and integrity keys. 792 7. If not using an AEAD algorithm, run the key derivation algorithm 793 specified by the "kdf" header parameter to generate the Content 794 Encryption Key (CEK) and the Content Integrity Key (CIK); 795 otherwise (when using an AEAD algorithm), set the CEK to be the 796 CMK. 798 8. Decrypt the binary representation of the JWE Ciphertext using 799 the CEK and IV. If an AEAD algorithm is used, use the bytes of 800 the ASCII representation of the concatenation of the Encoded JWE 801 Header, a period ('.') character, and the Encoded JWE Encrypted 802 Key as the "additional authenticated data" parameter value for 803 the decryption. 805 9. If not using an AEAD algorithm, run the integrity algorithm (see 806 Section 8) using the CIK to compute an integrity value for the 807 input received. This computed value MUST match the received JWE 808 Integrity Value; otherwise (when using an AEAD algorithm), the 809 received JWE Integrity Value MUST match the "authentication tag" 810 value produced by the AEAD algorithm. 812 10. Uncompress the result of the previous step, if a "zip" parameter 813 was included. 815 11. Output the resulting Plaintext. 817 7. CMK Encryption 819 JWE supports two forms of Content Master Key (CMK) encryption: 821 o Asymmetric encryption under the recipient's public key. 823 o Symmetric encryption under a key shared between the sender and 824 receiver. 826 See the algorithms registered for "enc" usage in the IANA JSON Web 827 Signature and Encryption Algorithms registry [JWA] and Section 4.1 of 828 the JSON Web Algorithms (JWA) [JWA] specification for lists of 829 encryption algorithms that can be used for CMK encryption. 831 8. Integrity Value Calculation 833 When a non-AEAD algorithm is used (an algorithm without an integrated 834 content check), JWE adds an explicit integrity check value to the 835 representation. This value is computed in the manner described in 836 the JSON Web Signature (JWS) [JWS] specification, with these 837 modifications: 839 o The algorithm used is taken from the "int" (integrity algorithm) 840 header parameter rather than the "alg" header parameter. 842 o The algorithm MUST be a MAC algorithm (such as HMAC SHA-256). 844 o The JWS Secured Input used is the bytes of the ASCII 845 representation of the concatenation of the Encoded JWE Header, a 846 period ('.') character, the Encoded JWE Encrypted Key, a period 847 ('.') character, and the Encoded JWE Ciphertext. 849 o The CIK is used as the MAC key. 851 The computed JWS Signature value is the resulting integrity value. 853 9. Encrypting JWEs with Cryptographic Algorithms 855 JWE uses cryptographic algorithms to encrypt the Plaintext and the 856 Content Encryption Key (CMK) and to provide integrity protection for 857 the JWE Header, JWE Encrypted Key, and JWE Ciphertext. The JSON Web 858 Algorithms (JWA) [JWA] specification specifies a set of cryptographic 859 algorithms and identifiers to be used with this specification and 860 defines registries for additional such algorithms. Specifically, 861 Section 4.1 specifies a set of "alg" (algorithm) header parameter 862 values, Section 4.2 specifies a set of "enc" (encryption method) 863 header parameter values, Section 4.3 specifies a set of "int" 864 (integrity algorithm) header parameter values, and Section 4.4 865 specifies a set of "kdf" (key derivation function) header parameter 866 values intended for use this specification. It also describes the 867 semantics and operations that are specific to these algorithms and 868 algorithm families. 870 Public keys employed for encryption can be identified using the 871 Header Parameter methods described in Section 4.1 or can be 872 distributed using methods that are outside the scope of this 873 specification. 875 10. IANA Considerations 877 10.1. Registration of JWE Header Parameter Names 879 This specification registers the Header Parameter Names defined in 880 Section 4.1 in the IANA JSON Web Signature and Encryption Header 881 Parameters registry [JWS]. 883 10.1.1. Registry Contents 885 o Header Parameter Name: "alg" 886 o Change Controller: IETF 888 o Specification Document(s): Section 4.1.1 of [[ this document ]] 890 o Header Parameter Name: "enc" 892 o Change Controller: IETF 894 o Specification Document(s): Section 4.1.2 of [[ this document ]] 896 o Header Parameter Name: "int" 898 o Change Controller: IETF 900 o Specification Document(s): Section 4.1.3 of [[ this document ]] 902 o Header Parameter Name: "kdf" 904 o Change Controller: IETF 906 o Specification Document(s): Section 4.1.4 of [[ this document ]] 908 o Header Parameter Name: "iv" 910 o Change Controller: IETF 912 o Specification Document(s): Section 4.1.5 of [[ this document ]] 914 o Header Parameter Name: "epk" 916 o Change Controller: IETF 918 o Specification Document(s): Section 4.1.6 of [[ this document ]] 920 o Header Parameter Name: "zip" 922 o Change Controller: IETF 924 o Specification Document(s): Section 4.1.7 of [[ this document ]] 926 o Header Parameter Name: "jku" 928 o Change Controller: IETF 930 o Specification Document(s): Section 4.1.8 of [[ this document ]] 931 o Header Parameter Name: "jwk" 933 o Change Controller: IETF 935 o Specification document(s): Section 4.1.9 of [[ this document ]] 937 o Header Parameter Name: "x5u" 939 o Change Controller: IETF 941 o Specification Document(s): Section 4.1.10 of [[ this document ]] 943 o Header Parameter Name: "x5t" 945 o Change Controller: IETF 947 o Specification Document(s): Section 4.1.11 of [[ this document ]] 949 o Header Parameter Name: "x5c" 951 o Change Controller: IETF 953 o Specification Document(s): Section 4.1.12 of [[ this document ]] 955 o Header Parameter Name: "kid" 957 o Change Controller: IETF 959 o Specification Document(s): Section 4.1.13 of [[ this document ]] 961 o Header Parameter Name: "typ" 963 o Change Controller: IETF 965 o Specification Document(s): Section 4.1.14 of [[ this document ]] 967 o Header Parameter Name: "cty" 969 o Change Controller: IETF 971 o Specification Document(s): Section 4.1.15 of [[ this document ]] 973 10.2. JSON Web Signature and Encryption Type Values Registration 975 10.2.1. Registry Contents 977 This specification registers the "JWE" type value in the IANA JSON 978 Web Signature and Encryption Type Values registry [JWS]: 980 o "typ" Header Parameter Value: "JWE" 982 o Abbreviation for MIME Type: application/jwe 984 o Change Controller: IETF 986 o Specification Document(s): Section 4.1.14 of [[ this document ]] 988 10.3. Media Type Registration 990 10.3.1. Registry Contents 992 This specification registers the "application/jwe" Media Type 993 [RFC2046] in the MIME Media Type registry [RFC4288] to indicate that 994 the content is a JWE using the Compact Serialization. 996 o Type Name: application 998 o Subtype Name: jwe 1000 o Required Parameters: n/a 1002 o Optional Parameters: n/a 1004 o Encoding considerations: JWE values are encoded as a series of 1005 base64url encoded values (some of which may be the empty string) 1006 separated by period ('.') characters 1008 o Security Considerations: See the Security Considerations section 1009 of this document 1011 o Interoperability Considerations: n/a 1013 o Published Specification: [[ this document ]] 1015 o Applications that use this media type: OpenID Connect and other 1016 applications using encrypted JWTs 1018 o Additional Information: Magic number(s): n/a, File extension(s): 1019 n/a, Macintosh file type code(s): n/a 1021 o Person & email address to contact for further information: Michael 1022 B. Jones, mbj@microsoft.com 1024 o Intended Usage: COMMON 1026 o Restrictions on Usage: none 1027 o Author: Michael B. Jones, mbj@microsoft.com 1029 o Change Controller: IETF 1031 11. Security Considerations 1033 All of the security issues faced by any cryptographic application 1034 must be faced by a JWS/JWE/JWK agent. Among these issues are 1035 protecting the user's private key, preventing various attacks, and 1036 helping the user avoid mistakes such as inadvertently encrypting a 1037 message for the wrong recipient. The entire list of security 1038 considerations is beyond the scope of this document, but some 1039 significant concerns are listed here. 1041 All the security considerations in the JWS specification also apply 1042 to this specification. Likewise, all the security considerations in 1043 XML Encryption 1.1 [W3C.CR-xmlenc-core1-20120313] also apply to JWE, 1044 other than those that are XML specific. 1046 12. Open Issues 1048 [[ to be removed by the RFC editor before publication as an RFC ]] 1050 The following items remain to be considered or done in this draft: 1052 o Should we define an optional nonce and/or timestamp header 1053 parameter? (Use of a nonce is an effective countermeasure to some 1054 kinds of attacks.) 1056 o When doing key agreement, do we want to also use a separate CMK 1057 and encrypt the CMK with the agreed upon key or just use the 1058 agreed upon key directly as the CMK? Or support both? Having a 1059 CMK would have value in the multiple recipients case, as it would 1060 allow multiple recipients to share the same ciphertext even when 1061 key agreement is used, but it seems that it's just extra overhead 1062 in the single recipient case. (Also see the related open issue 1063 about performing symmetric encryption directly with a shared key, 1064 without using a CMK.) 1066 o Do we want to consolidate the combination of the "enc", "int", and 1067 "kdf" parameters into a single new "enc" parameter defining 1068 composite AEAD algorithms? For instance, we might define a 1069 composite algorithm A128CBC with HS256 and CS256 and another 1070 composite algorithm A256CBC with HS512 and CS512. A symmetry 1071 argument for doing this is that the "int" and "kdf" parameters are 1072 not used with AEAD algorithms. An argument against it is that in 1073 some cases, integrity is not needed because it's provided by other 1074 means, and so having the flexibility to not use an "int" algorithm 1075 or key derivation with a non-AEAD "enc" algorithm could be useful. 1077 13. References 1079 13.1. Normative References 1081 [ITU.X690.1994] 1082 International Telecommunications Union, "Information 1083 Technology - ASN.1 encoding rules: Specification of Basic 1084 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1085 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1086 X.690, 1994. 1088 [JWA] Jones, M., "JSON Web Algorithms (JWA)", July 2012. 1090 [JWK] Jones, M., "JSON Web Key (JWK)", July 2012. 1092 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1093 Signature (JWS)", July 2012. 1095 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1096 Mail: Part I: Message Encryption and Authentication 1097 Procedures", RFC 1421, February 1993. 1099 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1100 version 1.3", RFC 1951, May 1996. 1102 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1103 Extensions (MIME) Part Two: Media Types", RFC 2046, 1104 November 1996. 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, March 1997. 1109 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1111 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1112 10646", STD 63, RFC 3629, November 2003. 1114 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1115 Resource Identifier (URI): Generic Syntax", STD 66, 1116 RFC 3986, January 2005. 1118 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1119 Requirements for Security", BCP 106, RFC 4086, June 2005. 1121 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1122 Registration Procedures", BCP 13, RFC 4288, December 2005. 1124 [RFC4627] Crockford, D., "The application/json Media Type for 1125 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1127 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1128 Encodings", RFC 4648, October 2006. 1130 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1131 Encryption", RFC 5116, January 2008. 1133 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1134 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1136 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1137 Housley, R., and W. Polk, "Internet X.509 Public Key 1138 Infrastructure Certificate and Certificate Revocation List 1139 (CRL) Profile", RFC 5280, May 2008. 1141 [W3C.CR-xmlenc-core1-20120313] 1142 Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, 1143 "XML Encryption Syntax and Processing Version 1.1", World 1144 Wide Web Consortium CR CR-xmlenc-core1-20120313, 1145 March 2012, 1146 . 1148 13.2. Informative References 1150 [I-D.rescorla-jsms] 1151 Rescorla, E. and J. Hildebrand, "JavaScript Message 1152 Security Format", draft-rescorla-jsms-00 (work in 1153 progress), March 2011. 1155 [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple 1156 Encryption", September 2010. 1158 [JWE-JS] Jones, M., "JSON Web Encryption JSON Serialization 1159 (JWE-JS)", July 2012. 1161 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1162 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1163 July 2005. 1165 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1166 RFC 5652, September 2009. 1168 Appendix A. JWE Examples 1170 This section provides examples of JWE computations. 1172 A.1. Example JWE using RSAES OAEP and AES GCM 1174 This example encrypts the plaintext "Live long and prosper." to the 1175 recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an 1176 integrated integrity check. The representation of this plaintext is: 1178 [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 1179 112, 114, 111, 115, 112, 101, 114, 46] 1181 A.1.1. JWE Header 1183 The following example JWE Header declares that: 1185 o the Content Master Key is encrypted to the recipient using the 1186 RSAES OAEP algorithm to produce the JWE Encrypted Key, 1188 o the Plaintext is encrypted using the AES GCM algorithm with a 256 1189 bit key to produce the Ciphertext, and 1191 o the 96 bit Initialization Vector (IV) [227, 197, 117, 252, 2, 219, 1192 233, 68, 180, 225, 77, 219] with the base64url encoding 1193 "48V1_ALb6US04U3b" was used. 1195 {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} 1197 A.1.2. Encoded JWE Header 1199 Base64url encoding the bytes of the UTF-8 representation of the JWE 1200 Header yields this Encoded JWE Header value (with line breaks for 1201 display purposes only): 1202 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxi 1203 NlVTMDRVM2IifQ 1205 A.1.3. Content Master Key (CMK) 1207 Generate a random Content Master Key (CMK). In this example, the key 1208 value is: 1210 [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 1211 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 1212 234, 64, 252] 1214 A.1.4. Key Encryption 1216 Encrypt the CMK with the recipient's public key using the RSAES OAEP 1217 algorithm to produce the JWE Encrypted Key. In this example, the RSA 1218 key parameters are: 1220 +-----------+-------------------------------------------------------+ 1221 | Parameter | Value | 1222 | Name | | 1223 +-----------+-------------------------------------------------------+ 1224 | Modulus | [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, | 1225 | | 110, 57, 30, 135, 227, 9, 31, 226, 128, 84, 92, 116, | 1226 | | 241, 70, 248, 27, 227, 193, 62, 5, 91, 241, 145, 224, | 1227 | | 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161, | 1228 | | 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, | 1229 | | 69, 78, 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, | 1230 | | 22, 167, 8, 212, 56, 35, 79, 210, 222, 192, 208, 252, | 1231 | | 49, 109, 138, 173, 253, 210, 166, 201, 63, 102, 74, | 1232 | | 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, | 1233 | | 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, | 1234 | | 121, 118, 196, 17, 146, 10, 244, 188, 72, 113, 55, | 1235 | | 221, 162, 217, 171, 27, 57, 233, 210, 101, 236, 154, | 1236 | | 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, | 1237 | | 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, | 1238 | | 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, 163, | 1239 | | 18, 180, 251, 58, 153, 46, 151, 174, 12, 103, 197, | 1240 | | 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, | 1241 | | 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, | 1242 | | 195, 20, 108, 202, 176, 214, 187, 45, 146, 182, 118, | 1243 | | 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37, | 1244 | | 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, | 1245 | | 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, | 1246 | | 190, 253, 186, 186, 27] | 1247 | Exponent | [1, 0, 1] | 1248 | Private | [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, | 1249 | Exponent | 66, 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, | 1250 | | 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191, | 1251 | | 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, | 1252 | | 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, | 1253 | | 231, 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, | 1254 | | 211, 245, 250, 112, 71, 243, 61, 129, 95, 39, 244, | 1255 | | 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, | 1256 | | 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, | 1257 | | 187, 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, | 1258 | | 1, 146, 43, 3, 108, 64, 194, 121, 182, 95, 187, 134, | 1259 | | 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, | 1260 | | 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, | 1261 | | 112, 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, | 1262 | | 157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241, | 1263 | | 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153, | 1264 | | 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, | 1265 | | 38, 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, | 1266 | | 131, 137, 175, 72, 126, 43, 229, 69, 179, 117, 82, | 1267 | | 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, | 1268 | | 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, | 1269 | | 210, 7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, | 1270 | | 224, 173, 56, 224, 201] | 1271 +-----------+-------------------------------------------------------+ 1273 The resulting JWE Encrypted Key value is: 1275 [142, 252, 40, 202, 21, 177, 56, 198, 232, 7, 151, 49, 95, 169, 220, 1276 2, 46, 214, 167, 116, 57, 20, 164, 109, 150, 98, 49, 223, 154, 95, 1277 71, 209, 233, 17, 174, 142, 203, 232, 132, 167, 17, 42, 51, 125, 22, 1278 221, 135, 17, 67, 197, 148, 246, 139, 145, 160, 238, 99, 119, 171, 1279 95, 117, 202, 87, 251, 101, 254, 58, 215, 135, 195, 135, 103, 49, 1280 119, 76, 46, 49, 198, 27, 31, 58, 44, 192, 222, 21, 16, 13, 216, 161, 1281 179, 236, 65, 143, 38, 43, 218, 195, 76, 140, 243, 71, 243, 79, 124, 1282 216, 208, 242, 171, 34, 245, 57, 154, 93, 76, 230, 204, 234, 82, 117, 1283 248, 39, 13, 62, 60, 215, 8, 51, 248, 254, 47, 150, 36, 46, 27, 247, 1284 98, 77, 56, 92, 44, 19, 39, 12, 77, 54, 101, 194, 126, 86, 0, 64, 1285 239, 95, 211, 64, 26, 219, 93, 211, 36, 154, 250, 117, 177, 213, 232, 1286 142, 184, 216, 92, 20, 248, 69, 175, 180, 71, 205, 221, 235, 224, 95, 1287 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0, 0, 135, 65, 67, 220, 1288 164, 15, 230, 155, 71, 53, 64, 253, 209, 169, 255, 34, 64, 101, 7, 1289 43, 102, 227, 83, 171, 52, 225, 119, 253, 182, 96, 195, 225, 34, 156, 1290 211, 202, 7, 194, 255, 137, 59, 170, 172, 72, 234, 222, 203, 123, 1291 249, 121, 254, 143, 173, 105, 65, 187, 189, 163, 64, 151, 145, 99, 1292 17] 1294 A.1.5. Encoded JWE Encrypted Key 1296 Base64url encode the JWE Encrypted Key to produce the Encoded JWE 1297 Encrypted Key. This result (with line breaks for display purposes 1298 only) is: 1299 jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcR 1300 Q8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva 1301 w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxN 1302 NmXCflYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkA 1303 AIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7L 1304 e_l5_o-taUG7vaNAl5FjEQ 1306 A.1.6. "Additional Authenticated Data" Parameter 1308 Concatenate the Encoded JWE Header value, a period character ('.'), 1309 and the Encoded JWE Encrypted Key to create the "additional 1310 authenticated data" parameter for the AES GCM algorithm. This result 1311 (with line breaks for display purposes only) is: 1312 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxi 1313 NlVTMDRVM2IifQ. 1314 jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcR 1315 Q8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva 1316 w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxN 1317 NmXCflYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkA 1318 AIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7L 1319 e_l5_o-taUG7vaNAl5FjEQ 1321 The representation of this value is: 1323 [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 1324 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 1325 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 1326 112, 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 1327 120, 105, 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 1328 46, 106, 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 1329 99, 120, 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 1330 82, 116, 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 1331 97, 54, 79, 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 1332 89, 99, 82, 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 1333 54, 116, 102, 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 1334 119, 52, 100, 110, 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 1335 76, 77, 68, 101, 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 1336 105, 118, 97, 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 1337 48, 80, 75, 114, 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 1338 113, 85, 110, 88, 52, 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 1339 45, 76, 53, 89, 107, 76, 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 1340 84, 74, 119, 120, 78, 78, 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 1341 102, 48, 48, 65, 97, 50, 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 1342 86, 54, 73, 54, 52, 50, 70, 119, 85, 45, 69, 87, 118, 116, 69, 102, 1343 78, 51, 101, 118, 103, 88, 51, 69, 70, 73, 86, 89, 83, 110, 84, 51, 1344 72, 67, 72, 107, 65, 65, 73, 100, 66, 81, 57, 121, 107, 68, 45, 97, 1345 98, 82, 122, 86, 65, 95, 100, 71, 112, 95, 121, 74, 65, 90, 81, 99, 1346 114, 90, 117, 78, 84, 113, 122, 84, 104, 100, 95, 50, 50, 89, 77, 80, 1347 104, 73, 112, 122, 84, 121, 103, 102, 67, 95, 52, 107, 55, 113, 113, 1348 120, 73, 54, 116, 55, 76, 101, 95, 108, 53, 95, 111, 45, 116, 97, 85, 1349 71, 55, 118, 97, 78, 65, 108, 53, 70, 106, 69, 81] 1351 A.1.7. Plaintext Encryption 1353 Encrypt the Plaintext with AES GCM, using the IV, the CMK as the 1354 encryption key, and the "additional authenticated data" value above, 1355 requesting a 128 bit "authentication tag" output. The resulting 1356 Ciphertext is: 1358 [253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122, 1359 246, 116, 195, 212, 102, 37, 36, 175] 1361 The resulting "authentication tag" value is: 1363 [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220, 233, 68, 233, 114, 1364 139] 1366 A.1.8. Encoded JWE Ciphertext 1368 Base64url encode the resulting Ciphertext to create the Encoded JWE 1369 Ciphertext. This result is: 1370 _e21tGGhac_peEFkLXr2dMPUZiUkrw 1372 A.1.9. Encoded JWE Integrity Value 1374 Base64url encode the resulting "authentication tag" to create the 1375 Encoded JWE Integrity Value. This result is: 1376 YbZSeHCNDZBqAdzpROlyiw 1378 A.1.10. Complete Representation 1380 Assemble the final representation: The Compact Serialization of this 1381 result is the concatenation of the Encoded JWE Header, the Encoded 1382 JWE Encrypted Key, the Encoded JWE Ciphertext, and the Encoded JWE 1383 Integrity Value in that order, with the four strings being separated 1384 by three period ('.') characters. 1386 The final result in this example (with line breaks for display 1387 purposes only) is: 1389 eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxi 1390 NlVTMDRVM2IifQ. 1391 jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcR 1392 Q8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJiva 1393 w0yM80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxN 1394 NmXCflYAQO9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkA 1395 AIdBQ9ykD-abRzVA_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7L 1396 e_l5_o-taUG7vaNAl5FjEQ. 1397 _e21tGGhac_peEFkLXr2dMPUZiUkrw. 1398 YbZSeHCNDZBqAdzpROlyiw 1400 A.1.11. Validation 1402 This example illustrates the process of creating a JWE with an AEAD 1403 algorithm. These results can be used to validate JWE decryption 1404 implementations for these algorithms. However, note that since the 1405 RSAES OAEP computation includes random values, the results above will 1406 not be repeatable. 1408 A.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC 1410 This example encrypts the plaintext "Now is the time for all good men 1411 to come to the aid of their country." to the recipient using RSAES- 1412 PKCS1-V1_5 and AES CBC. AES CBC does not have an integrated 1413 integrity check, so a separate integrity check calculation is 1414 performed using HMAC SHA-256, with separate encryption and integrity 1415 keys being derived from a master key using the Concat KDF with the 1416 SHA-256 digest function. The representation of this plaintext is: 1418 [78, 111, 119, 32, 105, 115, 32, 116, 104, 101, 32, 116, 105, 109, 1419 101, 32, 102, 111, 114, 32, 97, 108, 108, 32, 103, 111, 111, 100, 32, 1420 109, 101, 110, 32, 116, 111, 32, 99, 111, 109, 101, 32, 116, 111, 32, 1421 116, 104, 101, 32, 97, 105, 100, 32, 111, 102, 32, 116, 104, 101, 1422 105, 114, 32, 99, 111, 117, 110, 116, 114, 121, 46] 1424 A.2.1. JWE Header 1426 The following example JWE Header (with line breaks for display 1427 purposes only) declares that: 1429 o the Content Master Key is encrypted to the recipient using the 1430 RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key, 1432 o the Plaintext is encrypted using the AES CBC algorithm with a 128 1433 bit key to produce the Ciphertext, 1435 o the JWE Integrity Value safeguarding the integrity of the 1436 Ciphertext and the parameters used to create it was computed with 1437 the HMAC SHA-256 algorithm, and 1439 o the 128 bit Initialization Vector (IV) [3, 22, 60, 12, 43, 67, 1440 104, 105, 108, 108, 105, 99, 111, 116, 104, 101] with the 1441 base64url encoding "AxY8DCtDaGlsbGljb3RoZQ" was used. 1443 {"alg":"RSA1_5","enc":"A128CBC","int":"HS256","iv":"AxY8DCtDaGls 1444 bGljb3RoZQ"} 1446 A.2.2. Encoded JWE Header 1448 Base64url encoding the bytes of the UTF-8 representation of the JWE 1449 Header yields this Encoded JWE Header value (with line breaks for 1450 display purposes only): 1451 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp 1452 diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ 1454 A.2.3. Content Master Key (CMK) 1456 Generate a random Content Master Key (CMK). In this example, the key 1457 value is: 1459 [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 1460 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 1461 44, 207] 1463 A.2.4. Key Encryption 1465 Encrypt the CMK with the recipient's public key using the RSAES- 1466 PKCS1-V1_5 algorithm to produce the JWE Encrypted Key. In this 1467 example, the RSA key parameters are: 1469 +-----------+-------------------------------------------------------+ 1470 | Parameter | Value | 1471 | Name | | 1472 +-----------+-------------------------------------------------------+ 1473 | Modulus | [177, 119, 33, 13, 164, 30, 108, 121, 207, 136, 107, | 1474 | | 242, 12, 224, 19, 226, 198, 134, 17, 71, 173, 75, 42, | 1475 | | 61, 48, 162, 206, 161, 97, 108, 185, 234, 226, 219, | 1476 | | 118, 206, 118, 5, 169, 224, 60, 181, 90, 85, 51, 123, | 1477 | | 6, 224, 4, 122, 29, 230, 151, 12, 244, 127, 121, 25, | 1478 | | 4, 85, 220, 144, 215, 110, 130, 17, 68, 228, 129, | 1479 | | 138, 7, 130, 231, 40, 212, 214, 17, 179, 28, 124, | 1480 | | 151, 178, 207, 20, 14, 154, 222, 113, 176, 24, 198, | 1481 | | 73, 211, 113, 9, 33, 178, 80, 13, 25, 21, 25, 153, | 1482 | | 212, 206, 67, 154, 147, 70, 194, 192, 183, 160, 83, | 1483 | | 98, 236, 175, 85, 23, 97, 75, 199, 177, 73, 145, 50, | 1484 | | 253, 206, 32, 179, 254, 236, 190, 82, 73, 67, 129, | 1485 | | 253, 252, 220, 108, 136, 138, 11, 192, 1, 36, 239, | 1486 | | 228, 55, 81, 113, 17, 25, 140, 63, 239, 146, 3, 172, | 1487 | | 96, 60, 227, 233, 64, 255, 224, 173, 225, 228, 229, | 1488 | | 92, 112, 72, 99, 97, 26, 87, 187, 123, 46, 50, 90, | 1489 | | 202, 117, 73, 10, 153, 47, 224, 178, 163, 77, 48, 46, | 1490 | | 154, 33, 148, 34, 228, 33, 172, 216, 89, 46, 225, | 1491 | | 127, 68, 146, 234, 30, 147, 54, 146, 5, 133, 45, 78, | 1492 | | 254, 85, 55, 75, 213, 86, 194, 218, 215, 163, 189, | 1493 | | 194, 54, 6, 83, 36, 18, 153, 53, 7, 48, 89, 35, 66, | 1494 | | 144, 7, 65, 154, 13, 97, 75, 55, 230, 132, 3, 13, | 1495 | | 239, 71] | 1496 | Exponent | [1, 0, 1] | 1497 | Private | [84, 80, 150, 58, 165, 235, 242, 123, 217, 55, 38, | 1498 | Exponent | 154, 36, 181, 221, 156, 211, 215, 100, 164, 90, 88, | 1499 | | 40, 228, 83, 148, 54, 122, 4, 16, 165, 48, 76, 194, | 1500 | | 26, 107, 51, 53, 179, 165, 31, 18, 198, 173, 78, 61, | 1501 | | 56, 97, 252, 158, 140, 80, 63, 25, 223, 156, 36, 203, | 1502 | | 214, 252, 120, 67, 180, 167, 3, 82, 243, 25, 97, 214, | 1503 | | 83, 133, 69, 16, 104, 54, 160, 200, 41, 83, 164, 187, | 1504 | | 70, 153, 111, 234, 242, 158, 175, 28, 198, 48, 211, | 1505 | | 45, 148, 58, 23, 62, 227, 74, 52, 117, 42, 90, 41, | 1506 | | 249, 130, 154, 80, 119, 61, 26, 193, 40, 125, 10, | 1507 | | 152, 174, 227, 225, 205, 32, 62, 66, 6, 163, 100, 99, | 1508 | | 219, 19, 253, 25, 105, 80, 201, 29, 252, 157, 237, | 1509 | | 69, 1, 80, 171, 167, 20, 196, 156, 109, 249, 88, 0, | 1510 | | 3, 152, 38, 165, 72, 87, 6, 152, 71, 156, 214, 16, | 1511 | | 71, 30, 82, 51, 103, 76, 218, 63, 9, 84, 163, 249, | 1512 | | 91, 215, 44, 238, 85, 101, 240, 148, 1, 82, 224, 91, | 1513 | | 135, 105, 127, 84, 171, 181, 152, 210, 183, 126, 24, | 1514 | | 46, 196, 90, 173, 38, 245, 219, 186, 222, 27, 240, | 1515 | | 212, 194, 15, 66, 135, 226, 178, 190, 52, 245, 74, | 1516 | | 65, 224, 81, 100, 85, 25, 204, 165, 203, 187, 175, | 1517 | | 84, 100, 82, 15, 11, 23, 202, 151, 107, 54, 41, 207, | 1518 | | 3, 136, 229, 134, 131, 93, 139, 50, 182, 204, 93, | 1519 | | 130, 89] | 1520 +-----------+-------------------------------------------------------+ 1522 The resulting JWE Encrypted Key value is: 1524 [32, 242, 63, 207, 94, 246, 133, 37, 135, 48, 88, 4, 15, 193, 6, 244, 1525 51, 58, 132, 133, 212, 255, 163, 90, 59, 80, 200, 152, 41, 244, 188, 1526 215, 174, 160, 26, 188, 227, 180, 165, 234, 172, 63, 24, 116, 152, 1527 28, 149, 16, 94, 213, 201, 171, 180, 191, 11, 21, 149, 172, 143, 54, 1528 194, 58, 206, 201, 164, 28, 107, 155, 75, 101, 22, 92, 227, 144, 95, 1529 40, 119, 170, 7, 36, 225, 40, 141, 186, 213, 7, 175, 16, 174, 122, 1530 75, 32, 48, 193, 119, 202, 41, 152, 210, 190, 68, 57, 119, 4, 197, 1531 74, 7, 242, 239, 170, 204, 73, 75, 213, 202, 113, 216, 18, 23, 66, 1532 106, 208, 69, 244, 117, 147, 2, 37, 207, 199, 184, 96, 102, 44, 70, 1533 212, 87, 143, 253, 0, 166, 59, 41, 115, 217, 80, 165, 87, 38, 5, 9, 1534 184, 202, 68, 67, 176, 4, 87, 254, 166, 227, 88, 124, 238, 249, 75, 1535 114, 205, 148, 149, 45, 78, 193, 134, 64, 189, 168, 76, 170, 76, 176, 1536 72, 148, 77, 215, 159, 146, 55, 189, 213, 85, 253, 135, 200, 59, 247, 1537 79, 37, 22, 200, 32, 110, 53, 123, 54, 39, 9, 178, 231, 238, 95, 25, 1538 211, 143, 87, 220, 88, 138, 209, 13, 227, 72, 58, 102, 164, 136, 241, 1539 14, 14, 45, 32, 77, 44, 244, 162, 239, 150, 248, 181, 138, 251, 116, 1540 245, 205, 137, 78, 34, 34, 10, 6, 59, 4, 197, 2, 153, 251] 1542 A.2.5. Encoded JWE Encrypted Key 1544 Base64url encode the JWE Encrypted Key to produce the Encoded JWE 1545 Encrypted Key. This result (with line breaks for display purposes 1546 only) is: 1547 IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQ 1548 XtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfK 1549 KZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz 1550 2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9 1551 h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK 1552 -3T1zYlOIiIKBjsExQKZ-w 1554 A.2.6. Key Derivation 1556 Use the Concat key derivation function to derive Content Encryption 1557 Key (CEK) and Content Integrity Key (CIK) values from the CMK. The 1558 details of this derivation are shown in Appendix A.3. The resulting 1559 CEK value is: 1561 [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 1562 50, 69] 1564 The resulting CIK value is: 1566 [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 1567 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 1568 225, 159] 1570 A.2.7. Plaintext Encryption 1572 Encrypt the Plaintext with AES CBC using the CEK and IV to produce 1573 the Ciphertext. The resulting Ciphertext is: 1575 [253, 159, 221, 142, 82, 40, 11, 131, 3, 72, 34, 162, 173, 229, 146, 1576 217, 183, 173, 139, 132, 58, 137, 33, 182, 82, 49, 110, 141, 11, 221, 1577 207, 239, 207, 65, 213, 28, 20, 217, 14, 186, 87, 160, 15, 160, 96, 1578 142, 7, 69, 46, 55, 129, 224, 113, 206, 59, 181, 7, 188, 255, 15, 16, 1579 59, 180, 107, 75, 0, 217, 175, 254, 8, 141, 48, 217, 132, 16, 217, 4, 1580 30, 223, 147] 1582 A.2.8. Encoded JWE Ciphertext 1584 Base64url encode the resulting Ciphertext to create the Encoded JWE 1585 Ciphertext. This result (with line breaks for display purposes only) 1586 is: 1587 _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdF 1588 LjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M 1590 A.2.9. Secured Input Value 1592 Concatenate the Encoded JWE Header value, a period character ('.'), 1593 the Encoded JWE Encrypted Key, a second period character, and the 1594 Encoded JWE Ciphertext to create the value to integrity protect. 1595 This result (with line breaks for display purposes only) is: 1596 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp 1597 diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ. 1598 IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQ 1599 XtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfK 1600 KZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz 1601 2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9 1602 h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK 1603 -3T1zYlOIiIKBjsExQKZ-w. 1604 _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdF 1605 LjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M 1607 The representation of this value is: 1609 [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 1610 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 1611 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 73, 105, 119, 105, 97, 87, 1612 53, 48, 73, 106, 111, 105, 83, 70, 77, 121, 78, 84, 89, 105, 76, 67, 1613 74, 112, 100, 105, 73, 54, 73, 107, 70, 52, 87, 84, 104, 69, 81, 51, 1614 82, 69, 89, 85, 100, 115, 99, 50, 74, 72, 98, 71, 112, 105, 77, 49, 1615 74, 118, 87, 108, 69, 105, 102, 81, 46, 73, 80, 73, 95, 122, 49, 55, 1616 50, 104, 83, 87, 72, 77, 70, 103, 69, 68, 56, 69, 71, 57, 68, 77, 54, 1617 104, 73, 88, 85, 95, 54, 78, 97, 79, 49, 68, 73, 109, 67, 110, 48, 1618 118, 78, 101, 117, 111, 66, 113, 56, 52, 55, 83, 108, 54, 113, 119, 1619 95, 71, 72, 83, 89, 72, 74, 85, 81, 88, 116, 88, 74, 113, 55, 83, 95, 1620 67, 120, 87, 86, 114, 73, 56, 50, 119, 106, 114, 79, 121, 97, 81, 99, 1621 97, 53, 116, 76, 90, 82, 90, 99, 52, 53, 66, 102, 75, 72, 101, 113, 1622 66, 121, 84, 104, 75, 73, 50, 54, 49, 81, 101, 118, 69, 75, 53, 54, 1623 83, 121, 65, 119, 119, 88, 102, 75, 75, 90, 106, 83, 118, 107, 81, 1624 53, 100, 119, 84, 70, 83, 103, 102, 121, 55, 54, 114, 77, 83, 85, 1625 118, 86, 121, 110, 72, 89, 69, 104, 100, 67, 97, 116, 66, 70, 57, 72, 1626 87, 84, 65, 105, 88, 80, 120, 55, 104, 103, 90, 105, 120, 71, 49, 70, 1627 101, 80, 95, 81, 67, 109, 79, 121, 108, 122, 50, 86, 67, 108, 86, 1628 121, 89, 70, 67, 98, 106, 75, 82, 69, 79, 119, 66, 70, 102, 45, 112, 1629 117, 78, 89, 102, 79, 55, 53, 83, 51, 76, 78, 108, 74, 85, 116, 84, 1630 115, 71, 71, 81, 76, 50, 111, 84, 75, 112, 77, 115, 69, 105, 85, 84, 1631 100, 101, 102, 107, 106, 101, 57, 49, 86, 88, 57, 104, 56, 103, 55, 1632 57, 48, 56, 108, 70, 115, 103, 103, 98, 106, 86, 55, 78, 105, 99, 74, 1633 115, 117, 102, 117, 88, 120, 110, 84, 106, 49, 102, 99, 87, 73, 114, 1634 82, 68, 101, 78, 73, 79, 109, 97, 107, 105, 80, 69, 79, 68, 105, 48, 1635 103, 84, 83, 122, 48, 111, 117, 45, 87, 45, 76, 87, 75, 45, 51, 84, 1636 49, 122, 89, 108, 79, 73, 105, 73, 75, 66, 106, 115, 69, 120, 81, 75, 1637 90, 45, 119, 46, 95, 90, 95, 100, 106, 108, 73, 111, 67, 52, 77, 68, 1638 83, 67, 75, 105, 114, 101, 87, 83, 50, 98, 101, 116, 105, 52, 81, 54, 1639 105, 83, 71, 50, 85, 106, 70, 117, 106, 81, 118, 100, 122, 45, 95, 1640 80, 81, 100, 85, 99, 70, 78, 107, 79, 117, 108, 101, 103, 68, 54, 66, 1641 103, 106, 103, 100, 70, 76, 106, 101, 66, 52, 72, 72, 79, 79, 55, 85, 1642 72, 118, 80, 56, 80, 69, 68, 117, 48, 97, 48, 115, 65, 50, 97, 95, 1643 45, 67, 73, 48, 119, 50, 89, 81, 81, 50, 81, 81, 101, 51, 53, 77] 1645 A.2.10. JWE Integrity Value 1647 Compute the HMAC SHA-256 of this value using the CIK to create the 1648 JWE Integrity Value. This result is: 1650 [115, 141, 100, 225, 62, 30, 2, 0, 130, 183, 173, 230, 241, 147, 102, 1651 136, 232, 167, 49, 200, 133, 23, 42, 78, 22, 155, 226, 119, 184, 186, 1652 15, 73] 1654 A.2.11. Encoded JWE Integrity Value 1656 Base64url encode the resulting JWE Integrity Value to create the 1657 Encoded JWE Integrity Value. This result is: 1658 c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k 1660 A.2.12. Complete Representation 1662 Assemble the final representation: The Compact Serialization of this 1663 result is the concatenation of the Encoded JWE Header, the Encoded 1664 JWE Encrypted Key, the Encoded JWE Ciphertext, and the Encoded JWE 1665 Integrity Value in that order, with the four strings being separated 1666 by three period ('.') characters. 1668 The final result in this example (with line breaks for display 1669 purposes only) is: 1670 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDIiwiaW50IjoiSFMyNTYiLCJp 1671 diI6IkF4WThEQ3REYUdsc2JHbGpiM1JvWlEifQ. 1672 IPI_z172hSWHMFgED8EG9DM6hIXU_6NaO1DImCn0vNeuoBq847Sl6qw_GHSYHJUQ 1673 XtXJq7S_CxWVrI82wjrOyaQca5tLZRZc45BfKHeqByThKI261QevEK56SyAwwXfK 1674 KZjSvkQ5dwTFSgfy76rMSUvVynHYEhdCatBF9HWTAiXPx7hgZixG1FeP_QCmOylz 1675 2VClVyYFCbjKREOwBFf-puNYfO75S3LNlJUtTsGGQL2oTKpMsEiUTdefkje91VX9 1676 h8g7908lFsggbjV7NicJsufuXxnTj1fcWIrRDeNIOmakiPEODi0gTSz0ou-W-LWK 1677 -3T1zYlOIiIKBjsExQKZ-w. 1678 _Z_djlIoC4MDSCKireWS2beti4Q6iSG2UjFujQvdz-_PQdUcFNkOulegD6BgjgdF 1679 LjeB4HHOO7UHvP8PEDu0a0sA2a_-CI0w2YQQ2QQe35M. 1680 c41k4T4eAgCCt63m8ZNmiOinMciFFypOFpvid7i6D0k 1682 A.2.13. Validation 1684 This example illustrates the process of creating a JWE with a non- 1685 AEAD algorithm. These results can be used to validate JWE decryption 1686 implementations for these algorithms. Since all the algorithms used 1687 in this example produce deterministic results, the results above 1688 should be repeatable. 1690 A.3. Example Key Derivation with Outputs <= Hash Size 1692 This example uses the Concat KDF to derive the Content Encryption Key 1693 (CEK) and Content Integrity Key (CIK) from the Content Master Key 1694 (CMK) in the manner described in Section 4.12 of [JWA]. In this 1695 example, a 256 bit CMK is used to derive a 128 bit CEK and a 256 bit 1696 CIK. 1698 The CMK value is: 1700 [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 1701 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 1702 44, 207] 1704 A.3.1. CEK Generation 1706 When deriving the CEK from the CMK, the ASCII label "Encryption" 1707 ([69, 110, 99, 114, 121, 112, 116, 105, 111, 110]) is used. The 1708 input to the first hash round is the concatenation of the big endian 1709 number 1 ([0, 0, 0, 1]), the CMK, and the label. Thus the round 1 1710 hash input is: 1712 [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 1713 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 1714 240, 143, 156, 44, 207, 69, 110, 99, 114, 121, 112, 116, 105, 111, 1715 110] 1717 The SHA-256 hash of this value, which is the round 1 hash output, is: 1719 [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 1720 50, 69, 11, 237, 202, 71, 10, 96, 59, 199, 140, 88, 126, 147, 146, 1721 113, 222, 41] 1723 Given that 128 bits are needed for the CEK and the hash has produced 1724 256 bits, the CEK value is the first 128 bits of that value: 1726 [249, 255, 87, 218, 224, 223, 221, 53, 204, 121, 166, 130, 195, 184, 1727 50, 69] 1729 A.3.2. CIK Generation 1731 When deriving the CIK from the CMK, the ASCII label "Integrity" ([73, 1732 110, 116, 101, 103, 114, 105, 116, 121]) is used. The input to the 1733 first hash round is the concatenation of the big endian number 1 ([0, 1734 0, 0, 1]), the CMK, and the label. Thus the round 1 hash input is: 1736 [0, 0, 0, 1, 4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 1737 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 1738 240, 143, 156, 44, 207, 73, 110, 116, 101, 103, 114, 105, 116, 121] 1740 The SHA-256 hash of this value, which is the round 1 hash output, is: 1742 [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 1743 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 1744 225, 159] 1746 Given that 256 bits are needed for the CIK and the hash has produced 1747 256 bits, the CIK value is that same value: 1749 [218, 209, 130, 50, 169, 45, 70, 214, 29, 187, 123, 20, 3, 158, 111, 1750 122, 182, 94, 57, 133, 245, 76, 97, 44, 193, 80, 81, 246, 115, 177, 1751 225, 159] 1753 A.4. Example Key Derivation with Outputs >= Hash Size 1755 This example uses the Concat KDF to derive the Content Encryption Key 1756 (CEK) and Content Integrity Key (CIK) from the Content Master Key 1757 (CMK) in the manner described in Section 4.12 of [JWA]. In this 1758 example, a 512 bit CMK is used to derive a 256 bit CEK and a 512 bit 1759 CIK. 1761 The CMK value is: 1763 [148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 61, 34, 239, 1764 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 176, 68, 1765 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 138, 67, 1766 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 45, 156, 1767 249, 7, 225, 168] 1769 A.4.1. CEK Generation 1771 When deriving the CEK from the CMK, the ASCII label "Encryption" 1772 ([69, 110, 99, 114, 121, 112, 116, 105, 111, 110]) is used. The 1773 input to the first hash round is the concatenation of the big endian 1774 number 1 ([0, 0, 0, 1]), the CMK, and the label. Thus the round 1 1775 hash input is: 1777 [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 1778 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 1779 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 1780 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 1781 45, 156, 249, 7, 225, 168, 69, 110, 99, 114, 121, 112, 116, 105, 111, 1782 110] 1784 The SHA-256 hash of this value, which is the round 1 hash output, is: 1786 [137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 121, 78, 11, 144, 1787 10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 150, 116, 240, 159, 1788 64] 1790 Given that 256 bits are needed for the CEK and the hash has produced 1791 256 bits, the CEK value is that same value: 1793 [137, 5, 92, 9, 17, 47, 17, 86, 253, 235, 34, 247, 121, 78, 11, 144, 1794 10, 172, 38, 247, 108, 243, 201, 237, 95, 80, 49, 150, 116, 240, 159, 1795 64] 1797 A.4.2. CIK Generation 1799 When deriving the CIK from the CMK, the ASCII label "Integrity" ([73, 1800 110, 116, 101, 103, 114, 105, 116, 121]) is used. The input to the 1801 first hash round is the concatenation of the big endian number 1 ([0, 1802 0, 0, 1]), the CMK, and the label. Thus the round 1 hash input is: 1804 [0, 0, 0, 1, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 1805 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 1806 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 1807 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 1808 45, 156, 249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, 116, 1809 121] 1811 The SHA-256 hash of this value, which is the round 1 hash output, is: 1813 [11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 102, 100, 74, 88, 1814 149, 31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56, 37, 198, 1815 57, 17] 1817 Given that 512 bits are needed for the CIK and the hash has produced 1818 only 256 bits, another round is needed. The input to the second hash 1819 round is the concatenation of the big endian number 2 ([0, 0, 0, 2]), 1820 the CMK, and the label. Thus the round 2 hash input is: 1822 [0, 0, 0, 2, 148, 116, 199, 126, 2, 117, 233, 76, 150, 149, 89, 193, 1823 61, 34, 239, 226, 109, 71, 59, 160, 192, 140, 150, 235, 106, 204, 49, 1824 176, 68, 119, 13, 34, 49, 19, 41, 69, 5, 20, 252, 145, 104, 129, 137, 1825 138, 67, 23, 153, 83, 81, 234, 82, 247, 48, 211, 41, 130, 35, 124, 1826 45, 156, 249, 7, 225, 168, 73, 110, 116, 101, 103, 114, 105, 116, 1827 121] 1829 The SHA-256 hash of this value, which is the round 2 hash output, is: 1831 [149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141, 230, 39, 113, 1832 139, 84, 44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 96, 170, 1833 119, 236, 81] 1835 Given that 512 bits are needed for the CIK and the two rounds have 1836 collectively produced 512 bits of output, the CIK is the 1837 concatenation of the round 1 and round 2 hash outputs, which is: 1839 [11, 179, 132, 177, 171, 24, 126, 19, 113, 1, 200, 102, 100, 74, 88, 1840 149, 31, 41, 71, 57, 51, 179, 106, 242, 113, 211, 56, 56, 37, 198, 1841 57, 17, 149, 209, 221, 113, 40, 191, 95, 252, 142, 254, 141, 230, 39, 1842 113, 139, 84, 44, 156, 247, 47, 223, 101, 229, 180, 82, 231, 38, 96, 1843 170, 119, 236, 81] 1845 Appendix B. Acknowledgements 1847 Solutions for encrypting JSON content were also explored by JSON 1848 Simple Encryption [JSE] and JavaScript Message Security Format 1849 [I-D.rescorla-jsms], both of which significantly influenced this 1850 draft. This draft attempts to explicitly reuse as many of the 1851 relevant concepts from XML Encryption 1.1 1852 [W3C.CR-xmlenc-core1-20120313] and RFC 5652 [RFC5652] as possible, 1853 while utilizing simple compact JSON-based data structures. 1855 Special thanks are due to John Bradley and Nat Sakimura for the 1856 discussions that helped inform the content of this specification and 1857 to Eric Rescorla and Joe Hildebrand for allowing the reuse of text 1858 from [I-D.rescorla-jsms] in this document. 1860 Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund 1861 Jay for validating the examples in this specification. 1863 Appendix C. Document History 1865 [[ to be removed by the RFC editor before publication as an RFC ]] 1867 -04 1869 o Refer to the registries as the primary sources of defined values 1870 and then secondarily reference the sections defining the initial 1871 contents of the registries. 1873 o Normatively reference XML Encryption 1.1 1874 [W3C.CR-xmlenc-core1-20120313] for its security considerations. 1876 o Reference draft-jones-jose-jwe-json-serialization instead of 1877 draft-jones-json-web-encryption-json-serialization. 1879 o Described additional open issues. 1881 o Applied editorial suggestions. 1883 -03 1885 o Added the "kdf" (key derivation function) header parameter to 1886 provide crypto agility for key derivation. The default KDF 1887 remains the Concat KDF with the SHA-256 digest function. 1889 o Reordered encryption steps so that the Encoded JWE Header is 1890 always created before it is needed as an input to the AEAD 1891 "additional authenticated data" parameter. 1893 o Added the "cty" (content type) header parameter for declaring type 1894 information about the secured content, as opposed to the "typ" 1895 (type) header parameter, which declares type information about 1896 this object. 1898 o Moved description of how to determine whether a header is for a 1899 JWS or a JWE from the JWT spec to the JWE spec. 1901 o Added complete encryption examples for both AEAD and non-AEAD 1902 algorithms. 1904 o Added complete key derivation examples. 1906 o Added "Collision Resistant Namespace" to the terminology section. 1908 o Reference ITU.X690.1994 for DER encoding. 1910 o Added Registry Contents sections to populate registry values. 1912 o Numerous editorial improvements. 1914 -02 1916 o When using AEAD algorithms (such as AES GCM), use the "additional 1917 authenticated data" parameter to provide integrity for the header, 1918 encrypted key, and ciphertext and use the resulting 1919 "authentication tag" value as the JWE Integrity Value. 1921 o Defined KDF output key sizes. 1923 o Generalized text to allow key agreement to be employed as an 1924 alternative to key wrapping or key encryption. 1926 o Changed compression algorithm from gzip to DEFLATE. 1928 o Clarified that it is an error when a "kid" value is included and 1929 no matching key is found. 1931 o Clarified that JWEs with duplicate Header Parameter Names MUST be 1932 rejected. 1934 o Clarified the relationship between "typ" header parameter values 1935 and MIME types. 1937 o Registered application/jwe MIME type and "JWE" typ header 1938 parameter value. 1940 o Simplified JWK terminology to get replace the "JWK Key Object" and 1941 "JWK Container Object" terms with simply "JSON Web Key (JWK)" and 1942 "JSON Web Key Set (JWK Set)" and to eliminate potential confusion 1943 between single keys and sets of keys. As part of this change, the 1944 header parameter name for a public key value was changed from 1945 "jpk" (JSON Public Key) to "jwk" (JSON Web Key). 1947 o Added suggestion on defining additional header parameters such as 1948 "x5t#S256" in the future for certificate thumbprints using hash 1949 algorithms other than SHA-1. 1951 o Specify RFC 2818 server identity validation, rather than RFC 6125 1952 (paralleling the same decision in the OAuth specs). 1954 o Generalized language to refer to Message Authentication Codes 1955 (MACs) rather than Hash-based Message Authentication Codes (HMACs) 1956 unless in a context specific to HMAC algorithms. 1958 o Reformatted to give each header parameter its own section heading. 1960 -01 1962 o Added an integrity check for non-AEAD algorithms. 1964 o Added "jpk" and "x5c" header parameters for including JWK public 1965 keys and X.509 certificate chains directly in the header. 1967 o Clarified that this specification is defining the JWE Compact 1968 Serialization. Referenced the new JWE-JS spec, which defines the 1969 JWE JSON Serialization. 1971 o Added text "New header parameters should be introduced sparingly 1972 since an implementation that does not understand a parameter MUST 1973 reject the JWE". 1975 o Clarified that the order of the encryption and decryption steps is 1976 not significant in cases where there are no dependencies between 1977 the inputs and outputs of the steps. 1979 o Made other editorial improvements suggested by JOSE working group 1980 participants. 1982 -00 1984 o Created the initial IETF draft based upon 1985 draft-jones-json-web-encryption-02 with no normative changes. 1987 o Changed terminology to no longer call both digital signatures and 1988 HMACs "signatures". 1990 Authors' Addresses 1992 Michael B. Jones 1993 Microsoft 1995 Email: mbj@microsoft.com 1996 URI: http://self-issued.info/ 1998 Eric Rescorla 1999 RTFM, Inc. 2001 Email: ekr@rtfm.com 2003 Joe Hildebrand 2004 Cisco Systems, Inc. 2006 Email: jhildebr@cisco.com