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]
