< draft-ietf-jose-json-web-encryption-16.txt   draft-ietf-jose-json-web-encryption-17.txt >
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track E. Rescorla Intended status: Standards Track E. Rescorla
Expires: March 19, 2014 RTFM Expires: April 10, 2014 RTFM
J. Hildebrand J. Hildebrand
Cisco Cisco
September 15, 2013 October 7, 2013
JSON Web Encryption (JWE) JSON Web Encryption (JWE)
draft-ietf-jose-json-web-encryption-16 draft-ietf-jose-json-web-encryption-17
Abstract Abstract
JSON Web Encryption (JWE) represents encrypted content using JSON Web Encryption (JWE) represents encrypted content using
JavaScript Object Notation (JSON) based data structures. JavaScript Object Notation (JSON) based data structures.
Cryptographic algorithms and identifiers for use with this Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA) specification are described in the separate JSON Web Algorithms (JWA)
specification and IANA registries defined by that specification. specification and IANA registries defined by that specification.
Related digital signature and MAC capabilities are described in the Related digital signature and MAC capabilities are described in the
separate JSON Web Signature (JWS) specification. separate JSON Web Signature (JWS) specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2014. This Internet-Draft will expire on April 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 9 3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 7
3.1. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 9
4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Registered Header Parameter Names . . . . . . . . . . . . 11 4.1. Registered Header Parameter Names . . . . . . . . . . . . 11
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 11 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 11
4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 12 4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 12
4.1.3. "zip" (Compression Algorithm) Header Parameter . . . . 12 4.1.3. "zip" (Compression Algorithm) Header Parameter . . . . 12
4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 12 4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 12
4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13 4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
4.1.6. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13 4.1.6. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header 4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 13 Parameter . . . . . . . . . . . . . . . . . . . . . . 13
4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14 4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . . 13
4.1.9. "kid" (Key ID) Header Parameter . . . . . . . . . . . 14 4.1.9. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13
4.1.10. "typ" (Type) Header Parameter . . . . . . . . . . . . 14 4.1.10. "typ" (Type) Header Parameter . . . . . . . . . . . . 13
4.1.11. "cty" (Content Type) Header Parameter . . . . . . . . 15 4.1.11. "cty" (Content Type) Header Parameter . . . . . . . . 14
4.1.12. "crit" (Critical) Header Parameter . . . . . . . . . . 15 4.1.12. "crit" (Critical) Header Parameter . . . . . . . . . . 14
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 16 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 16 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 14
5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . . 16 5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . . 14
5.1. Message Encryption . . . . . . . . . . . . . . . . . . . . 16 5.1. Message Encryption . . . . . . . . . . . . . . . . . . . . 14
5.2. Message Decryption . . . . . . . . . . . . . . . . . . . . 18 5.2. Message Decryption . . . . . . . . . . . . . . . . . . . . 16
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 21 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 19
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 21 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 19
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 21 7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 19
7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . . 22 7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . . 19
8. Distinguishing Between JWS and JWE Objects . . . . . . . . . . 25 8. Distinguishing Between JWS and JWE Objects . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. JWE Header Parameter Names Registration . . . . . . . . . 25 9.1. JWE Header Parameter Names Registration . . . . . . . . . 23
9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 26 9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 30 Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 27
A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 30 A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 27
A.1.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 30 A.1.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 27
A.1.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 30 A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 27
A.1.3. Content Encryption Key (CEK) . . . . . . . . . . . . . 30 A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 28
A.1.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 31 A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 29
A.1.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 31 A.1.5. Additional Authenticated Data . . . . . . . . . . . . 29
A.1.6. Initialization Vector . . . . . . . . . . . . . . . . 32 A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 29
A.1.7. Additional Authenticated Data . . . . . . . . . . . . 32 A.1.7. Complete Representation . . . . . . . . . . . . . . . 30
A.1.8. Content Encryption . . . . . . . . . . . . . . . . . . 32 A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . . 30
A.1.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 33
A.1.10. Encoded JWE Authentication Tag . . . . . . . . . . . . 33
A.1.11. Complete Representation . . . . . . . . . . . . . . . 33
A.1.12. Validation . . . . . . . . . . . . . . . . . . . . . . 33
A.2. Example JWE using RSAES-PKCS1-V1_5 and A.2. Example JWE using RSAES-PKCS1-V1_5 and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 34 AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 30
A.2.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 34 A.2.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 31
A.2.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 34 A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 31
A.2.3. Content Encryption Key (CEK) . . . . . . . . . . . . . 34 A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 31
A.2.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 34 A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 33
A.2.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 35 A.2.5. Additional Authenticated Data . . . . . . . . . . . . 33
A.2.6. Initialization Vector . . . . . . . . . . . . . . . . 36 A.2.6. Content Encryption . . . . . . . . . . . . . . . . . . 33
A.2.7. Additional Authenticated Data . . . . . . . . . . . . 36 A.2.7. Complete Representation . . . . . . . . . . . . . . . 34
A.2.8. Content Encryption . . . . . . . . . . . . . . . . . . 36 A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . . 34
A.2.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 36
A.2.10. Encoded JWE Authentication Tag . . . . . . . . . . . . 37
A.2.11. Complete Representation . . . . . . . . . . . . . . . 37
A.2.12. Validation . . . . . . . . . . . . . . . . . . . . . . 37
A.3. Example JWE using AES Key Wrap and A.3. Example JWE using AES Key Wrap and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 37 AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 34
A.3.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 38 A.3.1. JWE Header . . . . . . . . . . . . . . . . . . . . . . 34
A.3.2. Encoded JWE Header . . . . . . . . . . . . . . . . . . 38 A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 35
A.3.3. Content Encryption Key (CEK) . . . . . . . . . . . . . 38 A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 35
A.3.4. Key Encryption . . . . . . . . . . . . . . . . . . . . 38 A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 36
A.3.5. Encoded JWE Encrypted Key . . . . . . . . . . . . . . 39 A.3.5. Additional Authenticated Data . . . . . . . . . . . . 36
A.3.6. Initialization Vector . . . . . . . . . . . . . . . . 39 A.3.6. Content Encryption . . . . . . . . . . . . . . . . . . 36
A.3.7. Additional Authenticated Data . . . . . . . . . . . . 39 A.3.7. Complete Representation . . . . . . . . . . . . . . . 37
A.3.8. Content Encryption . . . . . . . . . . . . . . . . . . 39 A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . . 37
A.3.9. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 40 A.4. Example JWE using JWE JSON Serialization . . . . . . . . . 37
A.3.10. Encoded JWE Authentication Tag . . . . . . . . . . . . 40 A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 38
A.3.11. Complete Representation . . . . . . . . . . . . . . . 40 A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . . 38
A.3.12. Validation . . . . . . . . . . . . . . . . . . . . . . 40 A.4.3. JWE Unprotected Header . . . . . . . . . . . . . . . . 38
A.4. Example JWE Using JWE JSON Serialization . . . . . . . . . 40 A.4.4. Complete JWE Header Values . . . . . . . . . . . . . . 38
A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 41 A.4.5. Additional Authenticated Data . . . . . . . . . . . . 39
A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . . 41 A.4.6. Content Encryption . . . . . . . . . . . . . . . . . . 39
A.4.3. JWE Unprotected Header . . . . . . . . . . . . . . . . 41 A.4.7. Complete JWE JSON Serialization Representation . . . . 39
A.4.4. Complete JWE Header Values . . . . . . . . . . . . . . 42 Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 40
A.4.5. Additional Authenticated Data . . . . . . . . . . . . 42 B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . . 40
A.4.6. Content Encryption . . . . . . . . . . . . . . . . . . 42 B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . . 41
A.4.7. Encoded JWE Ciphertext . . . . . . . . . . . . . . . . 42 B.3. 64 Bit Big Endian Representation of AAD Length . . . . . . 41
A.4.8. Encoded JWE Authentication Tag . . . . . . . . . . . . 43 B.4. Initialization Vector Value . . . . . . . . . . . . . . . 41
A.4.9. Complete JWE JSON Serialization Representation . . . . 43 B.5. Create Input to HMAC Computation . . . . . . . . . . . . . 42
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 43 B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . . 42
B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . . 44 B.7. Truncate HMAC Value to Create Authentication Tag . . . . . 42
B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . . 44 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 42
B.3. 64 Bit Big Endian Representation of AAD Length . . . . . . 44 Appendix D. Document History . . . . . . . . . . . . . . . . . . 43
B.4. Initialization Vector Value . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
B.5. Create Input to HMAC Computation . . . . . . . . . . . . . 45
B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . . 45
B.7. Truncate HMAC Value to Create Authentication Tag . . . . . 45
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix D. Document History . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
JSON Web Encryption (JWE) represents encrypted content using JSON Web Encryption (JWE) represents encrypted content using
JavaScript Object Notation (JSON) [RFC4627] based data structures. JavaScript Object Notation (JSON) [RFC4627] based data structures.
The JWE cryptographic mechanisms encrypt and provide integrity The JWE cryptographic mechanisms encrypt and provide integrity
protection for an arbitrary sequence of octets. protection for an arbitrary sequence of octets.
Two closely related serializations for JWE objects are defined. The Two closely related serializations for JWE objects are defined. The
JWE Compact Serialization is a compact, URL-safe representation JWE Compact Serialization is a compact, URL-safe representation
skipping to change at page 5, line 39 skipping to change at page 4, line 39
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in Key words for use in document are to be interpreted as described in Key words for use in
RFCs to Indicate Requirement Levels [RFC2119]. If these words are RFCs to Indicate Requirement Levels [RFC2119]. If these words are
used without being spelled in uppercase then they are to be used without being spelled in uppercase then they are to be
interpreted with their normal natural language meanings. interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2.
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
of STRING.
ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING.
The concatenation of two values A and B is denoted as A || B.
2. Terminology 2. Terminology
These terms defined by the JSON Web Signature (JWS) [JWS]
specification are incorporated into this specification: "JSON Web
Signature (JWS)", "JSON Text Object", "Base64url Encoding",
"Collision Resistant Name", and "StringOrURI".
These terms are defined for use by this specification:
JSON Web Encryption (JWE) A data structure representing an encrypted JSON Web Encryption (JWE) A data structure representing an encrypted
message. The structure represents five values: the JWE Header, and integrity protected message.
the JWE Encrypted Key, the JWE Initialization Vector, the JWE
Ciphertext, and the JWE Authentication Tag.
Authenticated Encryption with Associated Data (AEAD) An AEAD Authenticated Encryption with Associated Data (AEAD) An AEAD
algorithm is one that encrypts the Plaintext, allows Additional algorithm is one that encrypts the Plaintext, allows Additional
Authenticated Data to be specified, and provides an integrated Authenticated Data to be specified, and provides an integrated
content integrity check over the Ciphertext and Additional content integrity check over the Ciphertext and Additional
Authenticated Data. AEAD algorithms accept two inputs, the Authenticated Data. AEAD algorithms accept two inputs, the
Plaintext and the Additional Authenticated Data value, and produce Plaintext and the Additional Authenticated Data value, and produce
two outputs, the Ciphertext and the Authentication Tag value. AES two outputs, the Ciphertext and the Authentication Tag value. AES
Galois/Counter Mode (GCM) is one such algorithm. Galois/Counter Mode (GCM) is one such algorithm.
skipping to change at page 6, line 25 skipping to change at page 5, line 44
Authentication Tag An output of an AEAD operation that ensures the Authentication Tag An output of an AEAD operation that ensures the
integrity of the Ciphertext and the Additional Authenticated Data. integrity of the Ciphertext and the Additional Authenticated Data.
Note that some algorithms may not use an Authentication Tag, in Note that some algorithms may not use an Authentication Tag, in
which case this value is the empty octet sequence. which case this value is the empty octet sequence.
Content Encryption Key (CEK) A symmetric key for the AEAD algorithm Content Encryption Key (CEK) A symmetric key for the AEAD algorithm
used to encrypt the Plaintext for the recipient to produce the used to encrypt the Plaintext for the recipient to produce the
Ciphertext and the Authentication Tag. Ciphertext and the Authentication Tag.
JSON Text Object A UTF-8 [RFC3629] encoded text string representing
a JSON object; the syntax of JSON objects is defined in Section
2.2 of [RFC4627].
JWE Header A JSON Text Object (or JSON Text Objects, when using the JWE Header A JSON Text Object (or JSON Text Objects, when using the
JWE JSON Serialization) that describes the encryption operations JWE JSON Serialization) that describes the encryption operations
applied to create the JWE Encrypted Key, the JWE Ciphertext, and applied to create the JWE Encrypted Key, the JWE Ciphertext, and
the JWE Authentication Tag. The members of the JWE Header the JWE Authentication Tag. The members of the JWE Header
object(s) are Header Parameters. object(s) are Header Parameters.
JWE Encrypted Key The result of encrypting the Content Encryption JWE Encrypted Key The result of encrypting the Content Encryption
Key (CEK) with the intended recipient's key using the specified Key (CEK) with the intended recipient's key using the specified
algorithm. Note that for some algorithms, the JWE Encrypted Key algorithm. Note that for some algorithms, the JWE Encrypted Key
value is specified as being the empty octet sequence. value is specified as being the empty octet sequence.
skipping to change at page 7, line 12 skipping to change at page 6, line 28
JWE Authentication Tag A sequence of octets containing the JWE Authentication Tag A sequence of octets containing the
Authentication Tag for a JWE. Authentication Tag for a JWE.
JWE Protected Header A JSON Text Object that contains the portion of JWE Protected Header A JSON Text Object that contains the portion of
the JWE Header that is integrity protected. For the JWE Compact the JWE Header that is integrity protected. For the JWE Compact
Serialization, this comprises the entire JWE Header. For the JWE Serialization, this comprises the entire JWE Header. For the JWE
JSON Serialization, this is one component of the JWE Header. JSON Serialization, this is one component of the JWE Header.
Header Parameter A name/value pair that is member of the JWE Header. Header Parameter A name/value pair that is member of the JWE Header.
Header Parameter Name The name of a member of the JWE Header. JWE Compact Serialization A representation of the JWE as the string
BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE
Header Parameter Value The value of a member of the JWE Header. Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) ||
'.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Base64url Encoding Base64 encoding using the URL- and filename-safe Authentication Tag). This representation is compact and URL-safe.
character set defined in Section 5 of RFC 4648 [RFC4648], with all
trailing '=' characters omitted (as permitted by Section 3.2).
(See Appendix C of [JWS] for notes on implementing base64url
encoding without padding.)
Encoded JWE Header Base64url encoding of the JWE Protected Header.
Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted
Key.
Encoded JWE Initialization Vector Base64url encoding of the JWE
Initialization Vector.
Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext.
Encoded JWE Authentication Tag Base64url encoding of the JWE
Authentication Tag.
JWE Compact Serialization A representation of the JWE as the
concatenation of the Encoded JWE Header, the Encoded JWE Encrypted
Key, the Encoded JWE Initialization Vector, the Encoded JWE
Ciphertext, and the Encoded JWE Authentication Tag in that order,
with the five strings being separated by four period ('.')
characters. This representation is compact and URL-safe.
JWE JSON Serialization A representation of the JWE as a JSON JWE JSON Serialization A representation of the JWE as a JSON
structure containing JWE Header, Encoded JWE Encrypted Key, structure. Unlike the JWE Compact Serialization, the JWE JSON
Encoded JWE Initialization Vector, Encoded JWE Ciphertext, and Serialization enables the same content to be encrypted to multiple
Encoded JWE Authentication Tag values. Unlike the JWE Compact parties. This representation is neither compact nor URL-safe.
Serialization, the JWE JSON Serialization enables the same content
to be encrypted to multiple parties. This representation is
neither compact nor URL-safe.
Collision Resistant Name A name in a namespace that enables names to
be allocated in a manner such that they are highly unlikely to
collide with other names. Examples of collision resistant
namespaces include: Domain Names, Object Identifiers (OIDs) as
defined in the ITU-T X.660 and X.670 Recommendation series, and
Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an
administratively delegated namespace, the definer of a name needs
to take reasonable precautions to ensure they are in control of
the portion of the namespace they use to define the name.
StringOrURI A JSON string value, with the additional requirement
that while arbitrary string values MAY be used, any value
containing a ":" character MUST be a URI [RFC3986]. StringOrURI
values are compared as case-sensitive strings with no
transformations or canonicalizations applied.
Key Management Mode A method of determining the Content Encryption Key Management Mode A method of determining the Content Encryption
Key (CEK) value to use. Each algorithm used for determining the Key (CEK) value to use. Each algorithm used for determining the
CEK value uses a specific Key Management Mode. Key Management CEK value uses a specific Key Management Mode. Key Management
Modes employed by this specification are Key Encryption, Key Modes employed by this specification are Key Encryption, Key
Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping,
and Direct Encryption. and Direct Encryption.
Key Encryption A Key Management Mode in which the Content Encryption Key Encryption A Key Management Mode in which the Content Encryption
Key (CEK) value is encrypted to the intended recipient using an Key (CEK) value is encrypted to the intended recipient using an
skipping to change at page 9, line 8 skipping to change at page 7, line 25
encrypt the Content Encryption Key (CEK) value to the intended encrypt the Content Encryption Key (CEK) value to the intended
recipient using a symmetric key wrapping algorithm. recipient using a symmetric key wrapping algorithm.
Direct Encryption A Key Management Mode in which the Content Direct Encryption A Key Management Mode in which the Content
Encryption Key (CEK) value used is the secret symmetric key value Encryption Key (CEK) value used is the secret symmetric key value
shared between the parties. shared between the parties.
3. JSON Web Encryption (JWE) Overview 3. JSON Web Encryption (JWE) Overview
JWE represents encrypted content using JSON data structures and JWE represents encrypted content using JSON data structures and
base64url encoding. Five values are represented in a JWE: the JWE base64url encoding. A JWE represents these logical values:
Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE
Ciphertext, and the JWE Authentication Tag. In the Compact JWE Header JSON object containing the parameters describing the
Serialization, the five values are base64url-encoded for cryptographic operations and parameters employed. The JWE Header
transmission, and represented as the concatenation of the encoded members are the union of the members of the JWE Protected Header,
strings in that order, with the five strings being separated by four the JWE Shared Unprotected Header, and the JWE Per-Recipient
period ('.') characters. A JSON Serialization for this information Unprotected Header, as described below.
is also defined in Section 7.2.
JWE Encrypted Key Encrypted Content Encryption Key (CEK) value.
JWE Initialization Vector Initialization Vector value used when
encrypting the plaintext.
JWE Ciphertext Ciphertext value resulting from authenticated
encryption of the plaintext.
JWE Authentication Tag Authentication Tag value resulting from
authenticated encryption of the plaintext with additional
associated data.
JWE AAD Additional value to be integrity protected by the
authenticated encryption operation.
The JWE Header represents the combination of these logical values:
JWE Protected Header JSON object containing some of the parameters
describing the cryptographic operations and parameters employed.
These parameters apply to all recipients of the JWE. This value
is integrity protected in the digital signature or MAC calculation
of the JWE Signature.
JWE Shared Unprotected Header JSON object containing some of the
parameters describing the cryptographic operations and parameters
employed. These parameters apply to all recipients of the JWE.
This value is not integrity protected in the authenticated
encryption operation.
JWE Per-Recipient Unprotected Header JSON object containing some of
the parameters describing the cryptographic operations and
parameters employed. These parameters apply to a single recipient
of the JWE. This value is not integrity protected in the
authenticated encryption operation.
This document defines two serializations for JWE objects: a compact,
URL-safe serialization called the JWE Compact Serialization and a
JSON serialization called the JWE JSON Serialization. In both
serializations, the JWE Protected Header, JWE Encrypted Key, JWE
Initialization Vector, JWE Ciphertext, and JWE Authentication Tag are
base64url encoded for transmission, since JSON lacks a way to
directly represent octet sequences. When present, the JWE AAD is
also base64url encoded for transmission.
In the JWE Compact Serialization, no JWE Shared Unprotected Header or
JWE Per-Recipient Unprotected Header are used. In this case, the JWE
Header and the JWE Protected Header are the same.
In the JWE Compact Serialization, a JWE object is represented as the
combination of these five string values,
BASE64URL(UTF8(JWE Protected Header)),
BASE64URL(JWE Encrypted Key),
BASE64URL(JWE Initialization Vector),
BASE64URL(JWE Ciphertext), and
BASE64URL(JWE Authentication Tag),
concatenated in that order, with the five strings being separated by
four period ('.') characters.
In the JWE JSON Serialization, one or more of the JWE Protected
Header, JWE Shared Unprotected Header, and JWE Per-Recipient
Unprotected Header MUST be present. In this case, the members of the
JWE Header are the combination of the members of the JWE Protected
Header, JWE Shared Unprotected Header, and JWE Per-Recipient
Unprotected Header values that are present.
In the JWE JSON Serialization, a JWE object is represented as the
combination of these eight values,
BASE64URL(UTF8(JWE Protected Header)),
JWE Shared Unprotected Header,
JWE Per-Recipient Unprotected Header,
BASE64URL(JWE Encrypted Key),
BASE64URL(JWE Initialization Vector),
BASE64URL(JWE Ciphertext),
BASE64URL(JWE Authentication Tag), and
BASE64URL(JWE AAD),
with the six base64url encoding result strings and the two
unprotected JSON object values being represented as members within a
JSON object. The inclusion of some of these values is OPTIONAL. The
JWE JSON Serialization can also encrypt the plaintext to multiple
recipients. See Section 7.2 for more information about the JWE JSON
Serialization.
JWE utilizes authenticated encryption to ensure the confidentiality JWE utilizes authenticated encryption to ensure the confidentiality
and integrity of the Plaintext and the integrity of the JWE Protected and integrity of the Plaintext and the integrity of the JWE Protected
Header. Header and the JWE AAD.
3.1. Example JWE 3.1. Example JWE
This example encrypts the plaintext "The true sign of intelligence is This example encrypts the plaintext "The true sign of intelligence is
not knowledge but imagination." to the recipient using RSAES OAEP for not knowledge but imagination." to the recipient using RSAES OAEP for
key encryption and AES GCM for content encryption. key encryption and AES GCM for content encryption.
The following example JWE Header declares that: The following example JWE Protected Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES OAEP algorithm to produce the JWE Encrypted Key and RSAES OAEP algorithm to produce the JWE Encrypted Key and
o the Plaintext is encrypted using the AES GCM algorithm with a 256 o the Plaintext is encrypted using the AES GCM algorithm with a 256
bit key to produce the Ciphertext. bit key to produce the Ciphertext.
{"alg":"RSA-OAEP","enc":"A256GCM"} {"alg":"RSA-OAEP","enc":"A256GCM"}
Base64url encoding the octets of the UTF-8 representation of the JWE Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
Header yields this Encoded JWE Header value: Header)) gives this value:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
The remaining steps to finish creating this JWE are: The remaining steps to finish creating this JWE are:
o Generate a random Content Encryption Key (CEK). o Generate a random Content Encryption Key (CEK).
o Encrypt the CEK with the recipient's public key using the RSAES o Encrypt the CEK with the recipient's public key using the RSAES
OAEP algorithm to produce the JWE Encrypted Key. OAEP algorithm to produce the JWE Encrypted Key.
o Base64url encode the JWE Encrypted Key to produce the Encoded JWE o Base64url encode the JWE Encrypted Key.
Encrypted Key.
o Generate a random JWE Initialization Vector. o Generate a random JWE Initialization Vector.
o Base64url encode the JWE Initialization Vector to produce the o Base64url encode the JWE Initialization Vector.
Encoded JWE Initialization Vector.
o Let the Additional Authenticated Data encryption parameter be the o Let the Additional Authenticated Data encryption parameter be
octets of the ASCII representation of the Encoded JWE Header ASCII(BASE64URL(UTF8(JWE Protected Header))).
value.
o Encrypt the Plaintext with AES GCM using the CEK as the encryption o Encrypt the Plaintext with AES GCM using the CEK as the encryption
key, the JWE Initialization Vector, and the Additional key, the JWE Initialization Vector, and the Additional
Authenticated Data value, requesting a 128 bit Authentication Tag Authenticated Data value, requesting a 128 bit Authentication Tag
output. output.
o Base64url encode the Ciphertext to create the Encoded JWE o Base64url encode the Ciphertext.
Ciphertext.
o Base64url encode the Authentication Tag to create the Encoded JWE o Base64url encode the Authentication Tag.
Authentication Tag.
o Assemble the final representation: The Compact Serialization of o Assemble the final representation: The Compact Serialization of
this result is the concatenation of the Encoded JWE Header, the this result is the string BASE64URL(UTF8(JWE Protected Header)) ||
Encoded JWE Encrypted Key, the Encoded JWE Initialization Vector, '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE
the Encoded JWE Ciphertext, and the Encoded JWE Authentication Tag Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.'
in that order, with the five strings being separated by four || BASE64URL(JWE Authentication Tag).
period ('.') characters.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
skipping to change at page 11, line 9 skipping to change at page 11, line 9
SdiwkIr3ajwQzaBtQD_A. SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ XFBoMYUZodetZdvTiFvSkQ
See Appendix A.1 for the complete details of computing this JWE. See See Appendix A.1 for the complete details of computing this JWE. See
Appendix A for additional examples. Appendix A for additional examples.
4. JWE Header 4. JWE Header
The members of the JSON object(s) representing the JWE Header The members of the JSON object(s) representing the JWE Header
describe the encryption applied to the Plaintext and optionally describe the encryption applied to the Plaintext and optionally
additional properties of the JWE. The Header Parameter Names within additional properties of the JWE. The Header Parameter names within
the JWE Header MUST be unique; recipients MUST either reject JWEs the JWE Header MUST be unique; recipients MUST either reject JWEs
with duplicate Header Parameter Names or use a JSON parser that with duplicate Header Parameter names or use a JSON parser that
returns only the lexically last duplicate member name, as specified returns only the lexically last duplicate member name, as specified
in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
Implementations are required to understand the specific header Implementations are required to understand the specific Header
parameters defined by this specification that are designated as "MUST Parameters defined by this specification that are designated as "MUST
be understood" and process them in the manner defined in this be understood" and process them in the manner defined in this
specification. All other header parameters defined by this specification. All other Header Parameters defined by this
specification that are not so designated MUST be ignored when not specification that are not so designated MUST be ignored when not
understood. Unless listed as a critical header parameter, per understood. Unless listed as a critical Header Parameter, per
Section 4.1.12, all header parameters not defined by this Section 4.1.12, all Header Parameters not defined by this
specification MUST be ignored when not understood. specification MUST be ignored when not understood.
There are three classes of Header Parameter Names: Registered Header There are three classes of Header Parameter names: Registered Header
Parameter Names, Public Header Parameter Names, and Private Header Parameter names, Public Header Parameter names, and Private Header
Parameter Names. Parameter names.
4.1. Registered Header Parameter Names 4.1. Registered Header Parameter Names
The following Header Parameter Names are registered in the IANA JSON The following Header Parameter names are registered in the IANA JSON
Web Signature and Encryption Header Parameters registry defined in Web Signature and Encryption Header Parameters registry defined in
[JWS], with meanings as defined below. [JWS], with meanings as defined below.
As indicated by the common registry, JWSs and JWEs share a common As indicated by the common registry, JWSs and JWEs share a common
header parameter space; when a parameter is used by both Header Parameter space; when a parameter is used by both
specifications, its usage must be compatible between the specifications, its usage must be compatible between the
specifications. specifications.
4.1.1. "alg" (Algorithm) Header Parameter 4.1.1. "alg" (Algorithm) Header Parameter
The "alg" (algorithm) header parameter identifies the cryptographic This parameter has the same meaning, syntax, and processing rules as
algorithm used to encrypt or determine the value of the Content the "alg" Header Parameter defined in Section 4.1.1 of [JWS], except
Encryption Key (CEK). The encrypted content is not usable if the that the Header Parameter identifies the cryptographic algorithm used
"alg" value does not represent a supported algorithm, or if the to encrypt or determine the value of the Content Encryption Key
recipient does not have a key that can be used with that algorithm. (CEK). The encrypted content is not usable if the "alg" value does
"alg" values SHOULD either be registered in the IANA JSON Web not represent a supported algorithm, or if the recipient does not
Signature and Encryption Algorithms registry defined in [JWA] or be a have a key that can be used with that algorithm.
value that contains a Collision Resistant Name. The "alg" value is a
case sensitive string containing a StringOrURI value. Use of this
header parameter is REQUIRED. This header parameter MUST be
understood and processed by implementations.
A list of defined "alg" values can be found in the IANA JSON Web A list of defined "alg" values for this use can be found in the IANA
Signature and Encryption Algorithms registry defined in [JWA]; the JSON Web Signature and Encryption Algorithms registry defined in
initial contents of this registry are the values defined in Section [JWA]; the initial contents of this registry are the values defined
4.1 of the JSON Web Algorithms (JWA) [JWA] specification. in Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification.
4.1.2. "enc" (Encryption Method) Header Parameter 4.1.2. "enc" (Encryption Method) Header Parameter
The "enc" (encryption method) header parameter identifies the content The "enc" (encryption method) Header Parameter identifies the content
encryption algorithm used to encrypt the Plaintext to produce the encryption algorithm used to encrypt the Plaintext to produce the
Ciphertext. This algorithm MUST be an AEAD algorithm with a Ciphertext. This algorithm MUST be an AEAD algorithm with a
specified key length. The recipient MUST reject the JWE if the "enc" specified key length. The recipient MUST reject the JWE if the "enc"
value does not represent a supported algorithm. "enc" values SHOULD value does not represent a supported algorithm. "enc" values SHOULD
either be registered in the IANA JSON Web Signature and Encryption either be registered in the IANA JSON Web Signature and Encryption
Algorithms registry defined in [JWA] or be a value that contains a Algorithms registry defined in [JWA] or be a value that contains a
Collision Resistant Name. The "enc" value is a case sensitive string Collision Resistant Name. The "enc" value is a case sensitive string
containing a StringOrURI value. Use of this header parameter is containing a StringOrURI value. Use of this Header Parameter is
REQUIRED. This header parameter MUST be understood and processed by REQUIRED. This Header Parameter MUST be understood and processed by
implementations. implementations.
A list of defined "enc" values can be found in the IANA JSON Web A list of defined "enc" values for this use can be found in the IANA
Signature and Encryption Algorithms registry defined in [JWA]; the JSON Web Signature and Encryption Algorithms registry defined in
initial contents of this registry are the values defined in Section [JWA]; the initial contents of this registry are the values defined
4.2 of the JSON Web Algorithms (JWA) [JWA] specification. in Section 4.2 of the JSON Web Algorithms (JWA) [JWA] specification.
4.1.3. "zip" (Compression Algorithm) Header Parameter 4.1.3. "zip" (Compression Algorithm) Header Parameter
The "zip" (compression algorithm) applied to the Plaintext before The "zip" (compression algorithm) applied to the Plaintext before
encryption, if any. The "zip" value defined by this specification encryption, if any. The "zip" value defined by this specification
is: is:
o "DEF" - Compression with the DEFLATE [RFC1951] algorithm o "DEF" - Compression with the DEFLATE [RFC1951] algorithm
Other values MAY be used. Compression algorithm values can be Other values MAY be used. Compression algorithm values can be
registered in the IANA JSON Web Encryption Compression Algorithm registered in the IANA JSON Web Encryption Compression Algorithm
registry defined in [JWA]. The "zip" value is a case sensitive registry defined in [JWA]. The "zip" value is a case sensitive
string. If no "zip" parameter is present, no compression is applied string. If no "zip" parameter is present, no compression is applied
to the Plaintext before encryption. This header parameter MUST be to the Plaintext before encryption. This Header Parameter MUST be
integrity protected, and therefore MUST occur only within the JWE integrity protected, and therefore MUST occur only within the JWE
Protected Header, when used. Use of this header parameter is Protected Header, when used. Use of this Header Parameter is
OPTIONAL. This header parameter MUST be understood and processed by OPTIONAL. This Header Parameter MUST be understood and processed by
implementations. implementations.
4.1.4. "jku" (JWK Set URL) Header Parameter 4.1.4. "jku" (JWK Set URL) Header Parameter
The "jku" (JWK Set URL) header parameter is a URI [RFC3986] that This parameter has the same meaning, syntax, and processing rules as
refers to a resource for a set of JSON-encoded public keys, one of the "jku" Header Parameter defined in Section 4.1.2 of [JWS], except
which is the key to which the JWE was encrypted; this can be used to that the JWK Set resource contains the public key to which the JWE
determine the private key needed to decrypt the JWE. The keys MUST was encrypted; this can be used to determine the private key needed
be encoded as a JSON Web Key Set (JWK Set) [JWK]. The protocol used to decrypt the JWE.
to acquire the resource MUST provide integrity protection; an HTTP
GET request to retrieve the JWK Set MUST use TLS [RFC2818] [RFC5246];
the identity of the server MUST be validated, as per Section 3.1 of
HTTP Over TLS [RFC2818]. Use of this header parameter is OPTIONAL.
4.1.5. "jwk" (JSON Web Key) Header Parameter 4.1.5. "jwk" (JSON Web Key) Header Parameter
The "jwk" (JSON Web Key) header parameter is the public key to which This parameter has the same meaning, syntax, and processing rules as
the JWE was encrypted; this can be used to determine the private key the "jwk" Header Parameter defined in Section 4.1.3 of [JWS], except
needed to decrypt the JWE. This key is represented as a JSON Web Key that the key is the public key to which the JWE was encrypted; this
[JWK]. Use of this header parameter is OPTIONAL. can be used to determine the private key needed to decrypt the JWE.
4.1.6. "x5u" (X.509 URL) Header Parameter 4.1.6. "x5u" (X.509 URL) Header Parameter
The "x5u" (X.509 URL) header parameter is a URI [RFC3986] that refers This parameter has the same meaning, syntax, and processing rules as
to a resource for the X.509 public key certificate or certificate the "x5u" Header Parameter defined in Section 4.1.4 of [JWS], except
chain [RFC5280] containing the key to which the JWE was encrypted; that the X.509 public key certificate or certificate chain [RFC5280]
this can be used to determine the private key needed to decrypt the contains the public key to which the JWE was encrypted; this can be
JWE. The identified resource MUST provide a representation of the used to determine the private key needed to decrypt the JWE.
certificate or certificate chain that conforms to RFC 5280 [RFC5280]
in PEM encoded form [RFC1421]. The certificate containing the public
key to which the JWE was encrypted MUST be the first certificate.
This MAY be followed by additional certificates, with each subsequent
certificate being the one used to certify the previous one. The
protocol used to acquire the resource MUST provide integrity
protection; an HTTP GET request to retrieve the certificate MUST use
TLS [RFC2818] [RFC5246]; the identity of the server MUST be
validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of
this header parameter is OPTIONAL.
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter 4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter
The "x5t" (X.509 Certificate SHA-1 Thumbprint) header parameter is a This parameter has the same meaning, syntax, and processing rules as
base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER the "x5t" Header Parameter defined in Section 4.1.5 of [JWS], except
encoding of the X.509 certificate [RFC5280] containing the key to that certificate referenced by the thumbprint contains the public key
which the JWE was encrypted; this can be used to determine the to which the JWE was encrypted; this can be used to determine the
private key needed to decrypt the JWE. Use of this header parameter private key needed to decrypt the JWE.
is OPTIONAL.
If, in the future, certificate thumbprints need to be computed using
hash functions other than SHA-1, it is suggested that additional
related header parameters be defined for that purpose. For example,
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) header parameter could be defined by registering it in
the IANA JSON Web Signature and Encryption Header Parameters registry
defined in [JWS].
4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter 4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter
The "x5c" (X.509 Certificate Chain) header parameter contains the This parameter has the same meaning, syntax, and processing rules as
X.509 public key certificate or certificate chain [RFC5280] the "x5c" Header Parameter defined in Section 4.1.6 of [JWS], except
containing the key to which the JWE was encrypted; this can be used that the X.509 public key certificate or certificate chain [RFC5280]
to determine the private key needed to decrypt the JWE. The contains the public key to which the JWE was encrypted; this can be
certificate or certificate chain is represented as a JSON array of used to determine the private key needed to decrypt the JWE.
certificate value strings. Each string in the array is a base64
encoded ([RFC4648] Section 4 -- not base64url encoded) DER
[ITU.X690.1994] PKIX certificate value. The certificate containing
the public key to which the JWE was encrypted MUST be the first
certificate. This MAY be followed by additional certificates, with
each subsequent certificate being the one used to certify the
previous one. Use of this header parameter is OPTIONAL.
See Appendix B of [JWS] for an example "x5c" value. See Appendix B of [JWS] for an example "x5c" value.
4.1.9. "kid" (Key ID) Header Parameter 4.1.9. "kid" (Key ID) Header Parameter
The "kid" (key ID) header parameter is a hint indicating which key to This parameter has the same meaning, syntax, and processing rules as
which the JWE was encrypted; this can be used to determine the the "kid" Header Parameter defined in Section 4.1.7 of [JWS], except
private key needed to decrypt the JWE. This parameter allows that the key hint references the public key to which the JWE was
originators to explicitly signal a change of key to recipients. encrypted; this can be used to determine the private key needed to
Should the recipient be unable to locate a key corresponding to the decrypt the JWE. This parameter allows originators to explicitly
"kid" value, they SHOULD treat that condition as an error. The signal a change of key to JWE recipients.
interpretation of the "kid" value is unspecified. Its value MUST be
a string. Use of this header parameter is OPTIONAL.
When used with a JWK, the "kid" value can be used to match a JWK
"kid" parameter value.
4.1.10. "typ" (Type) Header Parameter 4.1.10. "typ" (Type) Header Parameter
The "typ" (type) header parameter is used to declare the type of this This parameter has the same meaning, syntax, and processing rules as
complete JWE object in an application-specific manner in contexts the "typ" Header Parameter defined in Section 4.1.8 of [JWS], except
where this is useful to the application. This parameter has no that the type is of this complete JWE object.
effect upon the JWE processing. The type value "JOSE" can be used by
applications to indicate that this object is a JWS or JWE using the
JWS Compact Serialization or the JWE Compact Serialization. The type
value "JOSE+JSON" can be used by applications to indicate that this
object is a JWS or JWE using the JWS JSON Serialization or the JWE
JSON Serialization. Other type values can also be used by
applications. The "typ" value is a case sensitive string. Use of
this header parameter is OPTIONAL.
MIME Media Type [RFC2046] values MAY be used as "typ" values. When
MIME Media Type values are used, it is RECOMMENDED that they be
spelled using the exact character case used in the MIME Media Types
registry [IANA.MediaTypes], since this field is case sensitive,
whereas MIME Media Type values are case insensitive.
"typ" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Type Values registry defined in [JWS] or be
a value that contains a Collision Resistant Name.
4.1.11. "cty" (Content Type) Header Parameter 4.1.11. "cty" (Content Type) Header Parameter
The "cty" (content type) header parameter is used to declare the type This parameter has the same meaning, syntax, and processing rules as
of the encrypted content (the Plaintext) in an application-specific the "cty" Header Parameter defined in Section 4.1.9 of [JWS], except
manner in contexts where this is useful to the application. This that the type is of the secured content (the payload).
parameter has no effect upon the JWE processing. The "cty" value is
a case sensitive string. Use of this header parameter is OPTIONAL.
The values used for the "cty" header parameter come from the same
value space as the "typ" header parameter, with the same rules
applying.
4.1.12. "crit" (Critical) Header Parameter 4.1.12. "crit" (Critical) Header Parameter
The "crit" (critical) header parameter indicates that extensions to This parameter has the same meaning, syntax, and processing rules as
[[ this specification ]] are being used that MUST be understood and the "typ" Header Parameter defined in Section 4.1.8 of [JWS], except
processed. Its value is an array listing the header parameter names that the Header Parameters referenced are the JWE Header Parameters.
defined by those extensions that are used in the JWE Header. If any
of the listed extension header parameters are not understood and
supported by the receiver, it MUST reject the JWE. Senders MUST NOT
include header parameter names defined by [[ this specification ]] or
by [JWA] for use with JWE, duplicate names, or names that do not
occur as header parameter names within the JWE Header in the "crit"
list. Senders MUST not use the empty list "[]" as the "crit" value.
Recipients MAY reject the JWE if the critical list contains any
header parameter names defined by [[ this specification ]] or by
[JWA] for use with JWE, or any other constraints on its use are
violated. This header parameter MUST be integrity protected, and
therefore MUST occur only with the JWE Protected Header, when used.
Use of this header parameter is OPTIONAL. This header parameter MUST
be understood and processed by implementations.
An example use, along with a hypothetical "exp" (expiration-time)
field is:
{"alg":"RSA-OAEP",
"enc":"A256GCM",
"crit":["exp"],
"exp":1363284000
}
4.2. Public Header Parameter Names 4.2. Public Header Parameter Names
Additional Header Parameter Names can be defined by those using JWEs. Additional Header Parameter names can be defined by those using JWEs.
However, in order to prevent collisions, any new Header Parameter However, in order to prevent collisions, any new Header Parameter
Name SHOULD either be registered in the IANA JSON Web Signature and name SHOULD either be registered in the IANA JSON Web Signature and
Encryption Header Parameters registry defined in [JWS] or be a Public Encryption Header Parameters registry defined in [JWS] or be a Public
Name: a value that contains a Collision Resistant Name. In each Name: a value that contains a Collision Resistant Name. In each
case, the definer of the name or value needs to take reasonable case, the definer of the name or value needs to take reasonable
precautions to make sure they are in control of the part of the precautions to make sure they are in control of the part of the
namespace they use to define the Header Parameter Name. namespace they use to define the Header Parameter name.
New header parameters should be introduced sparingly, as they can New Header Parameters should be introduced sparingly, as they can
result in non-interoperable JWEs. result in non-interoperable JWEs.
4.3. Private Header Parameter Names 4.3. Private Header Parameter Names
A producer and consumer of a JWE may agree to use Header Parameter A producer and consumer of a JWE may agree to use Header Parameter
Names that are Private Names: names that are not Registered Header names that are Private Names: names that are not Registered Header
Parameter Names Section 4.1 or Public Header Parameter Names Parameter names Section 4.1 or Public Header Parameter names
Section 4.2. Unlike Public Header Parameter Names, Private Header Section 4.2. Unlike Public Header Parameter names, Private Header
Parameter Names are subject to collision and should be used with Parameter names are subject to collision and should be used with
caution. caution.
5. Producing and Consuming JWEs 5. Producing and Consuming JWEs
5.1. Message Encryption 5.1. Message Encryption
The message encryption process is as follows. The order of the steps The message encryption process is as follows. The order of the steps
is not significant in cases where there are no dependencies between is not significant in cases where there are no dependencies between
the inputs and outputs of the steps. the inputs and outputs of the steps.
1. Determine the Key Management Mode employed by the algorithm used 1. Determine the Key Management Mode employed by the algorithm used
to determine the Content Encryption Key (CEK) value. (This is to determine the Content Encryption Key (CEK) value. (This is
the algorithm recorded in the "alg" (algorithm) header parameter the algorithm recorded in the "alg" (algorithm) Header Parameter
of the resulting JWE.) of the resulting JWE.)
2. When Key Wrapping, Key Encryption, or Key Agreement with Key 2. When Key Wrapping, Key Encryption, or Key Agreement with Key
Wrapping are employed, generate a random Content Encryption Key Wrapping are employed, generate a random Content Encryption Key
(CEK) value. See RFC 4086 [RFC4086] for considerations on (CEK) value. See RFC 4086 [RFC4086] for considerations on
generating random values. The CEK MUST have a length equal to generating random values. The CEK MUST have a length equal to
that required for the content encryption algorithm. that required for the content encryption algorithm.
3. When Direct Key Agreement or Key Agreement with Key Wrapping are 3. When Direct Key Agreement or Key Agreement with Key Wrapping are
employed, use the key agreement algorithm to compute the value employed, use the key agreement algorithm to compute the value
skipping to change at page 17, line 16 skipping to change at page 15, line 28
4. When Key Wrapping, Key Encryption, or Key Agreement with Key 4. When Key Wrapping, Key Encryption, or Key Agreement with Key
Wrapping are employed, encrypt the CEK to the recipient and let Wrapping are employed, encrypt the CEK to the recipient and let
the result be the JWE Encrypted Key. the result be the JWE Encrypted Key.
5. Otherwise, when Direct Key Agreement or Direct Encryption are 5. Otherwise, when Direct Key Agreement or Direct Encryption are
employed, let the JWE Encrypted Key be the empty octet sequence. employed, let the JWE Encrypted Key be the empty octet sequence.
6. When Direct Encryption is employed, let the Content Encryption 6. When Direct Encryption is employed, let the Content Encryption
Key (CEK) be the shared symmetric key. Key (CEK) be the shared symmetric key.
7. Base64url encode the JWE Encrypted Key to create the Encoded JWE 7. Compute the encoded key value BASE64URL(JWE Encrypted Key).
Encrypted Key.
8. If the JWE JSON Serialization is being used, repeat this process 8. If the JWE JSON Serialization is being used, repeat this process
for each recipient. for each recipient.
9. Generate a random JWE Initialization Vector of the correct size 9. Generate a random JWE Initialization Vector of the correct size
for the content encryption algorithm (if required for the for the content encryption algorithm (if required for the
algorithm); otherwise, let the JWE Initialization Vector be the algorithm); otherwise, let the JWE Initialization Vector be the
empty octet sequence. empty octet sequence.
10. Base64url encode the JWE Initialization Vector to create the 10. Compute the encoded initialization vector value BASE64URL(JWE
Encoded JWE Initialization Vector. Initialization Vector).
11. Compress the Plaintext if a "zip" parameter was included. 11. Compress the Plaintext if a "zip" parameter was included.
12. Serialize the (compressed) Plaintext into an octet sequence M. 12. Serialize the (compressed) Plaintext into an octet sequence M.
13. Create a JWE Header containing the encryption parameters used. 13. Create a JWE Header containing the encryption parameters used.
Note that white space is explicitly allowed in the Note that white space is explicitly allowed in the
representation and no canonicalization need be performed before representation and no canonicalization need be performed before
encoding. encoding.
14. Base64url encode the octets of the UTF-8 representation of the 14. Compute the encoded header value BASE64URL(UTF8(JWE Protected
JWE Protected Header to create the Encoded JWE Header. If the Header)). If the JWE Protected Header is not present (which can
JWE Protected Header is not present (which can only happen when only happen when using the JWE JSON Serialization and no
using the JWE JSON Serialization and no "protected" member is "protected" member is present), let this value be the empty
present), let the Encoded JWE Header be the empty string. string.
15. Let the Additional Authenticated Data encryption parameter be 15. Let the Additional Authenticated Data encryption parameter be
the octets of the ASCII representation of the Encoded JWE Header ASCII(BASE64URL(UTF8(JWE Protected Header))). However if a JWE
value. However if a top-level "aad" member is present when AAD value is present when using the JWE JSON Serialization,
using the JWE JSON Serialization, instead let the Additional instead let the Additional Authenticated Data encryption
Authenticated Data encryption parameter be the octets of the parameter be ASCII(BASE64URL(UTF8(JWE Protected Header)) || '.'
ASCII representation of the concatenation of the Encoded JWE || BASE64URL(JWE AAD)).
Header value, a period ('.') character, and the "aad" field
value.
16. Encrypt M using the CEK, the JWE Initialization Vector, and the 16. Encrypt M using the CEK, the JWE Initialization Vector, and the
Additional Authenticated Data value using the specified content Additional Authenticated Data value using the specified content
encryption algorithm to create the JWE Ciphertext value and the encryption algorithm to create the JWE Ciphertext value and the
JWE Authentication Tag (which is the Authentication Tag output JWE Authentication Tag (which is the Authentication Tag output
from the encryption operation). from the encryption operation).
17. Base64url encode the JWE Ciphertext to create the Encoded JWE 17. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).
Ciphertext.
18. Base64url encode the JWE Authentication Tag to create the 18. Compute the encoded authentication tag value BASE64URL(JWE
Encoded JWE Authentication Tag. Authentication Tag).
19. The five encoded parts are result values used in both the JWE 19. The five encoded values are used in both the JWE Compact
Compact Serialization and the JWE JSON Serialization Serialization and the JWE JSON Serialization representations.
representations.
20. Create the desired serialized output. The JWE Compact 20. If a JWE AAD value is present, compute the encoded AAD value
Serialization of this result is the concatenation of the Encoded BASE64URL(JWE AAD).
JWE Header, the Encoded JWE Encrypted Key, the Encoded JWE
Initialization Vector, the Encoded JWE Ciphertext, and the 21. Create the desired serialized output. The Compact Serialization
Encoded JWE Authentication Tag in that order, with the five of this result is the string BASE64URL(UTF8(JWE Protected
strings being separated by four period ('.') characters. The Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE
Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The
JWE JSON Serialization is described in Section 7.2. JWE JSON Serialization is described in Section 7.2.
5.2. Message Decryption 5.2. Message Decryption
The message decryption process is the reverse of the encryption The message decryption process is the reverse of the encryption
process. The order of the steps is not significant in cases where process. The order of the steps is not significant in cases where
there are no dependencies between the inputs and outputs of the there are no dependencies between the inputs and outputs of the
steps. If any of these steps fails, the encrypted content cannot be steps. If any of these steps fails, the encrypted content cannot be
validated. validated.
It is an application decision which recipients' encrypted content It is an application decision which recipients' encrypted content
must successfully validate for the JWE to be accepted. In some must successfully validate for the JWE to be accepted. In some
cases, encrypted content for all recipients must successfully cases, encrypted content for all recipients must successfully
validate or the JWE will be rejected. In other cases, only the validate or the JWE will be rejected. In other cases, only the
encrypted content for a single recipient needs to be successfully encrypted content for a single recipient needs to be successfully
validated. However, in all cases, the encrypted content for at least validated. However, in all cases, the encrypted content for at least
one recipient MUST successfully validate or the JWE MUST be rejected. one recipient MUST successfully validate or the JWE MUST be rejected.
1. Parse the serialized input to determine the values of the JWE 1. Parse the JWE representation to extract the serialized values
Header, the Encoded JWE Encrypted Key, the Encoded JWE for the components of the JWE -- when using the JWE Compact
Initialization Vector, the Encoded JWE Ciphertext, and the Serialization, the base64url encoded representations of the JWE
Encoded JWE Authentication Tag. When using the JWE Compact Protected Header, the JWE Encrypted Key, the JWE Initialization
Serialization, the Encoded JWE Header, the Encoded JWE Encrypted Vector, the JWE Ciphertext, and the JWE Authentication Tag, and
Key, the Encoded JWE Initialization Vector, the Encoded JWE when using the JWE JSON Serialization, also the base64url
Ciphertext, and the Encoded JWE Authentication Tag are encoded representation of the JWE AAD and the unencoded JWE
represented as text strings in that order, separated by four Shared Unprotected Header and JWE Per-Recipient Unprotected
period ('.') characters. The JWE JSON Serialization is Header values. When using the JWE Compact Serialization, the
described in Section 7.2. JWE Protected Header, the JWE Encrypted Key, the JWE
Initialization Vector, the JWE Ciphertext, and the JWE
Authentication Tag are represented as base64url encoded values
in that order, separated by four period ('.') characters. The
JWE JSON Serialization is described in Section 7.2.
2. The Encoded JWE Header, the Encoded JWE Encrypted Key, the 2. The encoded representations of the JWE Protected Header, the JWE
Encoded JWE Initialization Vector, the Encoded JWE Ciphertext, Encrypted Key, the JWE Initialization Vector, the JWE
and the Encoded JWE Authentication Tag MUST be successfully Ciphertext, the JWE Authentication Tag, and the JWE AAD MUST be
base64url decoded following the restriction that no padding successfully base64url decoded following the restriction that no
characters have been used. padding characters have been used.
3. The resulting JWE Protected Header MUST be a completely valid 3. The resulting UTF8 encoded JWE Protected Header MUST be a
JSON object conforming to RFC 4627 [RFC4627]. completely valid JSON object conforming to RFC 4627 [RFC4627].
4. If using the JWE Compact Serialization, let the JWE Header be 4. If using the JWE Compact Serialization, let the JWE Header be
the JWE Protected Header; otherwise, when using the JWE JSON the JWE Protected Header; otherwise, when using the JWE JSON
Serialization, let the JWE Header be the union of the members of Serialization, let the JWE Header be the union of the members of
the JWE Protected Header, the members of the "unprotected" the JWE Protected Header, the JWE Shared Unprotected Header and
value, and the members of the corresponding "header" value, all the corresponding JWE Per-Recipient Unprotected Header, all of
of which must be completely valid JSON objects. which must be completely valid JSON objects.
5. The resulting JWE Header MUST NOT contain duplicate Header 5. The resulting JWE Header MUST NOT contain duplicate Header
Parameter Names. When using the JWE JSON Serialization, this Parameter names. When using the JWE JSON Serialization, this
restriction includes that the same Header Parameter Name also restriction includes that the same Header Parameter name also
MUST NOT occur in distinct JSON Text Object values that together MUST NOT occur in distinct JSON Text Object values that together
comprise the JWE Header. comprise the JWE Header.
6. The resulting JWE Header MUST be validated to only include 6. The resulting JWE Header MUST be validated to only include
parameters and values whose syntax and semantics are both parameters and values whose syntax and semantics are both
understood and supported or that are specified as being ignored understood and supported or that are specified as being ignored
when not understood. when not understood.
7. Determine the Key Management Mode employed by the algorithm 7. Determine the Key Management Mode employed by the algorithm
specified by the "alg" (algorithm) header parameter. specified by the "alg" (algorithm) Header Parameter.
8. Verify that the JWE uses a key known to the recipient. 8. Verify that the JWE uses a key known to the recipient.
9. When Direct Key Agreement or Key Agreement with Key Wrapping are 9. When Direct Key Agreement or Key Agreement with Key Wrapping are
employed, use the key agreement algorithm to compute the value employed, use the key agreement algorithm to compute the value
of the agreed upon key. When Direct Key Agreement is employed, of the agreed upon key. When Direct Key Agreement is employed,
let the Content Encryption Key (CEK) be the agreed upon key. let the Content Encryption Key (CEK) be the agreed upon key.
When Key Agreement with Key Wrapping is employed, the agreed When Key Agreement with Key Wrapping is employed, the agreed
upon key will be used to decrypt the JWE Encrypted Key. upon key will be used to decrypt the JWE Encrypted Key.
skipping to change at page 20, line 29 skipping to change at page 18, line 42
sequence. sequence.
12. When Direct Encryption is employed, let the Content Encryption 12. When Direct Encryption is employed, let the Content Encryption
Key (CEK) be the shared symmetric key. Key (CEK) be the shared symmetric key.
13. If the JWE JSON Serialization is being used, repeat this process 13. If the JWE JSON Serialization is being used, repeat this process
for each recipient contained in the representation until the CEK for each recipient contained in the representation until the CEK
value has been determined. value has been determined.
14. Let the Additional Authenticated Data encryption parameter be 14. Let the Additional Authenticated Data encryption parameter be
the octets of the ASCII representation of the Encoded JWE Header ASCII(BASE64URL(UTF8(JWE Protected Header))). However if a JWE
value. However if a top-level "aad" member is present when AAD value is present when using the JWE JSON Serialization,
using the JWE JSON Serialization, instead let the Additional instead let the Additional Authenticated Data encryption
Authenticated Data encryption parameter be the octets of the parameter be ASCII(BASE64URL(UTF8(JWE Protected Header)) || '.'
ASCII representation of the concatenation of the Encoded JWE || BASE64URL(JWE AAD)).
Header value, a period ('.') character, and the "aad" field
value.
15. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization 15. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization
Vector, the Additional Authenticated Data value, and the JWE Vector, the Additional Authenticated Data value, and the JWE
Authentication Tag (which is the Authentication Tag input to the Authentication Tag (which is the Authentication Tag input to the
calculation) using the specified content encryption algorithm, calculation) using the specified content encryption algorithm,
returning the decrypted plaintext and verifying the JWE returning the decrypted plaintext and verifying the JWE
Authentication Tag in the manner specified for the algorithm, Authentication Tag in the manner specified for the algorithm,
rejecting the input without emitting any decrypted output if the rejecting the input without emitting any decrypted output if the
JWE Authentication Tag is incorrect. JWE Authentication Tag is incorrect.
16. Uncompress the decrypted plaintext if a "zip" parameter was 16. Uncompress the decrypted plaintext if a "zip" parameter was
included. included.
17. Output the resulting Plaintext. 17. Output the resulting Plaintext.
5.3. String Comparison Rules 5.3. String Comparison Rules
Processing a JWE inevitably requires comparing known strings to The string comparison rules for this specification are the same as
values in JSON objects. For example, in checking what the encryption those defined in Section 5.3 of [JWS].
method is, the Unicode string encoding "enc" will be checked against
the member names in the JWE Header to see if there is a matching
Header Parameter Name.
Comparisons between JSON strings and other Unicode strings MUST be
performed by comparing Unicode code points without normalization as
specified in the String Comparison Rules in Section 5.3 of [JWS].
6. Key Identification 6. Key Identification
It is necessary for the recipient of a JWE to be able to determine The key identification methods for this specification are the same as
the key that was employed for the encryption operation. The key those defined in Section 6 of [JWS], except that the key being
employed can be identified using the Header Parameter methods identified is the public key to which the JWE was encrypted.
described in Section 4.1 or can be identified using methods that are
outside the scope of this specification. Specifically, the Header
Parameters "jku", "jwk", "x5u", "x5t", "x5c", and "kid" can be used
to identify the key used. These header parameters MUST be integrity
protected if the information that they convey is to be utilized in a
trust decision.
The sender SHOULD include sufficient information in the Header
Parameters to identify the key used, unless the application uses
another means or convention to determine the key used. Validation of
the encrypted content fails when the key used cannot be determined.
The means of exchanging any shared symmetric keys used is outside the
scope of this specification.
7. Serializations 7. Serializations
JWE objects use one of two serializations, the JWE Compact JWE objects use one of two serializations, the JWE Compact
Serialization or the JWE JSON Serialization. The JWE Compact Serialization or the JWE JSON Serialization. For general-purpose
Serialization is mandatory to implement. Implementation of the JWE implementations, both the JWE Compact Serialization and JWE JSON
JSON Serialization is OPTIONAL. Serialization support for the single recipient case are mandatory to
implement; support for multiple recipients is OPTIONAL. Special-
purpose implementations are permitted to implement only a single
serialization, if that meets the needs of the targeted use cases.
7.1. JWE Compact Serialization 7.1. JWE Compact Serialization
The JWE Compact Serialization represents encrypted content as a The JWE Compact Serialization represents encrypted content as a
compact URL-safe string. This string is the concatenation of the compact URL-safe string. This string is BASE64URL(UTF8(JWE Protected
Encoded JWE Header, the Encoded JWE Encrypted Key, the Encoded JWE Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' ||
Initialization Vector, the Encoded JWE Ciphertext, and the Encoded BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE
JWE Authentication Tag in that order, with the five strings being Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). Only one
separated by four period ('.') characters. Only one recipient is recipient is supported by the JWE Compact Serialization.
supported by the JWE Compact Serialization.
7.2. JWE JSON Serialization 7.2. JWE JSON Serialization
The JWE JSON Serialization represents encrypted content as a JSON The JWE JSON Serialization represents encrypted content as a JSON
object. Unlike the JWE Compact Serialization, content using the JWE object. Unlike the JWE Compact Serialization, content using the JWE
JSON Serialization can be encrypted to more than one recipient. JSON Serialization can be encrypted to more than one recipient.
The representation is closely related to that used in the JWE Compact The representation is closely related to that used in the JWE Compact
Serialization, with the following differences for the JWE JSON Serialization, with the following differences for the JWE JSON
Serialization: Serialization:
o Values in the JWE JSON Serialization are represented as members of o Values in the JWE JSON Serialization are represented as members of
a JSON object, rather than as base64url encoded strings separated a JSON object, rather than as base64url encoded strings separated
by period ('.') characters. (However binary values and values by period ('.') characters. (However binary values and values
that are integrity protected are still base64url encoded.) that are integrity protected are still base64url encoded.)
o The Encoded JWE Header value, if non-empty, is stored in the o The value BASE64URL(UTF8(JWE Protected Header)), if non-empty, is
"protected" member. stored in the "protected" member.
o The Encoded JWE Initialization Vector value, if non-empty, is o The value BASE64URL(UTF8(JWE Shared Unprotected Header)), if non-
empty, is stored in the "unprotected" member.
o The value BASE64URL(JWE Initialization Vector), if non-empty, is
stored in the "iv" member. stored in the "iv" member.
o The Encoded JWE Ciphertext value is stored in the "ciphertext" o The value BASE64URL(JWE Ciphertext)is stored in the "ciphertext"
member. member.
o The Encoded JWE Authentication Tag value, if non-empty, is stored o The value BASE64URL(JWE Authentication Tag), if non-empty, is
in the "tag" member. stored in the "tag" member.
o The JWE can be encrypted to multiple recipients, rather than just o The JWE can be encrypted to multiple recipients, rather than just
one. A JSON array in the "recipients" member is used to hold one. A JSON array in the "recipients" member is used to hold
values that are specific to a particular recipient, with one array values that are specific to a particular recipient, with one array
element per recipient represented. These array elements are JSON element per recipient represented. These array elements are JSON
objects. objects.
o Each Encoded JWE Encrypted Key value, if non-empty, is stored in o Each value BASE64URL(JWE Encrypted Key), if non-empty, is stored
the "encrypted_key" member of a JSON object that is an element of in the "encrypted_key" member of a JSON object that is an element
the "recipients" array. of the "recipients" array.
o Some header parameter values, such as the "alg" value and o Some Header Parameter values, such as the "alg" value and
parameters used for selecting keys, can also differ for different parameters used for selecting keys, can also differ for different
recipient computations. Per-recipient header parameter values, if recipient computations. JWE Per-Recipient Unprotected Header
present, are stored in the "header" members of the same JSON values, if present, are stored in the "header" members of the same
objects that are elements of the "recipients" array. JSON objects that are elements of the "recipients" array.
o Some header parameters, including the "alg" parameter, can be o Some Header Parameters, including the "alg" parameter, can be
shared among all recipient computations. These header parameters shared among all recipient computations. Header Parameters in the
are stored in either of two top-level member(s) of the JSON JWE Protected Header and JWE Shared Unprotected Header values are
object: the "protected" member and the "unprotected" member. The shared among all recipients.
values of these members, if present, are JSON Text Objects
containing Header Parameters.
o Not all header parameters are integrity protected. The shared o Not all Header Parameters are integrity protected. The shared
header parameters in the "protected" member are integrity Header Parameters in the JWE Protected Header value member are
protected, and are base64url encoded. The per-recipient header integrity protected, and are base64url encoded for transmission.
parameters in the "header" array element members and the shared The per-recipient Header Parameters in the JWE Per-Recipient
header parameters in the "unprotected" member are not integrity Unprotected Header values and the shared Header Parameters in the
protected. These JSON Text Objects containing header parameters JWE Shared Unprotected Header value are not integrity protected.
that are not integrity protected are not base64url encoded. These JSON Text Objects containing Header Parameters that are not
integrity protected are not base64url encoded.
o The header parameter values used when creating or validating per- o The Header Parameter values used when creating or validating per-
recipient Ciphertext and Authentication Tag values are the union recipient Ciphertext and Authentication Tag values are the union
of the three sets of header parameter values that may be present: of the three sets of Header Parameter values that may be present:
(1) the per-recipient values in the "header" member of the (1) the JWE Protected Header values represented in the "protected"
recipient's array element, (2) the shared integrity-protected member, (2) the JWE Shared Unprotected Header values represented
values in the "protected" member, and (3) the shared non- in the "unprotected" member, and (3) the JWE Per-Recipient
integrity-protected values in the "unprotected" member. The union Unprotected Header values represented in the "header" member of
of these sets of header parameters comprises the JWE Header. The the recipient's array element. The union of these sets of Header
header parameter names in the three locations MUST be disjoint. Parameters comprises the JWE Header. The Header Parameter names
in the three locations MUST be disjoint.
o An "aad" (Additional Authenticated Data) member can be included to o A JWE AAD value can be included to supply a base64url encoded
supply a base64url encoded value to be integrity protected but not value to be integrity protected but not encrypted. (Note that
encrypted. (Note that this can also be achieved when using either this can also be achieved when using either serialization by
serialization by including the AAD value as a protected header including the AAD value as a protected Header Parameter value, but
parameter value, but at the cost of the value being double at the cost of the value being double base64url encoded.) If a
base64url encoded.) JWE AAD value is present, the value BASE64URL(JWE AAD)) is stored
in the "aad" member.
o The "recipients" array MUST always be present, even if the array o The "recipients" array MUST always be present, even if the array
elements contain only the empty JSON object "{}" (which can happen elements contain only the empty JSON object "{}" (which can happen
when all header parameter values are shared between all recipients when all Header Parameter values are shared between all recipients
and when no encrypted key is used, such as when doing Direct and when no encrypted key is used, such as when doing Direct
Encryption). Encryption).
The syntax of a JWE using the JWE JSON Serialization is as follows: The syntax of a JWE using the JWE JSON Serialization is as follows:
{"protected":<integrity-protected shared header contents>", {"protected":<integrity-protected shared header contents>",
"unprotected":<non-integrity-protected shared header contents>", "unprotected":<non-integrity-protected shared header contents>",
"recipients":[ "recipients":[
{"header":"<per-recipient unprotected header 1 contents>", {"header":"<per-recipient unprotected header 1 contents>",
"encrypted_key":"<encrypted key 1 contents>"}, "encrypted_key":"<encrypted key 1 contents>"},
skipping to change at page 24, line 27 skipping to change at page 22, line 8
"ciphertext":"<ciphertext contents>", "ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>" "tag":"<authentication tag contents>"
} }
Of these members, only the "ciphertext" member MUST be present. The Of these members, only the "ciphertext" member MUST be present. The
"iv", "tag", and "encrypted_key" members MUST be present when "iv", "tag", and "encrypted_key" members MUST be present when
corresponding JWE Initialization Vector, JWE Authentication Tag, and corresponding JWE Initialization Vector, JWE Authentication Tag, and
JWE Encrypted Key values are non-empty. The "recipients" member MUST JWE Encrypted Key values are non-empty. The "recipients" member MUST
be present when any "header" or "encrypted_key" members are needed be present when any "header" or "encrypted_key" members are needed
for recipients. At least one of the "header", "protected", and for recipients. At least one of the "header", "protected", and
"unprotected" members MUST be present so that "alg" and "enc" header "unprotected" members MUST be present so that "alg" and "enc" Header
parameter values are conveyed for each recipient computation. Parameter values are conveyed for each recipient computation.
The contents of the Encoded JWE Encrypted Key, Encoded JWE The contents of the JWE Encrypted Key, JWE Initialization Vector, JWE
Initialization Vector, Encoded JWE Ciphertext, and Encoded JWE Ciphertext, and JWE Authentication Tag values are exactly as defined
Authentication Tag values are exactly as defined in the rest of this in the rest of this specification. They are interpreted and
specification. They are interpreted and validated in the same validated in the same manner, with each corresponding JWE Encrypted
manner, with each corresponding Encoded JWE Encrypted Key, Encoded Key, JWE Initialization Vector, JWE Ciphertext, JWE Authentication
JWE Initialization Vector, Encoded JWE Ciphertext, Encoded JWE Tag, and set of Header Parameter values being created and validated
Authentication Tag, and set of header parameter values being created together. The JWE Header values used are the union of the Header
and validated together. The JWE Header values used are the union of Parameters in the JWE Protected Header, JWE Shared Unprotected
the header parameters in the "protected", "unprotected", and Header, and corresponding JWE Per-Recipient Unprotected Header
corresponding "header" members, as described earlier. values, as described earlier.
Each JWE Encrypted Key value is computed using the parameters of the Each JWE Encrypted Key value is computed using the parameters of the
corresponding JWE Header value in the same manner as for the JWE corresponding JWE Header value in the same manner as for the JWE
Compact Serialization. This has the desirable property that each Compact Serialization. This has the desirable property that each JWE
Encoded JWE Encrypted Key value in the "recipients" array is Encrypted Key value in the "recipients" array is identical to the
identical to the value that would have been computed for the same value that would have been computed for the same parameter in the JWE
parameter in the JWE Compact Serialization. Likewise, the JWE Compact Serialization. Likewise, the JWE Ciphertext and JWE
Ciphertext and JWE Authentication Tag values match those produced for Authentication Tag values match those produced for the JWE Compact
the JWE Compact Serialization, provided that the Encoded JWE Header Serialization, provided that the JWE Protected Header value (which
value (which represents the integrity-protected header parameter represents the integrity-protected Header Parameter values) matches
values) matches that used in the JWE Compact Serialization. that used in the JWE Compact Serialization.
All recipients use the same JWE Protected Header, JWE Initialization All recipients use the same JWE Protected Header, JWE Initialization
Vector, JWE Ciphertext, and JWE Authentication Tag values, resulting Vector, JWE Ciphertext, and JWE Authentication Tag values, resulting
in potentially significant space savings if the message is large. in potentially significant space savings if the message is large.
Therefore, all header parameters that specify the treatment of the Therefore, all Header Parameters that specify the treatment of the
Plaintext value MUST be the same for all recipients. This primarily Plaintext value MUST be the same for all recipients. This primarily
means that the "enc" (encryption method) header parameter value in means that the "enc" (encryption method) Header Parameter value in
the JWE Header for each recipient and any parameters of that the JWE Header for each recipient and any parameters of that
algorithm MUST be the same. algorithm MUST be the same.
See Appendix A.4 for an example of computing a JWE using the JWE JSON See Appendix A.4 for an example of computing a JWE using the JWE JSON
Serialization. Serialization.
8. Distinguishing Between JWS and JWE Objects 8. Distinguishing Between JWS and JWE Objects
There are several ways of distinguishing whether an object is a JWS There are several ways of distinguishing whether an object is a JWS
or JWE object. All these methods will yield the same result for all or JWE object. All these methods will yield the same result for all
skipping to change at page 25, line 33 skipping to change at page 23, line 17
separated by period ('.') characters differs for JWSs and JWEs. separated by period ('.') characters differs for JWSs and JWEs.
JWSs have three segments separated by two period ('.') characters. JWSs have three segments separated by two period ('.') characters.
JWEs have five segments separated by four period ('.') characters. JWEs have five segments separated by four period ('.') characters.
o If the object is using the JWS JSON Serialization or the JWE JSON o If the object is using the JWS JSON Serialization or the JWE JSON
Serialization, the members used will be different. JWSs have a Serialization, the members used will be different. JWSs have a
"signatures" member and JWEs do not. JWEs have a "recipients" "signatures" member and JWEs do not. JWEs have a "recipients"
member and JWSs do not. member and JWSs do not.
o A JWS Header can be distinguished from a JWE header by examining o A JWS Header can be distinguished from a JWE header by examining
the "alg" (algorithm) header parameter value. If the value the "alg" (algorithm) Header Parameter value. If the value
represents a digital signature or MAC algorithm, or is the value represents a digital signature or MAC algorithm, or is the value
"none", it is for a JWS; if it represents a Key Encryption, Key "none", it is for a JWS; if it represents a Key Encryption, Key
Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping,
or Direct Encryption algorithm, it is for a JWE. or Direct Encryption algorithm, it is for a JWE.
o A JWS Header can also be distinguished from a JWE header by o A JWS Header can also be distinguished from a JWE header by
determining whether an "enc" (encryption method) member exists. determining whether an "enc" (encryption method) member exists.
If the "enc" member exists, it is a JWE; otherwise, it is a JWS. If the "enc" member exists, it is a JWE; otherwise, it is a JWS.
9. IANA Considerations 9. IANA Considerations
9.1. JWE Header Parameter Names Registration 9.1. JWE Header Parameter Names Registration
This specification registers the Header Parameter Names defined in This specification registers the Header Parameter names defined in
Section 4.1 in the IANA JSON Web Signature and Encryption Header Section 4.1 in the IANA JSON Web Signature and Encryption Header
Parameters registry defined in [JWS]. Parameters registry defined in [JWS].
9.1.1. Registry Contents 9.1.1. Registry Contents
o Header Parameter Name: "alg" o Header Parameter Name: "alg"
o Header Parameter Usage Location(s): JWE o Header Parameter Usage Location(s): JWE
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.1 of [[ this document ]] o Specification Document(s): Section 4.1.1 of [[ this document ]]
skipping to change at page 28, line 6 skipping to change at page 25, line 38
the encrypted content is rejected. the encrypted content is rejected.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ECMAScript] [ECMAScript]
Ecma International, "ECMAScript Language Specification, Ecma International, "ECMAScript Language Specification,
5.1 Edition", ECMA 262, June 2011. 5.1 Edition", ECMA 262, June 2011.
[IANA.MediaTypes]
Internet Assigned Numbers Authority (IANA), "MIME Media
Types", 2005.
[ITU.X690.1994]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", [JWA] Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms (work in progress), draft-ietf-jose-json-web-algorithms (work in progress),
September 2013. October 2013.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
September 2013. October 2013.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), September 2013. in progress), October 2013.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[W3C.CR-xmlenc-core1-20120313] [W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
"XML Encryption Syntax and Processing Version 1.1", World "XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium CR CR-xmlenc-core1-20120313, Wide Web Consortium CR CR-xmlenc-core1-20120313,
March 2012, March 2012,
<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
11.2. Informative References 11.2. Informative References
[I-D.mcgrew-aead-aes-cbc-hmac-sha2] [I-D.mcgrew-aead-aes-cbc-hmac-sha2]
skipping to change at page 29, line 48 skipping to change at page 26, line 52
Rescorla, E. and J. Hildebrand, "JavaScript Message Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", draft-rescorla-jsms-00 (work in Security Format", draft-rescorla-jsms-00 (work in
progress), March 2011. progress), March 2011.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010. Encryption", September 2010.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on [RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218, January 2002. Cryptographic Message Syntax", RFC 3218, January 2002.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
Appendix A. JWE Examples Appendix A. JWE Examples
This section provides examples of JWE computations. This section provides examples of JWE computations.
A.1. Example JWE using RSAES OAEP and AES GCM A.1. Example JWE using RSAES OAEP and AES GCM
This example encrypts the plaintext "The true sign of intelligence is This example encrypts the plaintext "The true sign of intelligence is
skipping to change at page 30, line 25 skipping to change at page 27, line 25
representation of this plaintext is: representation of this plaintext is:
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,
111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,
101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,
101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,
110, 97, 116, 105, 111, 110, 46] 110, 97, 116, 105, 111, 110, 46]
A.1.1. JWE Header A.1.1. JWE Header
The following example JWE Header declares that: The following example JWE Protected Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES OAEP algorithm to produce the JWE Encrypted Key and RSAES OAEP algorithm to produce the JWE Encrypted Key and
o the Plaintext is encrypted using the AES GCM algorithm with a 256 o the Plaintext is encrypted using the AES GCM algorithm with a 256
bit key to produce the Ciphertext. bit key to produce the Ciphertext.
{"alg":"RSA-OAEP","enc":"A256GCM"} {"alg":"RSA-OAEP","enc":"A256GCM"}
A.1.2. Encoded JWE Header Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
Header)) gives this value:
Base64url encoding the octets of the UTF-8 representation of the JWE
Header yields this Encoded JWE Header value:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
A.1.3. Content Encryption Key (CEK) A.1.2. Content Encryption Key (CEK)
Generate a 256 bit random Content Encryption Key (CEK). In this Generate a 256 bit random Content Encryption Key (CEK). In this
example, the value is: example, the value is:
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,
212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,
234, 64, 252] 234, 64, 252]
A.1.4. Key Encryption A.1.3. Key Encryption
Encrypt the CEK with the recipient's public key using the RSAES OAEP Encrypt the CEK with the recipient's public key using the RSAES OAEP
algorithm to produce the JWE Encrypted Key. This example uses the RSA algorithm to produce the JWE Encrypted Key. This example uses the RSA
key represented in JSON Web Key [JWK] format below (with line breaks key represented in JSON Web Key [JWK] format below (with line breaks
for display purposes only): for display purposes only):
{"kty":"RSA", {"kty":"RSA",
"n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW "n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW
cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S
psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a
skipping to change at page 31, line 49 skipping to change at page 28, line 49
41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126, 41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126,
215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58, 215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58,
63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98, 63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98,
193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215, 193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215,
206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216, 206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216,
104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197, 104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197,
89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219, 89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219,
172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134, 172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134,
117, 114, 135, 206] 117, 114, 135, 206]
A.1.5. Encoded JWE Encrypted Key Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives
this value (with line breaks for display purposes only):
Base64url encode the JWE Encrypted Key to produce the Encoded JWE
Encrypted Key. This result (with line breaks for display purposes
only) is:
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg 6UklfCpIMfIjf7iGdXKHzg
A.1.6. Initialization Vector A.1.4. Initialization Vector
Generate a random 96 bit JWE Initialization Vector. In this example, Generate a random 96 bit JWE Initialization Vector. In this example,
the value is: the value is:
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219] [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
Base64url encoding this value yields this Encoded JWE Initialization Encoding this JWE Initialization Vector as BASE64URL(JWE
Vector value: Initialization Vector) gives this value:
48V1_ALb6US04U3b 48V1_ALb6US04U3b
A.1.7. Additional Authenticated Data A.1.5. Additional Authenticated Data
Let the Additional Authenticated Data encryption parameter be the Let the Additional Authenticated Data encryption parameter be
octets of the ASCII representation of the Encoded JWE Header value. ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
This AAD value is:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,
54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81] 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
A.1.8. Content Encryption A.1.6. Content Encryption
Encrypt the Plaintext with AES GCM using the CEK as the encryption Encrypt the Plaintext with AES GCM using the CEK as the encryption
key, the JWE Initialization Vector, and the Additional Authenticated key, the JWE Initialization Vector, and the Additional Authenticated
Data value above, requesting a 128 bit Authentication Tag output. Data value above, requesting a 128 bit Authentication Tag output.
The resulting Ciphertext is: The resulting Ciphertext is:
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122, [229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122,
233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111, 233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111,
104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32, 104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32,
123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205, 123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205,
160, 109, 64, 63, 192] 160, 109, 64, 63, 192]
The resulting Authentication Tag value is: The resulting Authentication Tag value is:
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91, [92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91,
210, 145] 210, 145]
A.1.9. Encoded JWE Ciphertext Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value (with line breaks for display purposes only):
Base64url encode the Ciphertext to create the Encoded JWE Ciphertext.
This result (with line breaks for display purposes only) is:
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A SdiwkIr3ajwQzaBtQD_A
A.1.10. Encoded JWE Authentication Tag Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
Base64url encode the Authentication Tag to create the Encoded JWE
Authentication Tag. This result is:
XFBoMYUZodetZdvTiFvSkQ XFBoMYUZodetZdvTiFvSkQ
A.1.11. Complete Representation A.1.7. Complete Representation
Assemble the final representation: The Compact Serialization of this Assemble the final representation: The Compact Serialization of this
result is the concatenation of the Encoded JWE Header, the Encoded result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' ||
JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
JWE Ciphertext, and the Encoded JWE Authentication Tag in that order, Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
with the five strings being separated by four period ('.') Authentication Tag).
characters.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg. 6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b. 48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A. SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ XFBoMYUZodetZdvTiFvSkQ
A.1.12. Validation A.1.8. Validation
This example illustrates the process of creating a JWE with RSAES This example illustrates the process of creating a JWE with RSAES
OAEP for key encryption and AES GCM for content encryption. These OAEP for key encryption and AES GCM for content encryption. These
results can be used to validate JWE decryption implementations for results can be used to validate JWE decryption implementations for
these algorithms. Note that since the RSAES OAEP computation these algorithms. Note that since the RSAES OAEP computation
includes random values, the encryption results above will not be includes random values, the encryption results above will not be
completely reproducible. However, since the AES GCM computation is completely reproducible. However, since the AES GCM computation is
deterministic, the JWE Encrypted Ciphertext values will be the same deterministic, the JWE Encrypted Ciphertext values will be the same
for all encryptions performed using these inputs. for all encryptions performed using these inputs.
skipping to change at page 34, line 18 skipping to change at page 31, line 10
This example encrypts the plaintext "Live long and prosper." to the This example encrypts the plaintext "Live long and prosper." to the
recipient using RSAES-PKCS1-V1_5 for key encryption and recipient using RSAES-PKCS1-V1_5 for key encryption and
AES_128_CBC_HMAC_SHA_256 for content encryption. The representation AES_128_CBC_HMAC_SHA_256 for content encryption. The representation
of this plaintext is: of this plaintext is:
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46] 112, 114, 111, 115, 112, 101, 114, 46]
A.2.1. JWE Header A.2.1. JWE Header
The following example JWE Header (with line breaks for display The following example JWE Protected Header declares that:
purposes only) declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
algorithm to produce the Ciphertext. algorithm to produce the Ciphertext.
{"alg":"RSA1_5","enc":"A128CBC-HS256"} {"alg":"RSA1_5","enc":"A128CBC-HS256"}
A.2.2. Encoded JWE Header Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
Header)) gives this value:
Base64url encoding the octets of the UTF-8 representation of the JWE
Header yields this Encoded JWE Header value:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.2.3. Content Encryption Key (CEK) A.2.2. Content Encryption Key (CEK)
Generate a 256 bit random Content Encryption Key (CEK). In this Generate a 256 bit random Content Encryption Key (CEK). In this
example, the key value is: example, the key value is:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207] 44, 207]
A.2.4. Key Encryption A.2.3. Key Encryption
Encrypt the CEK with the recipient's public key using the RSAES- Encrypt the CEK with the recipient's public key using the RSAES-
PKCS1-V1_5 algorithm to produce the JWE Encrypted Key. This example PKCS1-V1_5 algorithm to produce the JWE Encrypted Key. This example
uses the RSA key represented in JSON Web Key [JWK] format below (with uses the RSA key represented in JSON Web Key [JWK] format below (with
line breaks for display purposes only): line breaks for display purposes only):
{"kty":"RSA", {"kty":"RSA",
"n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl "n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl
UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre
cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_ cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_
skipping to change at page 35, line 42 skipping to change at page 32, line 42
250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197, 250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197,
21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102, 21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102,
166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222, 166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222,
150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241, 150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241,
124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242, 124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242,
16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244, 16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244,
248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167, 248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167,
101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169, 101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169,
146, 114, 165, 204, 71, 136, 41, 252] 146, 114, 165, 204, 71, 136, 41, 252]
A.2.5. Encoded JWE Encrypted Key Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives
this value (with line breaks for display purposes only):
Base64url encode the JWE Encrypted Key to produce the Encoded JWE
Encrypted Key. This result (with line breaks for display purposes
only) is:
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc 1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8 NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A -B3oWh2TbqmScqXMR4gp_A
A.2.6. Initialization Vector A.2.4. Initialization Vector
Generate a random 128 bit JWE Initialization Vector. In this Generate a random 128 bit JWE Initialization Vector. In this
example, the value is: example, the value is:
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101] 101]
Base64url encoding this value yields this Encoded JWE Initialization Encoding this JWE Initialization Vector as BASE64URL(JWE
Vector value: Initialization Vector) gives this value:
AxY8DCtDaGlsbGljb3RoZQ AxY8DCtDaGlsbGljb3RoZQ
A.2.7. Additional Authenticated Data A.2.5. Additional Authenticated Data
Let the Additional Authenticated Data encryption parameter be the Let the Additional Authenticated Data encryption parameter be
octets of the ASCII representation of the Encoded JWE Header value. ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
This AAD value is:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105,
74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85,
50, 73, 110, 48] 50, 73, 110, 48]
A.2.8. Content Encryption A.2.6. Content Encryption
Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as
the encryption key, the JWE Initialization Vector, and the Additional the encryption key, the JWE Initialization Vector, and the Additional
Authenticated Data value above. The steps for doing this using the Authenticated Data value above. The steps for doing this using the
values from Appendix A.3 are detailed in Appendix B. The resulting values from Appendix A.3 are detailed in Appendix B. The resulting
Ciphertext is: Ciphertext is:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, [40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102] 112, 56, 102]
The resulting Authentication Tag value is: The resulting Authentication Tag value is:
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100, [246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100,
191] 191]
A.2.9. Encoded JWE Ciphertext Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value:
Base64url encode the Ciphertext to create the Encoded JWE Ciphertext.
This result is:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
A.2.10. Encoded JWE Authentication Tag Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
Base64url encode the Authentication Tag to create the Encoded JWE
Authentication Tag. This result is:
9hH0vgRfYgPnAHOd8stkvw 9hH0vgRfYgPnAHOd8stkvw
A.2.11. Complete Representation A.2.7. Complete Representation
Assemble the final representation: The Compact Serialization of this Assemble the final representation: The Compact Serialization of this
result is the concatenation of the Encoded JWE Header, the Encoded result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' ||
JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
JWE Ciphertext, and the Encoded JWE Authentication Tag in that order, Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
with the five strings being separated by four period ('.') Authentication Tag).
characters.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc 1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8 NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A. -B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ. AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY. KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw 9hH0vgRfYgPnAHOd8stkvw
A.2.12. Validation A.2.8. Validation
This example illustrates the process of creating a JWE with RSAES- This example illustrates the process of creating a JWE with RSAES-
PKCS1-V1_5 for key encryption and AES_CBC_HMAC_SHA2 for content PKCS1-V1_5 for key encryption and AES_CBC_HMAC_SHA2 for content
encryption. These results can be used to validate JWE decryption encryption. These results can be used to validate JWE decryption
implementations for these algorithms. Note that since the RSAES- implementations for these algorithms. Note that since the RSAES-
PKCS1-V1_5 computation includes random values, the encryption results PKCS1-V1_5 computation includes random values, the encryption results
above will not be completely reproducible. However, since the AES above will not be completely reproducible. However, since the AES
CBC computation is deterministic, the JWE Encrypted Ciphertext values CBC computation is deterministic, the JWE Encrypted Ciphertext values
will be the same for all encryptions performed using these inputs. will be the same for all encryptions performed using these inputs.
skipping to change at page 38, line 10 skipping to change at page 34, line 51
This example encrypts the plaintext "Live long and prosper." to the This example encrypts the plaintext "Live long and prosper." to the
recipient using AES Key Wrap for key encryption and AES GCM for recipient using AES Key Wrap for key encryption and AES GCM for
content encryption. The representation of this plaintext is: content encryption. The representation of this plaintext is:
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46] 112, 114, 111, 115, 112, 101, 114, 46]
A.3.1. JWE Header A.3.1. JWE Header
The following example JWE Header declares that: The following example JWE Protected Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
AES Key Wrap algorithm with a 128 bit key to produce the JWE AES Key Wrap algorithm with a 128 bit key to produce the JWE
Encrypted Key and Encrypted Key and
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
algorithm to produce the Ciphertext. algorithm to produce the Ciphertext.
{"alg":"A128KW","enc":"A128CBC-HS256"} {"alg":"A128KW","enc":"A128CBC-HS256"}
A.3.2. Encoded JWE Header Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
Header)) gives this value:
Base64url encoding the octets of the UTF-8 representation of the JWE
Header yields this Encoded JWE Header value:
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.3.3. Content Encryption Key (CEK) A.3.2. Content Encryption Key (CEK)
Generate a 256 bit random Content Encryption Key (CEK). In this Generate a 256 bit random Content Encryption Key (CEK). In this
example, the value is: example, the value is:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, [4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207] 44, 207]
A.3.4. Key Encryption A.3.3. Key Encryption
Encrypt the CEK with the shared symmetric key using the AES Key Wrap Encrypt the CEK with the shared symmetric key using the AES Key Wrap
algorithm to produce the JWE Encrypted Key. This example uses the algorithm to produce the JWE Encrypted Key. This example uses the
symmetric key represented in JSON Web Key [JWK] format below: symmetric key represented in JSON Web Key [JWK] format below:
{"kty":"oct", {"kty":"oct",
"k":"GawgguFyGrWKav7AX4VKUg" "k":"GawgguFyGrWKav7AX4VKUg"
} }
The resulting JWE Encrypted Key value is: The resulting JWE Encrypted Key value is:
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216, [232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216,
22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3, 22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3,
76, 124, 193, 11, 98, 37, 173, 61, 104, 57] 76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
A.3.5. Encoded JWE Encrypted Key Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives
this value:
Base64url encode the JWE Encrypted Key to produce the Encoded JWE
Encrypted Key. This result is:
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
A.3.6. Initialization Vector A.3.4. Initialization Vector
Generate a random 128 bit JWE Initialization Vector. In this Generate a random 128 bit JWE Initialization Vector. In this
example, the value is: example, the value is:
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, [3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101] 101]
Base64url encoding this value yields this Encoded JWE Initialization Encoding this JWE Initialization Vector as BASE64URL(JWE
Vector value: Initialization Vector) gives this value:
AxY8DCtDaGlsbGljb3RoZQ AxY8DCtDaGlsbGljb3RoZQ
A.3.7. Additional Authenticated Data A.3.5. Additional Authenticated Data
Let the Additional Authenticated Data encryption parameter be the Let the Additional Authenticated Data encryption parameter be
octets of the ASCII representation of the Encoded JWE Header value. ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
This AAD value is:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48] 110, 48]
A.3.8. Content Encryption A.3.6. Content Encryption
Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as
the encryption key, the JWE Initialization Vector, and the Additional the encryption key, the JWE Initialization Vector, and the Additional
Authenticated Data value above. The steps for doing this using the Authenticated Data value above. The steps for doing this using the
values from this example are detailed in Appendix B. The resulting values from this example are detailed in Appendix B. The resulting
Ciphertext is: Ciphertext is:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, [40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102] 112, 56, 102]
The resulting Authentication Tag value is: The resulting Authentication Tag value is:
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, [83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85] 194, 85]
A.3.9. Encoded JWE Ciphertext Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value:
Base64url encode the Ciphertext to create the Encoded JWE Ciphertext.
This result is:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
A.3.10. Encoded JWE Authentication Tag Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
Base64url encode the Authentication Tag to create the Encoded JWE
Authentication Tag. This result is:
U0m_YmjN04DJvceFICbCVQ U0m_YmjN04DJvceFICbCVQ
A.3.11. Complete Representation A.3.7. Complete Representation
Assemble the final representation: The Compact Serialization of this Assemble the final representation: The Compact Serialization of this
result is the concatenation of the Encoded JWE Header, the Encoded result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' ||
JWE Encrypted Key, the Encoded JWE Initialization Vector, the Encoded BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
JWE Ciphertext, and the Encoded JWE Authentication Tag in that order, Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
with the five strings being separated by four period ('.') Authentication Tag).
characters.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ. 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.
AxY8DCtDaGlsbGljb3RoZQ. AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY. KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
U0m_YmjN04DJvceFICbCVQ U0m_YmjN04DJvceFICbCVQ
A.3.12. Validation A.3.8. Validation
This example illustrates the process of creating a JWE with AES Key This example illustrates the process of creating a JWE with AES Key
Wrap for key encryption and AES GCM for content encryption. These Wrap for key encryption and AES GCM for content encryption. These
results can be used to validate JWE decryption implementations for results can be used to validate JWE decryption implementations for
these algorithms. Also, since both the AES Key Wrap and AES GCM these algorithms. Also, since both the AES Key Wrap and AES GCM
computations are deterministic, the resulting JWE value will be the computations are deterministic, the resulting JWE value will be the
same for all encryptions performed using these inputs. Since the same for all encryptions performed using these inputs. Since the
computation is reproducible, these results can also be used to computation is reproducible, these results can also be used to
validate JWE encryption implementations for these algorithms. validate JWE encryption implementations for these algorithms.
A.4. Example JWE Using JWE JSON Serialization A.4. Example JWE using JWE JSON Serialization
This section contains an example using the JWE JSON Serialization. This section contains an example using the JWE JSON Serialization.
This example demonstrates the capability for encrypting the same This example demonstrates the capability for encrypting the same
plaintext to multiple recipients. plaintext to multiple recipients.
Two recipients are present in this example. The algorithm and key Two recipients are present in this example. The algorithm and key
used for the first recipient are the same as that used in used for the first recipient are the same as that used in
Appendix A.2. The algorithm and key used for the second recipient Appendix A.2. The algorithm and key used for the second recipient
are the same as that used in Appendix A.3. The resulting JWE are the same as that used in Appendix A.3. The resulting JWE
Encrypted Key values are therefore the same; those computations are Encrypted Key values are therefore the same; those computations are
skipping to change at page 41, line 39 skipping to change at page 38, line 27
{"alg":"A128KW","kid":"7"} {"alg":"A128KW","kid":"7"}
A.4.2. JWE Protected Header A.4.2. JWE Protected Header
The Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 The Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
algorithm to produce the common JWE Ciphertext and JWE Authentication algorithm to produce the common JWE Ciphertext and JWE Authentication
Tag values. The JWE Protected Header value representing this is: Tag values. The JWE Protected Header value representing this is:
{"enc":"A128CBC-HS256"} {"enc":"A128CBC-HS256"}
Base64url encoding the octets of the UTF-8 representation of the JWE Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
Protected Header yields this Encoded JWE Protected Header value: Header)) gives this value:
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.4.3. JWE Unprotected Header A.4.3. JWE Unprotected Header
This JWE uses the "jku" header parameter to reference a JWK Set. This This JWE uses the "jku" Header Parameter to reference a JWK Set. This
is represented in the following JWE Unprotected Header value as: is represented in the following JWE Unprotected Header value as:
{"jku":"https://server.example.com/keys.jwks"} {"jku":"https://server.example.com/keys.jwks"}
A.4.4. Complete JWE Header Values A.4.4. Complete JWE Header Values
Combining the per-recipient, protected, and unprotected header values Combining the per-recipient, protected, and unprotected header values
supplied, the JWE Header values used for the first and second supplied, the JWE Header values used for the first and second
recipient respectively are: recipient respectively are:
skipping to change at page 42, line 17 skipping to change at page 39, line 4
Combining the per-recipient, protected, and unprotected header values Combining the per-recipient, protected, and unprotected header values
supplied, the JWE Header values used for the first and second supplied, the JWE Header values used for the first and second
recipient respectively are: recipient respectively are:
{"alg":"RSA1_5", {"alg":"RSA1_5",
"kid":"2011-04-29", "kid":"2011-04-29",
"enc":"A128CBC-HS256", "enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"} "jku":"https://server.example.com/keys.jwks"}
and and
{"alg":"A128KW", {"alg":"A128KW",
"kid":"7", "kid":"7",
"enc":"A128CBC-HS256", "enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"} "jku":"https://server.example.com/keys.jwks"}
A.4.5. Additional Authenticated Data A.4.5. Additional Authenticated Data
Let the Additional Authenticated Data encryption parameter be the Let the Additional Authenticated Data encryption parameter be
octets of the ASCII representation of the Encoded JWE Protected ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
Header value. This AAD value is:
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, [101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73,
52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48] 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
A.4.6. Content Encryption A.4.6. Content Encryption
Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as
the encryption key, the JWE Initialization Vector, and the Additional the encryption key, the JWE Initialization Vector, and the Additional
Authenticated Data value above. The steps for doing this using the Authenticated Data value above. The steps for doing this using the
values from Appendix A.3 are detailed in Appendix B. The resulting values from Appendix A.3 are detailed in Appendix B. The resulting
skipping to change at page 42, line 49 skipping to change at page 39, line 34
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, [40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102] 112, 56, 102]
The resulting Authentication Tag value is: The resulting Authentication Tag value is:
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47, [51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47,
207] 207]
A.4.7. Encoded JWE Ciphertext Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value:
Base64url encode the Ciphertext to create the Encoded JWE Ciphertext.
This result is:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
A.4.8. Encoded JWE Authentication Tag Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
Base64url encode the Authentication Tag to create the Encoded JWE
Authentication Tag. This result is:
Mz-VPPyU4RlcuYv1IwIvzw Mz-VPPyU4RlcuYv1IwIvzw
A.4.9. Complete JWE JSON Serialization Representation A.4.7. Complete JWE JSON Serialization Representation
The complete JSON Web Encryption JSON Serialization for these values The complete JSON Web Encryption JSON Serialization for these values
is as follows (with line breaks for display purposes only): is as follows (with line breaks for display purposes only):
{"protected": {"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected": "unprotected":
{"jku":"https://server.example.com/keys.jwks"}, {"jku":"https://server.example.com/keys.jwks"},
"recipients":[ "recipients":[
{"header": {"header":
skipping to change at page 46, line 41 skipping to change at page 43, line 26
Hannes Tschofenig, and Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix D. Document History Appendix D. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-17
o Refined the "typ" and "cty" definitions to always be MIME Media
Types, with the omission of "application/" prefixes recommended
for brevity, addressing issue #50.
o Updated the mandatory-to-implement (MTI) language to say that
general-purpose implementations must implement the single
recipient case for both serializations whereas special-purpose
implementations can implement just one serialization if that meets
the needs of the use cases the implementation is designed for,
addressing issue #176.
o Explicitly named all the logical components of a JWE and defined
the processing rules and serializations in terms of those
components, addressing issues #60, #61, and #62.
o Replaced verbose repetitive phases such as "base64url encode the
octets of the UTF-8 representation of X" with mathematical
notation such as "BASE64URL(UTF8(X))".
o Header Parameters and processing rules occurring in both JWS and
JWE are now referenced in JWS by JWE, rather than duplicated,
addressing issue #57.
o Terms used in multiple documents are now defined in one place and
incorporated by reference. Some lightly used or obvious terms
were also removed. This addresses issue #58.
-16 -16
o Changes to address editorial and minor issues #163, #168, #169, o Changes to address editorial and minor issues #163, #168, #169,
#170, #172, and #173. #170, #172, and #173.
-15 -15
o Clarified that it is an application decision which recipients' o Clarified that it is an application decision which recipients'
encrypted content must successfully validate for the JWE to be encrypted content must successfully validate for the JWE to be
accepted, addressing issue #35. accepted, addressing issue #35.
skipping to change at page 48, line 7 skipping to change at page 45, line 23
-11 -11
o Added Key Identification section. o Added Key Identification section.
o Removed the Encrypted Key value from the AAD computation since it o Removed the Encrypted Key value from the AAD computation since it
is already effectively integrity protected by the encryption is already effectively integrity protected by the encryption
process. The AAD value now only contains the representation of process. The AAD value now only contains the representation of
the JWE Encrypted Header. the JWE Encrypted Header.
o For the JWE JSON Serialization, enable header parameter values to o For the JWE JSON Serialization, enable Header Parameter values to
be specified in any of three parameters: the "protected" member be specified in any of three parameters: the "protected" member
that is integrity protected and shared among all recipients, the that is integrity protected and shared among all recipients, the
"unprotected" member that is not integrity protected and shared "unprotected" member that is not integrity protected and shared
among all recipients, and the "header" member that is not among all recipients, and the "header" member that is not
integrity protected and specific to a particular recipient. (This integrity protected and specific to a particular recipient. (This
does not affect the JWE Compact Serialization, in which all header does not affect the JWE Compact Serialization, in which all Header
parameter values are in a single integrity protected JWE Header Parameter values are in a single integrity protected JWE Header
value.) value.)
o Shortened the names "authentication_tag" to "tag" and o Shortened the names "authentication_tag" to "tag" and
"initialization_vector" to "iv" in the JWE JSON Serialization, "initialization_vector" to "iv" in the JWE JSON Serialization,
addressing issue #20. addressing issue #20.
o Removed "apv" (agreement PartyVInfo) since it is no longer used. o Removed "apv" (agreement PartyVInfo) since it is no longer used.
o Removed suggested compact serialization for multiple recipients. o Removed suggested compact serialization for multiple recipients.
 End of changes. 160 change blocks. 
666 lines changed or deleted 553 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/