JSON Object Signing and Encryption (JOSE) S. Erdtman Internet-Draft Spotify AB Intended status: Informational A. Rundgren Expires: September 5, 2018 Independent M. Jones Microsoft March 4, 2018 Cleartext JSON Web Encryption (JWE) draft-erdtman-jose-cleartext-jwe-00 Abstract Cleartext JSON Web Encryption (JWE) is a means of representing encrypted content as a JSON object without representing JSON values to be integrity protected in a non-JSON representation, such as base64url-encoded JSON. The integrity protection calculation for the authenticated encryption performed uses the predictable JSON serialization defined in ECMAScript version 6. Cleartext JWE builds on the JWE, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 5, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Erdtman, et al. Expires September 5, 2018 [Page 1] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Encryption Structure . . . . . . . . . . . . . . . . . . . . 3 3.1. Single Recipient with Direct Encryption . . . . . . . . . 4 3.2. Single Recipient with Key Encryption . . . . . . . . . . 4 3.3. Multiple Recipients . . . . . . . . . . . . . . . . . . . 5 3.4. Additional Authenticated Data (aad) . . . . . . . . . . . 6 4. Encrypting and Decrypting Cleartext JWEs . . . . . . . . . . 6 4.1. Message Encryption . . . . . . . . . . . . . . . . . . . 7 4.2. Message Decryption . . . . . . . . . . . . . . . . . . . 8 4.3. Serialization and Normalization . . . . . . . . . . . . . 11 4.4. ES6+ Interoperability Considerations . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1. JSON Header Parameters Registry . . . . . . . . . . . . . 11 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13 A.1. Common Data to Encrypt . . . . . . . . . . . . . . . . . 13 A.2. Symmetric Key "a256bitkey" . . . . . . . . . . . . . . . 13 A.3. Elliptic Curve Key "example.com:p256" . . . . . . . . . . 14 A.4. Elliptic Curve Key "example.com:p384" . . . . . . . . . . 14 A.5. RSA Key "example.com:r2048" . . . . . . . . . . . . . . . 14 A.6. Multiple Recipients with Common "alg" Header Parameter . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix C. Document History . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Cleartext JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Computing the integrity-protected data for the authenticated encryption operation performed uses the predictable JSON serialization defined in ECMAScript version 6 [ES6]. This enables integrity-protected Header Parameters to be represented in JSON, rather than in a non-JSON representation, such as base64url- encoded JSON. Erdtman, et al. Expires September 5, 2018 [Page 2] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 Cleartext JWS builds on the JWE [RFC7516], JWA [RFC7518], and JWK [RFC7517] specifications, reusing data structures and semantics from these specifications, where applicable. Cryptographic algorithm identifiers used by this specification come from the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. By keeping Header Parameters in cleartext, the structure becomes easier to read. However, cleartext Header Parameters are not suitable for all purposes, e.g., transport as an HTTP query parameter is not possible without additional encoding. The following is a summary of Cleartext JWE features: o All Header Parameters including "encrypted_key" are integrity protected. o All Header Parameters are represented in JSON, with no additional encoding. o The design choices parallel those in the closely-related Cleartext JWS specification. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Encryption Structure This section describes the representation of Cleartext JWEs. Cleartext JWEs are JSON objects. The members of this JSON object are JWE Header Parameters, with the addition of "recipients", "encrypted_key", and "ciphertext" members. The "recipients" member has the same usage as in the JWE JSON encoding, but the structure is slightly different. Instead of an object with members "header" and "encrypted_key", all of these are now Header Parameters. The "recipients" member MUST NOT be included unless the message is addressed to multiple recipients. The "encrypted_key" member is used in the top-level JSON object when there is only one recipient, i.e., the "recipients" array is not present. When multiple recipients are targeted, there is one "encrypted_key" value for each of them in the "recipients" array. Erdtman, et al. Expires September 5, 2018 [Page 3] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 The Cleartext JWE JSON structure can be illustrated as below: { , "recipients": [{ , "encrypted_key": "" }], "encrypted_key": "" "iv": "", "tag": "", "ciphertext": "" } Depending on the Key Management Mode and number of recipients, the structure and members used differs slightly. The following sub-section describes the different modes in more detail. All the examples encrypt the data specified in Appendix A.1. (Line breaks within values are for display purposes only.) 3.1. Single Recipient with Direct Encryption In the Direct Encryption mode, the parameters "alg" and "encrypted_key" are not applicable. Since a single recipient is targeted, the "recipients" parameter is not used. If not implied by the context, a "kid" can be used for identifying the CEK. The following shows an example of Direct Encryption: { "enc": "A256GCM", "alg": "dir", "kid": "a256bitkey", "iv": "764BCBnN8yMNu1tT", "tag": "6miH9pSBzQ-0nImMsvHmyQ", "ciphertext": "VZ3Zl0-vuFkZxCGJ_w5Q_SOVJTBVSw" } The example can be decrypted using the key in Appendix A.2. 3.2. Single Recipient with Key Encryption In the Key Encryption mode, a specific key is used to encrypt the CEK requiring the "alg" and "encrypted_key" parameters. Since a single recipient is targeted, the "recipients" parameter is not used. If not implied by the context, a "kid" can be used for identifying the encryption key. The following shows an example of Key Encryption using a public key: Erdtman, et al. Expires September 5, 2018 [Page 4] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 { "enc": "A128CBC-HS256", "alg": "ECDH-ES+A256KW", "kid": "example.com:p256", "epk": { "kty": "EC", "crv": "P-256", "x": "bzwthHR5_KL4Zs8bGyomwbJydZLXM0_yQKNL7jmfpPk", "y": "onq8dN7uJ61EPv54sy4hhyrc6s4wyEpkiQ968v_ib4s" }, "encrypted_key": "xLplzwvjqZXf7eTaNfAJtQPvWUra-EG-N_varxT7crTE9njua ahgPw", "iv": "ZflQlofG7n8xkBteEWtINg", "tag": "7BVYgQUpiWNQa9rUyz2QLQ", "ciphertext": "8FtQtpyS_WFyKhYU1CwgFWsexFIBun2Ry9YaIyTOfw8" } The example can be decrypted using the key in Appendix A.3. 3.3. Multiple Recipients Multiple recipients can be addressed with the key management modes Key Encryption, Key Wrapping and Key Agreement with Key Wrapping. When addressing multiple recipients, the "recipients" array is used. The "recipients" array contains a list of objects containing Header Parameters and an encrypted CEK ("encrypted_key"). A given Header Parameter MUST NOT occur in both the top-level JSON object and in a "recipients" array value. Any Header Parameter occurring in the top-level object applies to all recipients. For instance, "alg" MUST either be present at the top level or for each recipient, both not both. See Appendix A.6 for an example using a common "alg" value for multiple recipients. The following example shows a Cleartext JWE object having multiple recipients: Erdtman, et al. Expires September 5, 2018 [Page 5] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 { "enc": "A128CBC-HS256", "recipients": [{ "alg": "ECDH-ES+A256KW", "kid": "example.com:p256", "epk": { "kty": "EC", "crv": "P-256", "x": "YbE9lUeaQzQlmYMnJ6BRxsvN9Eq7HUfomksZ442S7JU", "y": "rvwope5t_ZEnnysDyZqoajnYhtl3nrHBNjL7on4C6PE" }, "encrypted_key": "2eaoZkaKkyfhhkzwl0YQk0I8seHuq6MHqoXJNEHIiXqKz6a 0VEwmSQ" },{ "alg": "RSA-OAEP-256", "kid": "example.com:r2048", "encrypted_key": "HtLQyLSl-_0acyV2VjMOus_n7J14eXRdONue3cd3thRRQbT LO9W3rE7cLrkBfjB-DyQ9OnNUrWSkRaT834yI4cNO9t_LsC WAz4GMaS7lQoURVN5Tbujb2aUmYGBuQef3uozC04QOmAkhV vdJWmdAm78-pxrZaUFOqjNYGiRhCjijIOpn9xX-fX1b04sL MTQ8jTopnQWQjUE52jELRfr8bxAfLjy6S34kg8A-2FBQia7 hy4BTXgvVvlhmepGdB5USHCnLDq_s8ozUSYFJtvIv74eF8v 05H-P47d5uI_P-vDJgPhspcP5A-3_uj8xSMWNeeXcBm7vf3 rcQfL7cm-IPYQ" }], "iv": "DQLdn_K_bE7z1OffRZySzQ", "tag": "W_i_9eaLo0Vg9TTeGxnvfw", "ciphertext": "hcVRCcUO9ZjjEDm87cyba_ss2mWEIFGUVYM9Y2Gw-HU" } The example can be decrypted using the keys in Appendix A.3 and Appendix A.5. 3.4. Additional Authenticated Data (aad) Unlike the JWE JSON Serialization, Cleartext JWE does not have an "aad" member. Since Cleartext JWE integrity protects the whole Header Parameters structure, one can add additional Header Parameters to integrity protect additional data that is connected to the ciphertext. See Section 4.2 of [RFC7516] (Public Header Parameter Names) and Section 4.3 of [RFC7516] (Private Header Parameter Names) for details on adding additional Header Parameters. 4. Encrypting and Decrypting Cleartext JWEs Erdtman, et al. Expires September 5, 2018 [Page 6] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 4.1. Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. Most steps are equivalent to the ones in JWE. Those that have been changed are indicated as [Modified]. 1. Determine the Key Management Mode employed by the algorithm used to determine the Content Encryption Key value. (This is the algorithm recorded in the "alg" (algorithm) Header Parameter of the resulting JWE.) 2. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, generate a random CEK value. See RFC 4086 [RFC4086] for considerations on generating random values. The CEK MUST have a length equal to that required for the content encryption algorithm ("enc"). 3. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to wrap the CEK. 4. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, encrypt the CEK to the recipient and let the result be the JWE Encrypted Key ("encrypted_key"). 5. When Direct Key Agreement or Direct Encryption are employed, let the JWE Encrypted Key be the empty octet sequence. 6. When Direct Encryption is employed, let the CEK be the shared symmetric key. 7. Compute the encoded key value BASE64URL(JWE Encrypted Key). 8. If more than one recipient is being addressed, repeat this process (steps 1-7) for each recipient. 9. Generate a random JWE Initialization Vector of the correct size for the content encryption algorithm (if required for the algorithm); otherwise, let the JWE Initialization Vector be the empty octet sequence. Erdtman, et al. Expires September 5, 2018 [Page 7] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 10. Compute the encoded Initialization Vector value BASE64URL(JWE Initialization Vector). 11. If a "zip" parameter was included, compress the plaintext using the specified compression algorithm and let M be the octet sequence representing the compressed plaintext; otherwise, let M be the octet sequence representing the plaintext. 12. [Modified] Create the JSON object(s) containing the desired set of Header Parameters, including "encrypted_key" if one recipient is addressed or the "recipients" array if more than one recipient is addressed. 13. [Modified] Serialize the JSON Header Parameters according to instructions in Section 4.3. 14. [Modified] Let the Additional Authenticated Data encryption parameter be the serialized JSON header. 15. Encrypt M using the CEK, the JWE Initialization Vector, and the Additional Authenticated Data value using the specified content encryption algorithm to create the JWE Ciphertext value and the JWE Authentication Tag (which is the Authentication Tag output from the encryption operation). 16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext). 17. Compute the encoded Authentication Tag value BASE64URL(JWE Authentication Tag). 18. [Modified] Not applicable to Cleartext JWE, see Section 3.4. 19. [Modified] Finalize the encryption by adding the JWE Initialization Vector, JWE Authentication Tag and JWE Ciphertext to the JSON Header Parameters and let this be the encrypted package. Note: The "iv" member MUST NOT be present when the JWE Initialization Vector value is empty. 4.2. Message Decryption The message decryption process is the reverse of the encryption process. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of these steps fail, the encrypted content cannot be validated. When there are multiple recipients, it is an application decision which of the recipients' encrypted content must successfully validate Erdtman, et al. Expires September 5, 2018 [Page 8] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 for the Cleartext JWE to be accepted. In some cases, encrypted content for all recipients must successfully validate or the Cleartext JWE will be considered invalid. In other cases, only the encrypted content for a single recipient needs to be successfully validated. However, in all cases, the encrypted content for at least one recipient MUST successfully validate or the Cleartext JWE MUST be considered invalid. Most steps are equivalent to the ones in JWE. Those that has been changed or removed are indicated as [Modified]. This is a temporary construction to make it easy to understand the differences between JWE and Cleartext JWE, and will be removed in final version. 1. [Modified] Parse the Cleartext JWE JSON structure. 2. [Modified] Extract and remove Cleartext JWE components JWE Initialization Vector ("iv"), JWE Ciphertext ("ciphertext") and JWE Authentication Tag ("tag"). Let the remaining JSON be the JWE Protected Header. Base64url decode the encoded representations of the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag, following the restriction that no line breaks, whitespace, or other additional characters have been used. 3. [Modified] Not applicable to Cleartext JWE. 4. [Modified] Not applicable to Cleartext JWE. 5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithms being used, or by the "crit" Header Parameter value, and that the values of those parameters are also understood and supported. 6. Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter. 7. Verify that the Cleartext JWE uses a key known to the recipient. 8. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to decrypt the JWE Encrypted Key. 9. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, decrypt the JWE Encrypted Key to produce Erdtman, et al. Expires September 5, 2018 [Page 9] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 the CEK. The CEK MUST have a length equal to that required for the content encryption algorithm. Note that when there are multiple recipients, each recipient will only be able to decrypt JWE Encrypted Key values that were encrypted to a key in that recipient's possession. It is therefore normal to only be able to decrypt one of the per-recipient JWE Encrypted Key values to obtain the CEK value. Also, see JWE Section 11.5 for security considerations on mitigating timing attacks. 10. [Modified] When Direct Key Agreement or Direct Encryption are employed, verify that the JWE Encrypted Key value is absent. 11. When Direct Encryption is employed, let the CEK be the shared symmetric key. 12. Record whether the CEK could be successfully determined for this recipient or not. 13. [Modified] If the more than one recipient is addressed, repeat this process (steps 5-12) for each recipient contained in the representation. 14. [Modified] Serialize the JWE Protected Header according to instructions in Section 4.3. 15. [Modified] Let the Additional Authenticated Data encryption parameter be the serialized the JWE Protected Header. 16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect. 17. If a "zip" parameter was included, uncompress the decrypted plaintext using the specified compression algorithm. 18. If there was no recipient for which all of the decryption steps succeeded, then the JWE MUST be considered invalid. Otherwise, output the plaintext. With multiple recipients, also return a result to the application indicating for which of the recipients the decryption succeeded and failed. 19. [Modified] Additional step. If the JSON data structure needs to be verified later, put back the JWE Initialization Vector Erdtman, et al. Expires September 5, 2018 [Page 10] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 ("iv"), JWE Ciphertext ("ciphertext") and JWE Authentication Tag ("tag") into the JWE Protected Header. Finally, note that it is an application decision which algorithms may be used in a given context. Even if a Cleartext JWE can be successfully decrypted, unless the algorithms used in the JWE are acceptable to the application, it SHOULD consider the Cleartext JWE to be invalid. 4.3. Serialization and Normalization When integrity protecting (or signing) unencoded JSON data, the serialization (canonicalization) of it used as an input to the cryptographic function needs to be consistent across platforms. See the "Serialization and Normalization" section of the "Cleartext JSON Web Signature (JWS)" specification for a summary of how to achieve predictable serialization using the ES6 rules. If these rules are applied to the public key encryption example in Section 3.1, it should result in the following string (with line breaks within values for display purposes only): {"enc":"A128CBC-HS256","alg":"ECDH-ES+A256KW","kid":"example.com: p256","epk":{"kty":"EC","crv":"P-256","x":"bzwthHR5_KL4Zs8bGyomwb JydZLXM0_yQKNL7jmfpPk","y":"onq8dN7uJ61EPv54sy4hhyrc6s4wyEpkiQ968 v_ib4s"},"encrypted_key":"xLplzwvjqZXf7eTaNfAJtQPvWUra-EG-N_varxT 7crTE9njuaahgPw"} 4.4. ES6+ Interoperability Considerations See the "ES6+ Interoperability Considerations" section of the "Cleartext JSON Web Signature (JWS)" specification for a description of special care that may need to be taken when ordering the Header Parameter names. 5. IANA Considerations 5.1. JSON Header Parameters Registry This section registers the following Header Parameters in the IANA "JSON Web Signature and Encryption Header Parameters" registry [IANA.JOSE.HeaderParameters]. 5.1.1. Registry Contents o Header Parameter Name: "ciphertext" o Header Parameter Description: The base64url-encoded ciphertext Erdtman, et al. Expires September 5, 2018 [Page 11] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 o Header Parameter Usage Location(s): "Cleartext JWE" o Change Controller: IESG o Specification Document(s): [this document] o Header Parameter Name: "encrypted_key" o Header Parameter Description: The base64url-encoded encrypted CEK o Header Parameter Usage Location(s): "Cleartext JWE" o Change Controller: IESG o Specification Document(s): [this document] o Header Parameter Name: "recipients" o Header Parameter Description: List of targeted recipients, each with a set of Header Parameters o Header Parameter Usage Location(s): "Cleartext JWE" o Change Controller: IESG o Specification Document(s): [this document] 6. Security Considerations The same security considerations apply to this specification as do for JWE [RFC7516]. 7. References 7.1. Normative References [ES6] Ecma International, "ECMAScript 2015 Language Specification", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . Erdtman, et al. Expires September 5, 2018 [Page 12] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 7.2. Informative References [IANA.JOSE.Algorithms] IANA, "JSON Web Signature and Encryption Algorithms", . [IANA.JOSE.HeaderParameters] IANA, "JSON Web Signature and Encryption Header Parameters", . Appendix A. Test Vectors This section contains a set of test vectors. (Line breaks within values are for display purposes only.) A.1. Common Data to Encrypt All examples in this specification encrypt the plaintext: "Hello encrypted world!". Expressed as decimal bytes this yields: 72, 101, 108, 108, 111, 32, 101, 110, 99, 114, 121, 112, 116, 101, 100, 32, 119, 111, 114, 108, 100, 33 A.2. Symmetric Key "a256bitkey" 256-bit symmetric key, here expressed in hexadecimal notation: 7fdd851a3b9d2dafc5f0d00030e22b9343900cd42ede4948568a4a2ee655291a Erdtman, et al. Expires September 5, 2018 [Page 13] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 A.3. Elliptic Curve Key "example.com:p256" Elliptic Curve private key, represented as a JWK: { "kid": "example.com:p256", "kty": "EC", "crv": "P-256", "x": "censDzcMEkgiePz6DXB7cDuwFemshAFR90UNVQFCg8Q", "y": "xq8rze6ewG0-eVcSF72J77gKiD0IHnzpwHaU7t6nVeY", "d": "nEsftLbi5u9pI8B0-drEjIuJzQgZie3yeqUR3BwWDl4" } A.4. Elliptic Curve Key "example.com:p384" Elliptic Curve private key, represented as a JWK: { "kid": "example.com:p384", "kty": "EC", "crv": "P-384", "x": "GLfdsvEwphRzS_twup7UFPVOk7_CKgHZ7dt_fJ2QHPBdJa1c5pfJcRIWTfT0l pg9", "y": "ovA5_QXmFbj9U4pjZ1AX_ZdVyIRZUBWW9cuZda_tupKfWQfmcQHzDmHGHbxl9 Xxl", "d": "Qsgq80kMs40sAn1gB7gLxAk1se37Kmh9AG18wWZ3SqgcPPRq1wwidNTi866Gt 4_0" } A.5. RSA Key "example.com:r2048" RSA private key, represented as a JWK: Erdtman, et al. Expires September 5, 2018 [Page 14] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 { "kid": "example.com:r2048", "kty": "RSA", "n": "hFWEXArvaZEpSP5qNX7x4C4Hl28GJQTNvnDwkfqiWs63kXbdyPeS06bz6GnY3 tfQ_093nGauWsimqKBmGAGMPtsV83Qxw1OIeO4ujbIIb9pema0qtVqs0MWlHx klZGFkYfAmbuEUFxYDeLDHe0bkkXbSlB7_t8pCSvc8HLgHjEQjYOlFRwjR0D- uLo-xgsCbpmCtYkB5lcT_zFgpRgY4zJNLSv7GZiz2S4Fc5ArGjd34lL47-L8b ozuYjqNOv9sqX0Zgll5XaJ1ndvr7UqZu1xQFgm38reoM3IarBP_SkEFbt_v9i ak602VO3k28fQhMaocP7JWR2YLT3kZM0-WTFw", "e": "AQAB", "d": "Q6iBYpnIrB2mkQZagP1lZuvBv9_osVaSZpLRvKD7DxhvbDTs0coaTJIoVCSB1 _VZip8zlUg-TnYWF1Liv9VSwfQ7ddxrcOUtej60mId0ntNz2HhbxJsWjiru8E ZoArl0nEovLDNxlRgRMEyZwOKPC_xHT6nFrk7_s9pR5pEEcubGLAVBKnLCoPd Lr-CBjCvWfJo73W5AZxoSb8MdWQOi5viXHURpr1Y_uBRsMuclovM56Vt05etM sB1AbcTLUDwAuYrZWa1c08ql60ft7b3v6Q_rCL7EHtFU3PHAuP0mV7tM5BfAP f4T0g9pbr4GOw7eqQCiYgPFE7gmCR_PDxv5YQ", "p": "6DIM343hAtj1hQprJaVQ3T8YeIytIQ7Ma544C0A8BX-irjJfARy4fAlTSyBFe auZ0WdbMGtKpAIgNVmfCfuP7W1bXw7UaxpqsQlbw54K1VtBs8xG-lee_2YQ3l UlIiC1at6L0jxWYNkvp-LIfU2F5ZQir5ZWVXwgdMcgoNBABMc", "q": "keacq0goV7pAtG2h33OAk-XOSclIF1agvEMMOKuud5V-vGQ6OaYldlYqZmSGg F7RVlX0GZO70nPqatjd2G-tI8wEq5K_xmLQurUPFW8g___z0CTgJ62KbjFxCt Gny5rsObX9im6cCc_EOtWZRaApzO8ykxfo1QcEjT4k1na7DzE", "dp": "nPmJPnFal2Q5x_GdMlwq6QhI8OaZ_OlWRcM3PFP2v_jj8ERZehUCm8hqKTXu Ai2C1dC8E2XVlj9hqu-l10fcq7Tsurz52laHnpwnD35-8HK7XmRR79jgwuUr rkN90S6vt0ow2La15s-tqiBlTmDkjqqxMGfAghZiktA0PMPNI-0", "dq": "D3c1lkZw2FPK9hVE-m3A7GyIwHOQq8CoCyzER-GS_eQf6hJpxaCiCfg6SF5R j5v9brxvwqJRX46gA7F3WrED1m6S9Cj7ISlqXNBCiBAenGRiUOcHx8zyhpnB FNeChOeoMLnk5V6yNawLbf0kYSgIJkwYvVTkfmhfCCXVO9KcI5E", "qi": "wV0NzfCakfog1NFjtPzcga1MtkpizgPkxcP9LjNdvXW2YQZhM6GIEGjsu3iv TrHrrM-4_bTQHOoTtfIY7wdqBKlwQTJOI0dH9FbNJ4ecGojRwgv83TN8aNKh 17Tt44jI5oibs2P-31B_VW9R1wwhnnOuCYpABfoSbtHIoCRme5I" } A.6. Multiple Recipients with Common "alg" Header Parameter Erdtman, et al. Expires September 5, 2018 [Page 15] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 { "enc": "A128CBC-HS256", "alg": "ECDH-ES+A256KW", "recipients": [{ "kid": "example.com:p256", "epk": { "kty": "EC", "crv": "P-256", "x": "_CSnca_rR2mPQJXVb_TCdcjF3CoPzNToh9_QxAh64DQ", "y": "y-q57nJ80iujgx8XcfaudEWXnZybMN4lI-C0nAnIBOA" }, "encrypted_key": "U2bxavr4j-H8cGL24fswTUh21-gk7yudENcUGdZtyKJlkiK KVAcqdg" },{ "kid": "example.com:p384", "epk": { "kty": "EC", "crv": "P-384", "x": "McBmQfP4AwSn3_OjTy09r4w8teqt_DiYBxDYl54LeE0otEtlkRFUctWPo aew9qVK", "y": "bifK7MyfngeJD26PuRnSDK675MqRDJ1VPXv44MIRxfy21Nz1dl7IpDhBx f_TYhJp" }, "encrypted_key": "U2M7ZKoQ4v7nzE-uV7zCMhr6FM4Q-WGqIwtikxhuD0EUD4S mcZ7CPw" }], "iv": "ti3c2XIIccQQgnEx5h9OHA", "tag": "C5NGFW1mPFbqVclGFnpTdQ", "ciphertext": "wSOtggwQ9HCVOg11TRTUbmtA8VjWlMG9UDEHA2KzN5g" } The example can be decrypted using the keys in Appendix A.3 and Appendix A.4. Appendix B. Acknowledgements This document builds on the work done in the JOSE working group, so a big thanks goes out to all involved in that work. It is specifically inspired by JWE, so special thanks are due to the authors of that document, Michael B. Jones and Joe Hildebrand. Building on ES6 number normalization was originally proposed by James Manger. This ultimately led to the adoption of the entire ES6 JSON processing model. Erdtman, et al. Expires September 5, 2018 [Page 16] Internet-Draft draft-erdtman-jose-cleartext-jwe March 2018 Appendix C. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] -00 o Initial version. Authors' Addresses Samuel Erdtman Spotify AB Birger Jarlsgatan 61, 4tr Stockholm 113 56 Sweden Email: erdtman@spotify.com Anders Rundgren Independent Montpellier France Email: anders.rundgren.net@gmail.com Michael B. Jones Microsoft Email: mbj@microsoft.com URI: http://self-issued.info/ Erdtman, et al. Expires September 5, 2018 [Page 17]