Internet DRAFT - draft-erdtman-jose-cleartext-jwe

draft-erdtman-jose-cleartext-jwe







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:

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



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", <https://www.ecma-international.org/ecma-
              262/6.0/ECMA-262.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.



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,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

7.2.  Informative References

   [IANA.JOSE.Algorithms]
              IANA, "JSON Web Signature and Encryption Algorithms",
              <https://www.iana.org/assignments/jose/
              jose.xhtml#web-signature-encryption-algorithms>.

   [IANA.JOSE.HeaderParameters]
              IANA, "JSON Web Signature and Encryption Header
              Parameters", <https://www.iana.org/assignments/jose/
              jose.xhtml#web-signature-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]