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 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. Terminology
• 3. Encryption Structure
• 3.1. Single Recipient with Direct Encryption
• 3.2. Single Recipient with Key Encryption
• 3.3. Multiple Recipients
• 3.4. Additional Authenticated Data (aad)
• 4. Encrypting and Decrypting Cleartext JWEs
• 4.1. Message Encryption
• 4.2. Message Decryption
• 4.3. Serialization and Normalization
• 4.4. ES6+ Interoperability Considerations
• 5. IANA Considerations
• 5.1. JSON Header Parameters Registry
• 5.1.1. Registry Contents
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Test Vectors
• A.1. Common Data to Encrypt
• A.2. Symmetric Key "a256bitkey"
• A.3. Elliptic Curve Key "example.com:p256"
• A.4. Elliptic Curve Key "example.com:p384"
• A.5. RSA Key "example.com:r2048"
• A.6. Multiple Recipients with Common "alg" Header Parameter
• Appendix B. Acknowledgements
• Appendix C. Document History
• Authors' Addresses

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.

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:

• All Header Parameters including encrypted_key are integrity protected.
• All Header Parameters are represented in JSON, with no additional encoding.
• 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.

The Cleartext JWE JSON structure can be illustrated as below:

{
  <JWE Header Parameters />,
  "recipients": [{
    <JWE Header Parameters />,
    "encrypted_key": "<base64url-encoded data />"
  }],
  "encrypted_key": "<base64url-encoded data />"
  "iv": "<base64url-encoded data />",
  "tag": "<base64url-encoded data />",
  "ciphertext": "<base64url-encoded data />"
}

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:

{
  "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:

{
  "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

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.
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 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 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 (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

• Header Parameter Name: ciphertext
• Header Parameter Description: The base64url-encoded ciphertext
• Header Parameter Usage Location(s): Cleartext JWE
• Change Controller: IESG
• Specification Document(s): [this document]

• Header Parameter Name: encrypted_key
• Header Parameter Description: The base64url-encoded encrypted CEK
• Header Parameter Usage Location(s): Cleartext JWE
• Change Controller: IESG
• Specification Document(s): [this document]

• Header Parameter Name: recipients
• Header Parameter Description: List of targeted recipients, each with a set of Header Parameters
• Header Parameter Usage Location(s): Cleartext JWE
• Change Controller: IESG
• 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

7.2. Informative References

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

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:

{
  "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

{
  "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.

Appendix C. Document History

[[ to be removed by the RFC Editor before publication as an RFC ]]

-00

• Initial version.

Authors' Addresses