identity 1.0 documentation

JSON Web Encryption (JWE)

«  Holder-of-Key JSON Web Signature (JWS)   ::   Contents   ::   JSON Web Key (JWK)  »

JSON Web Encryption (JWE)

Abstract

JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Related signature capabilities are described in the separate JSON Web Signature (JWS) specification.

(v.01)

JSON Web Encryption (JWE) represents encrypted content

using JavaScript Object Notation (JSON) based data structures.

Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification.

Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification.

(draft 16)

1. Introduction

JSON Web Encryption (JWE) is a compact encryption format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. It represents this content using JavaScript Object Notation (JSON) [RFC4627] based data structures. The JWE cryptographic mechanisms encrypt and provide integrity protection for arbitrary sequences of bytes.

Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) [JWS] specification.

2. Terminology

JSON Web Encryption (JWE)
A data structure representing an encrypted message. The structure represents five values: the JWE Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag.
Authenticated Encryption with Associated Data (AEAD)

An AEAD algorithm is one that encrypts the Plaintext, allows Additional Authenticated Data to be specified, and provides an integrated content integrity check over the Ciphertext and Additional Authenticated Data.

AEAD algorithms accept two inputs, the Plaintext and the Additional Authenticated Data value, and produce two outputs, the Ciphertext and the Authentication Tag value.

AES Galois/Counter Mode (GCM) is one such algorithm.

Plaintext
The sequence of octets to be encrypted – a.k.a., the message. The plaintext can contain an arbitrary sequence of octets.
Ciphertext
An encrypted representation of the Plaintext.
Additional Authenticated Data (AAD)
An input to an AEAD operation that is integrity protected but not encrypted.
Authentication Tag
An output of an AEAD operation that ensures the integrity of the Ciphertext and the Additional Authenticated Data. Note that some algorithms may not use an Authentication Tag, in which case this value is the empty octet sequence.
Content Encryption Key (CEK)
A symmetric key for the AEAD algorithm used to encrypt the Plaintext for the recipient to produce the 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 JSON Serialization) that describes the encryption operations applied to create the JWE Encrypted Key, the JWE Ciphertext, and the JWE Authentication Tag.

The members of the JWE Header object(s) are Header Parameters.

JWE Encrypted Key
The result of encrypting the Content Encryption Key (CEK) with the intended recipient’s key using the specified algorithm. Note that for some algorithms, the JWE Encrypted Key value is specified as being the empty octet sequence.
JWE Initialization Vector
A sequence of octets containing the Initialization Vector used when encrypting the Plaintext. Note that some algorithms may not use an Initialization Vector, in which case this value is the empty octet sequence.
JWE Ciphertext
A sequence of octets containing the Ciphertext for a JWE.
JWE Authentication Tag
A sequence of octets containing the Authentication Tag for a JWE.
JWE Protected Header
A JSON Text Object that contains the portion of the JWE Header that is integrity protected. For the JWE Compact Serialization, this comprises the entire JWE Header. For the JWE 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
Name The name of a member of the JWE Header.
Header Parameter Value
The value of a member of the JWE Header.
Base64url Encoding
The URL- and filename-safe Base64 encoding described in RFC 4648 [RFC4648], Section 5, with the (non URL- safe) ‘=’ padding 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 structure containing JWE Header, Encoded JWE Encrypted Key, Encoded JWE Initialization Vector, Encoded JWE Ciphertext, and Encoded JWE Authentication Tag values. Unlike the JWE Compact 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 Namespace
A namespace that allows names to be allocated in a manner such that they are highly unlikely to collide with other names. For instance, collision resistance can be achieved through administrative delegation of portions of the namespace or through use of collision-resistant name allocation functions. 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 (CEK) value to use. Each algorithm used for determining the CEK value uses a specific Key Management Mode. Key Management Modes employed by this specification are Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, and Direct Encryption.
Key Encryption
A Key Management Mode in which the Content Encryption Key (CEK) value is encrypted to the intended recipient using an asymmetric encryption algorithm.
Key Wrapping
A Key Management Mode in which the Content Encryption Key (CEK) value is encrypted to the intended recipient using a symmetric key wrapping algorithm.
Direct Key Agreement
A Key Management Mode in which a key agreement algorithm is used to agree upon the Content Encryption Key (CEK) value.
Key Agreement with Key Wrapping
A Key Management Mode in which a key agreement algorithm is used to agree upon a symmetric key used to encrypt the Content Encryption Key (CEK) value to the intended recipient using a symmetric key wrapping algorithm.
Direct Encryption
A Key Management Mode in which the Content Encryption Key (CEK) value used is the secret symmetric key value shared between the parties.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-2 )

3. JSON Web Encryption (JWE) Overview

JWE represents encrypted content using JSON data structures and base64url encoding. The representation consists of five parts: the JWE Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Integrity Value.

Note

HEADER.KEY.IV.TEXT.INTEGRITY

In the Compact Serialization, the five parts are base64url-encoded for transmission, and represented as the concatenation of the encoded strings in that order, with the five strings being separated by four period (‘.’) characters. (A JSON Serialization for this information is defined in the separate JSON Web Encryption JSON Serialization (JWE-JS) [JWE-JS] specification.)

JWE utilizes encryption to ensure the confidentiality of the Plaintext. JWE adds a content integrity check if not provided by the underlying encryption algorithm.

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-3 )

3.1. Example JWE using RSAES OAEP and AES GCM

This example encrypts the plaintext “Live long and prosper.” to the recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an integrated integrity check.

The following example JWE Header declares that:

  • the Content Master Key is encrypted to the recipient using the RSAES OAEP algorithm to produce the JWE Encrypted Key and
  • the Plaintext is encrypted using the AES GCM algorithm with a 256 bit key to produce the Ciphertext.
{"alg":"RSA-OAEP","enc":"A256GCM"}

Base64url encoding the bytes of the UTF-8 representation of the JWE Header yields this Encoded JWE Header value:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ

The remaining steps to finish creating this JWE are:

to create the “additional authenticated data” parameter for the AES GCM algorithm
  • Encrypt the Plaintext with AES GCM, using the CMK as the encryption key, the JWE Initialization Vector, and the “additional authenticated data” value above, requesting a 128 bit “authentication tag” output
  • Base64url encode the resulting Ciphertext to create the Encoded JWE Ciphertext
  • Base64url encode the resulting “authentication tag” to create the Encoded JWE Integrity Value
  • Assemble the final representation: The Compact Serialization of this result is 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 Integrity Value in that order, with the five strings being separated by four period (‘.’) characters.

The final result in this example (with line breaks for display purposes only) is:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m
rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA
O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj
zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN
SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG
6BBBbR37pHcyzext9epOAQ.
48V1_ALb6US04U3b.
_e21tGGhac_peEFkLXr2dMPUZiUkrw.
7V5ZDko0v_mf2PAc4JMiUg

See Appendix A.1 for the complete details of computing this JWE.

(draft 08 , http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-3.1 )

3.2. Example JWE using RSAES-PKCS1-V1_5 and AES CBC

This example encrypts the plaintext “No matter where you go, there you are.” to the recipient using RSAES-PKCS1-V1_5 and AES CBC.

AES CBC does not have an integrated integrity check, so a separate integrity check calculation is performed using HMAC SHA-256, with separate encryption and integrity keys being derived from a master key using the Concat KDF with the SHA-256 digest function.

The following example JWE Header (with line breaks for display purposes only) declares that:

  • the Content Master Key is encrypted to the recipient using the RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
  • the Plaintext is encrypted using the AES CBC algorithm with a 128 bit key to produce the Ciphertext, with the integrity of the Ciphertext and the parameters used to create it being secured using the HMAC SHA-256 algorithm.
{"alg":"RSA1_5","enc":"A128CBC+HS256"}

Base64url encoding the bytes of the UTF-8 representation of the JWE Header yields this Encoded JWE Header value:

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0

The remaining steps to finish creating this JWE are like the previous example, but with an additional step to compute the separate integrity value:

  • Generate a random Content Master Key (CMK)
  • Encrypt the CMK with the recipient’s public key using the RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key
  • Base64url encode the JWE Encrypted Key to produce the Encoded JWE Encrypted Key
  • Generate a random JWE Initialization Vector
  • Base64url encode the JWE Initialization Vector to produce the Encoded JWE Initialization Vector
  • Use the Concat key derivation function to derive Content Encryption Key (CEK) and Content Integrity Key (CIK) values from the CMK
  • Encrypt the Plaintext with AES CBC using the CEK and JWE Initialization Vector to produce the Ciphertext
  • Base64url encode the resulting Ciphertext to create the Encoded JWE Ciphertext
  • Concatenate the Encoded JWE Header value, a period character (‘.’), the Encoded JWE Encrypted Key, a second period character (‘.’), the Encoded JWE Initialization Vector, a third period (‘.’) character, and the Encoded JWE Ciphertext to create the value to integrity protect
  • Compute the HMAC SHA-256 of this value using the CIK to create the JWE Integrity Value
  • Base64url encode the resulting JWE Integrity Value to create the Encoded JWE Integrity Value
  • Assemble the final representation: The Compact Serialization of this result is 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 Integrity Value in that order, with the five strings being separated by four period (‘.’) characters.

The final result in this example (with line breaks for display purposes only) is:

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0.
O6AqXqgVlJJ4c4lp5sXZd7bpGHAw6ARkHUeXQxD1cAW4-X1x0qtj_AN0mukqEOl4
Y6UOwJXIJY9-G1ELK-RQWrKH_StR-AM9H7GpKmSEji8QYOcMOjr-u9H1Lt_pBEie
G802SxWz0rbFTXRcj4BWLxcpCtjUZ31AP-sc-L_eCZ5UNl0aSRNqFskuPkzRsFZR
DJqSSJeVOyJ7pZCQ83fli19Vgi_3R7XMUqluQuuc7ZHOWixi47jXlBTlWRZ5iFxa
S8G6J8wUrd4BKggAw3qX5XoIfXQVlQZE0Vmkq_zQSIo5LnFKyowooRcdsEuNh9B9
Mkyt0ZQElG-jGdtHWjZSOA.
AxY8DCtDaGlsbGljb3RoZQ.
1eBWFgcrz40wC88cgv8rPgu3EfmC1p4zT0kIxxfSF2zDJcQ-iEHk1jQM95xAdr5Z.
RBGhYzE8_cZLHjJqqHuLhzbgWgL_wV3LDSUrcbkOiIA

See Appendix A.2 for the complete details of computing this JWE.

( http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-3.2 )

4. JWE Header

The members of the JSON object represented by the JWE Header describe the encryption applied to the Plaintext and optionally additional properties of the JWE.

The Header Parameter Names within this object MUST be unique. Implementations MUST understand the entire contents of the header; otherwise, the JWE MUST be rejected for processing.

( draft 02 )

4.1. Reserved Header Parameter Names

The following Header Parameter Names are reserved with meanings as defined below. All the names are short because a core goal of JWE is for the representations to be compact.

Additional reserved Header Parameter Names MAY be defined via the IANA JSON Web Signature and Encryption Header Parameters registry [JWS]. As indicated by the common registry, JWSs and JWEs share a common header parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.

4.1.1. “alg” (Algorithm) Header Parameter

The “alg” (algorithm) header parameter identifies the cryptographic algorithm used to encrypt or determine the value of the Content Master Key (CMK).

The algorithm specified by the “alg” value MUST be supported by the implementation and there MUST be a key for use with that algorithm associated with the intended recipient or the JWE MUST be rejected. “alg” values SHOULD either be registered in the IANA JSON Web Signature and Encryption Algorithms registry [JWA] or be a value that contains a Collision Resistant Namespace. The “alg” value is a case sensitive string containing a StringOrURI value. Use of this header parameter is REQUIRED.

A list of defined “alg” values can be found in the IANA JSON Web Signature and Encryption Algorithms registry [JWA]; the initial contents of this registry are the values defined in Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification.

4.1.2. “enc” (Encryption Method) Header Parameter

The “enc” (encryption method) header parameter identifies the block encryption algorithm used to encrypt the Plaintext to produce the Ciphertext. This algorithm MUST be an Authenticated Encryption algorithm with a specified key length. The algorithm specified by the “enc” value MUST be supported by the implementation or the JWE MUST be rejected. “enc” values SHOULD either be registered in the IANA JSON Web Signature and Encryption Algorithms registry [JWA] or be a value that contains a Collision Resistant Namespace. The “enc” value is a case sensitive string containing a StringOrURI value. Use of this header parameter is REQUIRED.

A list of defined “enc” values can be found in the IANA JSON Web Signature and Encryption Algorithms registry [JWA]; the initial contents of this registry are the values defined in Section 4.2 of the JSON Web Algorithms (JWA) [JWA] specification.

4.1.3. “epk” (Ephemeral Public Key) Header Parameter

The “epk” (ephemeral public key) value created by the originator for the use in key agreement algorithms. This key is represented as a JSON Web Key [JWK] value. Use of this header parameter is OPTIONAL, although its use is REQUIRED with some “alg” algorithms.

4.1.4. “jku” (JWK Set URL) Header Parameter

The “jku” (JWK Set URL) header parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which is the key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.

The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The protocol used 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.

Note

  • 暗号化に使ったキー
  • このキーに対応するプライベートキーで復号する

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.4 )

4.1.5. “jwk” (JSON Web Key) Header Parameter

The “jwk” (JSON Web Key) header parameter is the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.

This key is represented as a JSON Web Key [JWK].

Use of this header parameter is OPTIONAL.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.5 )

4.1.6. “jwk” (JSON Web Key) Header Parameter

The “jwk” (JSON Web Key) header parameter is a public key that corresponds to the key used to encrypt the JWE; this can be used to determine the private key needed to decrypt the JWE. This key is represented as a JSON Web Key [JWK]. Use of this header parameter is OPTIONAL.

4.1.7. “x5u” (X.509 URL) Header Parameter

The “x5u” (X.509 URL) header parameter is a URI [RFC3986] that refers to a resource for the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to encrypt the JWE; this can be used to determine the private key needed to decrypt the JWE. The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM encoded form [RFC1421]. The certificate containing the public key of the entity that encrypted the JWE 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.8. “x5t” (X.509 Certificate Thumbprint) Header Parameter

The “x5t” (X.509 Certificate Thumbprint) header parameter provides a base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate [RFC5280] corresponding to the key used to encrypt the JWE; this can be used to determine the private key needed to decrypt the JWE. Use of this header parameter 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 [JWS].

4.1.9. “x5c” (X.509 Certificate Chain) Header Parameter

The “x5c” (X.509 Certificate Chain) header parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to encrypt the JWE; this can be used to determine the private key needed to decrypt the JWE. The certificate or certificate chain is represented as an array of certificate value strings. Each string is a base64 encoded ([RFC4648] Section 4 – not base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The certificate containing the public key of the entity that encrypted the JWE 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 recipient MUST verify the certificate chain according to [RFC5280] and reject the JWE if any validation failure occurs. Use of this header parameter is OPTIONAL.

See Appendix B of [JWS] for an example “x5c” value.

4.1.10. “typ” (Type) Header Parameter

The “typ” (type) header parameter MAY be used to declare the type of this complete JWE object in an application-specific manner in contexts where this is useful to the application.

This parameter has no effect upon the JWE processing.

The type value “JOSE” MAY be used 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” MAY be used to indicate that this object is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization.

Other type values MAY be used, and if not understood, SHOULD be ignored. 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.

“typ” values SHOULD either be registered in the IANA JSON Web Signature and Encryption Type Values registry [JWS] or be a value that contains a Collision Resistant Namespace.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.10 )

4.1.11. “cty” (Content Type) Header Parameter

The “cty” (content type) header parameter MAY be used to declare the type of the encrypted content (the Plaintext) in an application-specific manner in contexts where this is useful to the application.

This parameter has no effect upon the JWE processing. Content type values that are not understood SHOULD be ignored. 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.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.11 )

Note

  • cty : id_token とか?

4.1.12. “crit” (Critical) Header Parameter

The “crit” (critical) header parameter indicates that extensions to [[ this specification ]] are being used that MUST be understood and processed. Its value is an array listing the header parameter names 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 by implementations.

An example use, along with a hypothetical “exp” (expiration-time) field is:

{"alg":"RSA-OAEP",
 "enc":"A256GCM",
 "crit":["exp"],
 "exp":1363284000
}

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.12 )

6. Encrypting JWEs with Cryptographic Algorithms

JWE uses cryptographic algorithms to encrypt the Plaintext and the Content Encryption Key (CMK) and to provide integrity protection for the JWE Header, JWE Encrypted Key, and JWE Ciphertext.

The JSON Web Algorithms (JWA) [JWA] specification specifies a set of cryptographic algorithms and identifiers to be used with this specification and defines registries for additional such algorithms.

Specifically, Section 4.1 specifies a set of “alg” (algorithm) header parameter values and Section 4.2 specifies a set of “enc” (encryption method) header parameter values intended for use this specification.

It also describes the semantics and operations that are specific to these algorithms.

Public keys employed for encryption can be identified using the Header Parameter methods described in Section 4.1 or can be distributed using methods that are outside the scope of this specification.

6.1. CMK Encryption

JWE supports three forms of Content Master Key (CMK) encryption:

  • Asymmetric encryption under the recipient’s public key.
  • Symmetric encryption under a key shared between the sender and receiver.
  • Symmetric encryption under a key agreed upon between the sender and receiver.

See the algorithms registered for “enc” usage in the IANA JSON Web Signature and Encryption Algorithms registry [JWA] and Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification for lists of encryption algorithms that can be used for CMK encryption.

Note

  • draft 08,http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-6.1

7. Serializations

JWE objects use one of two serializations, the JWE Compact Serialization or the JWE JSON Serialization. The JWE Compact Serialization is mandatory to implement. Implementation of the JWE JSON Serialization is OPTIONAL.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-7 )

7.1. JWE Compact Serialization

The JWE Compact Serialization represents encrypted content as a compact URL-safe string.

This string is 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.

Only one recipient is supported by the JWE Compact Serialization.

[E-HEADER].[E-KEY].[E-IV].[Ciphertext].[E-TAG]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-7.1 )

7.2. JWE JSON Serialization

The JWE JSON Serialization represents encrypted content as a JSON object. Unlike the JWE Compact Serialization, content using the JWE JSON Serialization can be encrypted to more than one recipient.

The representation is closely related to that used in the JWE Compact Serialization, with the following differences for the JWE JSON Serialization:

  • Values in the JWE JSON Serialization are represented as members of a JSON object, rather than as base64url encoded strings separated by period (‘.’) characters. (However binary values and values that are integrity protected are still base64url encoded.)
  • The Encoded JWE Header value, if non-empty, is stored in the “protected” member.
  • The Encoded JWE Initialization Vector value is stored in the “iv” member.
  • The Encoded JWE Ciphertext value is stored in the “ciphertext” member.
  • The Encoded JWE Authentication Tag value is stored in the “tag” member.
  • The JWE can be encrypted to multiple recipients, rather than just one. A JSON array in the “recipients” member is used to hold values that are specific to a particular recipient, with one array element per recipient represented. These array elements are JSON objects.
  • Each Encoded JWE Encrypted Key value is stored in the “encrypted_key” member of a JSON object that is an element of the “recipients” array.
  • Some header parameter values, such as the “alg” value and parameters used for selecting keys, can also differ for different recipient computations. Per-recipient header parameter values are stored in the “header” members of the same JSON objects that are elements of the “recipients” array.
  • Some header parameters, including the “alg” parameter, can be shared among all recipient computations. These header parameters are stored in either of two top-level member(s) of the JSON object: the “protected” member and the “unprotected” member. The values of these members are JSON Text Objects containing Header Parameters.
  • Not all header parameters are integrity protected. The shared header parameters in the “protected” member are integrity protected, and are base64url encoded. The per-recipient header parameters in the “header” array element members and the shared header parameters in the “unprotected” member are not integrity protected. These JSON Text Objects containing header parameters that are not integrity protected are not base64url encoded.
  • The header parameter values used when creating or validating per- recipient Ciphertext and Authentication Tag values are the union of the three sets of header parameter values that may be present: (1) the per-recipient values in the “header” member of the recipient’s array element, (2) the shared integrity-protected values in the “protected” member, and (3) the shared non- integrity-protected values in the “unprotected” member. The union of these sets of header parameters comprises the JWE Header. The header parameter names in the three locations MUST be disjoint.
  • An “aad” (Additional Authenticated Data) member can be included to supply a base64url encoded value to be integrity protected but not encrypted. (Note that this can also be achieved when using either serialization by including the AAD value as a protected header parameter value, but at the cost of the value being double base64url encoded.)

The syntax of a JWE using the JWE JSON Serialization is as follows:

{"protected":<integrity-protected shared header contents>",
 "unprotected":<non-integrity-protected shared header contents>",

 "recipients":[
  {"header":"<per-recipient unprotected header 1 contents>",
   "encrypted_key":"<encrypted key 1 contents>"},
  ...
  {"header":"<per-recipient unprotected header N contents>",
   "encrypted_key":"<encrypted key N contents>"}],

 "aad":"<additional authenticated data contents>",
 "iv":"<initialization vector contents>",
 "ciphertext":"<ciphertext contents>",
 "tag":"<authentication tag contents>"
}

Of these members, only the “ciphertext” member MUST be present.

The “iv”, “tag”, and “encrypted_key” members MUST be present when corresponding JWE Initialization Vector, JWE Authentication Tag, and JWE Encrypted Key values are non-empty.

The “recipients” member MUST be present when any “header” or “encrypted_key” members are needed for recipients. At least one of the “header”, “protected”, and “unprotected” members MUST be present so that “alg” and “enc” header parameter values are conveyed for each recipient computation.

The contents of the Encoded JWE Encrypted Key, Encoded JWE Initialization Vector, Encoded JWE Ciphertext, and Encoded JWE Authentication Tag values are exactly as defined in the rest of this specification. They are interpreted and validated in the same manner, with each corresponding Encoded JWE Encrypted Key, Encoded JWE Initialization Vector, Encoded JWE Ciphertext, Encoded JWE Authentication Tag, and set of header parameter values being created and validated together. The JWE Header values used are the union of the header parameters in the “protected”, “unprotected”, and corresponding “header” members, as described earlier.

Each JWE Encrypted Key value is computed using the parameters of the corresponding JWE Header value in the same manner as for the JWE Compact Serialization. This has the desirable property that each Encoded JWE Encrypted Key value in the “recipients” array is identical to the value that would have been computed for the same parameter in the JWE Compact Serialization. Likewise, the JWE Ciphertext and JWE Authentication Tag values match those produced for the JWE Compact Serialization, provided that the Encoded JWE Header value (which represents the integrity-protected header parameter values) matches that used in the JWE Compact Serialization.

All recipients use the same JWE Protected Header, JWE Initialization Vector, JWE Ciphertext, and JWE Authentication Tag values, resulting in potentially significant space savings if the message is large. Therefore, all header parameters that specify the treatment of the Plaintext value MUST be the same for all recipients. This primarily means that the “enc” (encryption method) header parameter value in the JWE Header for each recipient and any parameters of that algorithm MUST be the same.

See Appendix A.4 for an example of computing a JWE using the JWE JSON Serialization.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-7.2 )

8. Composition

This document does not specify a combination signed and encrypted mode.

However, because the contents of a message can be arbitrary, encryption and data origin authentication can be provided by recursively encapsulating multiple JWE and JWS messages.

In general, senders SHOULD sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer.

(draft 02)

9. References

( http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-9 )

9.1. Normative References

[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)”, draft-ietf-jose-json-web-algorithms (work in progress), December 2012.
[JWK]
Jones, M., “JSON Web Key (JWK)”, draft-ietf-jose-json-web-key (work in progress), December 2012.
[JWS]
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS)”, draft-ietf-jose-json-web-signature (work in progress), December 2012.
[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 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 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 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 Requirements for Security”, BCP 106, RFC 4086, June 2005.
[RFC4288]
Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 4288, December 2005.
[RFC4627]
Crockford, D., “The application/json Media Type for 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., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, May 2008.
[W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, “XML Encryption Syntax and Processing Version 1.1”, World Wide Web Consortium CR CR-xmlenc-core1-20120313, March 2012, <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-9.1 )

9.2. Informative References

[I-D.rescorla-jsms]
Rescorla, E. and J. Hildebrand, “JavaScript Message Security Format”, draft-rescorla-jsms-00 (work in progress), March 2011.
[JSE]
Bradley, J. and N. Sakimura (editor), “JSON Simple Encryption”, September 2010.
[JWE-JS]
Jones, M., “JSON Web Encryption JSON Serialization (JWE-JS)”, draft-jones-jose-jwe-json-serialization (work in progress), December 2012.
[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, RFC 5652, September 2009.

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-9.2 )

13. References

13.1. Normative References

[FIPS-197]
National Institute of Standards and Technology (NIST), “Advanced Encryption Standard (AES)”, FIPS PUB 197, November 2001.
[JWK]
Jones, M., “JSON Web Key (JWK)”, October 2011.
[JWS]
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS)”, October 2011.
[NIST-800-38A]
National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation”, NIST PUB 800-38A, December 2001.
[NIST-800-38D]
National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC”, NIST PUB 800-38D, December 2001.
[NIST-800-56A]
National Institute of Standards and Technology (NIST), “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)”, NIST PUB 800-56A, March 2007.
[RFC1421]
Linn, J., “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures”, RFC 1421, February 1993.
[RFC1738]
Berners-Lee, T., Masinter, L., and M. McCahill, “Uniform Resource Locators (URL)”, RFC 1738, December 1994.
[RFC1952]
Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, “GZIP file format specification version 4.3”, RFC 1952, May 1996.
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2818]
Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
[RFC3394]
Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm”, RFC 3394, September 2002.
[RFC3447]
Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”, RFC 3447, February 2003.
[RFC3629]
Yergeau, F., “UTF-8, a transformation format of ISO 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 Requirements for Security”, BCP 106, RFC 4086, June 2005.
[RFC4627]
Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON)”, RFC 4627, July 2006.
[RFC4648]
Josefsson, S., “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, October 2006.
[RFC5226]
Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[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., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, May 2008.
[RFC5785]
Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs)”, RFC 5785, April 2010.
[RFC6090]
McGrew, D., Igoe, K., and M. Salter, “Fundamental Elliptic Curve Cryptography Algorithms”, RFC 6090, February 2011.
[RFC6125]
Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)”, RFC 6125, March 2011.

13.2. Informative References

[I-D.rescorla-jsms]
Rescorla, E. and J. Hildebrand, “JavaScript Message Security Format”, draft-rescorla-jsms-00 (work in progress), March 2011.
[JCA]
Oracle, “Java Cryptography Architecture”, 2011.
[JSS]
Bradley, J. and N. Sakimura (editor), “JSON Simple Sign”, September 2010.
[JWT]
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token (JWT)”, October 2011. (JSON Web Token(JWT))
[RFC3275]
Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing”, RFC 3275, March 2002.
[RFC5652]
Housley, R., “Cryptographic Message Syntax (CMS)”, STD 70, RFC 5652, September 2009.
[W3C.CR-xmlenc-core1-20110303]
Hirsch, F., Reagle, J., Eastlake, D., and T. Roessler, “XML Encryption Syntax and Processing Version 1.1”, World Wide Web Consortium CR CR-xmlenc-core1-20110303, March 2011, <http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing”, World Wide Web Consortium Recommendation REC- xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.

Appendix A. JWE Examples

This section provides examples of JWE computations.

A.1. Example JWE using RSAES OAEP and AES GCM

This example encrypts the plaintext “Live long and prosper.” to the recipient using RSAES OAEP and AES GCM.

The AES GCM algorithm has an integrated integrity check.

The representation of this plaintext is:

[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1 )

A.1.1. JWE Header

The following example JWE Header declares that:

{"alg":"RSA-OAEP","enc":"A256GCM"}

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.1 )

A.1.2. Encoded JWE Header

Base64url encoding the bytes of the UTF-8 representation of the JWE Header yields this Encoded JWE Header value:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.2 )

A.1.3. Content Master Key (CMK)

Generate a 256 bit random Content Master Key (CMK).

In this example, the value is:

[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,
234, 64, 252]

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.3)

A.1.4. Key Encryption

Encrypt the CMK with the recipient’s public key using the RSAES OAEP algorithm to produce the JWE Encrypted Key.

In this example, the RSA key parameters are:

Parameter Name Value
Modulus [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, 135, 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5, 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161, 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140, 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210, 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102, 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227, 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196, 17, 146, 10, 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233, 210, 101, 236, 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, 111, 234, 71, 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89, 244, 254, 107, 84, 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46, 151, 174, 12, 103, 197, 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, 24, 47, 133, 8, 199, 235, 107, 126, 130, 246, 73, 195, 20, 108, 202, 176, 214, 187, 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37, 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, 36, 10, 230, 248, 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, 27]
Exponent [1, 0, 1]
Private Exponent [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66, 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92, 119, 136, 251, 41, 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228, 213, 149, 228, 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, 231, 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, 211, 245, 250, 112, 71, 243, 61, 129, 95, 39, 244, 122, 225, 217, 169, 211, 165, 48, 253, 220, 59, 122, 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187, 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64, 194, 121, 182, 95, 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106, 143, 121, 27, 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112, 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, 157, 184, 154, 131, 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133, 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38, 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126, 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171, 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7, 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201]

The resulting JWE Encrypted Key value is:

[51, 101, 241, 165, 179, 145, 41, 236, 202, 75, 60, 208, 47, 255,
121, 248, 104, 226, 185, 212, 65, 78, 169, 255, 162, 100, 188, 207,
220, 96, 161, 22, 251, 47, 66, 112, 229, 75, 4, 111, 25, 173, 200,
121, 246, 79, 189, 102, 173, 146, 228, 142, 14, 12, 167, 200, 27,
133, 138, 37, 180, 249, 4, 56, 123, 192, 162, 156, 246, 231, 235,
217, 240, 45, 158, 213, 195, 154, 2, 142, 86, 61, 198, 210, 34, 225,
92, 7, 128, 227, 4, 227, 55, 183, 69, 0, 59, 162, 71, 145, 98, 238,
0, 70, 40, 123, 159, 37, 115, 18, 16, 157, 236, 138, 117, 166, 18,
45, 181, 125, 112, 170, 168, 82, 129, 80, 166, 242, 150, 97, 17, 217,
109, 251, 51, 35, 39, 236, 107, 95, 43, 154, 4, 227, 206, 187, 75,
13, 51, 231, 115, 79, 67, 72, 145, 54, 225, 164, 60, 195, 120, 188,
69, 113, 3, 182, 21, 189, 79, 82, 122, 46, 196, 199, 254, 252, 7,
119, 5, 32, 144, 143, 173, 11, 99, 205, 120, 106, 231, 51, 231, 77,
73, 252, 197, 221, 142, 254, 151, 7, 6, 203, 65, 108, 117, 121, 15,
95, 43, 111, 13, 94, 242, 226, 150, 94, 121, 72, 144, 251, 69, 93,
137, 178, 13, 216, 8, 227, 125, 110, 180, 157, 250, 207, 184, 232,
222, 164, 193, 70, 232, 16, 65, 109, 29, 251, 164, 119, 50, 205, 236,
109, 245, 234, 78, 1]

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.4 )

A.1.5. Encoded JWE Encrypted Key

Base64url encode the JWE Encrypted Key to produce the Encoded JWE Encrypted Key.

This result (with line breaks for display purposes only) is:

M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m
rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA
O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj
zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN
SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG
6BBBbR37pHcyzext9epOAQ

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.5 )

A.1.6. Initialization Vector

Generate a random 96 bit JWE Initialization Vector.

In this example, the value is:

[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]

Base64url encoding this value yields the Encoded JWE Initialization Vector value:

48V1_ALb6US04U3b

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.5 )

A.1.7. “Additional Authenticated Data” Parameter

Concatenate the Encoded JWE Header value, a period character (‘.’), the Encoded JWE Encrypted Key, a second period character (‘.’), and the Encoded JWE Initialization Vector to create the “additional authenticated data” parameter for the AES GCM algorithm.

This result (with line breaks for display purposes only) is:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m
rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA
O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj
zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN
SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG
6BBBbR37pHcyzext9epOAQ.
48V1_ALb6US04U3b

The representation of this value is:

[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,
54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81, 46,
77, 50, 88, 120, 112, 98, 79, 82, 75, 101, 122, 75, 83, 122, 122, 81,
76, 95, 57, 53, 45, 71, 106, 105, 117, 100, 82, 66, 84, 113, 110, 95,
111, 109, 83, 56, 122, 57, 120, 103, 111, 82, 98, 55, 76, 48, 74,
119, 53, 85, 115, 69, 98, 120, 109, 116, 121, 72, 110, 50, 84, 55,
49, 109, 114, 90, 76, 107, 106, 103, 52, 77, 112, 56, 103, 98, 104,
89, 111, 108, 116, 80, 107, 69, 79, 72, 118, 65, 111, 112, 122, 50,
53, 45, 118, 90, 56, 67, 50, 101, 49, 99, 79, 97, 65, 111, 53, 87,
80, 99, 98, 83, 73, 117, 70, 99, 66, 52, 68, 106, 66, 79, 77, 51,
116, 48, 85, 65, 79, 54, 74, 72, 107, 87, 76, 117, 65, 69, 89, 111,
101, 53, 56, 108, 99, 120, 73, 81, 110, 101, 121, 75, 100, 97, 89,
83, 76, 98, 86, 57, 99, 75, 113, 111, 85, 111, 70, 81, 112, 118, 75,
87, 89, 82, 72, 90, 98, 102, 115, 122, 73, 121, 102, 115, 97, 49, 56,
114, 109, 103, 84, 106, 122, 114, 116, 76, 68, 84, 80, 110, 99, 48,
57, 68, 83, 74, 69, 50, 52, 97, 81, 56, 119, 51, 105, 56, 82, 88, 69,
68, 116, 104, 87, 57, 84, 49, 74, 54, 76, 115, 84, 72, 95, 118, 119,
72, 100, 119, 85, 103, 107, 73, 45, 116, 67, 50, 80, 78, 101, 71,
114, 110, 77, 45, 100, 78, 83, 102, 122, 70, 51, 89, 55, 45, 108,
119, 99, 71, 121, 48, 70, 115, 100, 88, 107, 80, 88, 121, 116, 118,
68, 86, 55, 121, 52, 112, 90, 101, 101, 85, 105, 81, 45, 48, 86, 100,
105, 98, 73, 78, 50, 65, 106, 106, 102, 87, 54, 48, 110, 102, 114,
80, 117, 79, 106, 101, 112, 77, 70, 71, 54, 66, 66, 66, 98, 82, 51,
55, 112, 72, 99, 121, 122, 101, 120, 116, 57, 101, 112, 79, 65, 81,
46, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85, 83, 48, 52, 85, 51, 98]

( draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.7 )

A.1.8. Plaintext Encryption

Encrypt the Plaintext with AES GCM using the CMK as the encryption key, the JWE Initialization Vector, and the “additional authenticated data” value above, requesting a 128 bit “authentication tag” output.

The resulting Ciphertext is:

[253, 237, 181, 180, 97, 161, 105, 207, 233, 120, 65, 100, 45, 122,
246, 116, 195, 212, 102, 37, 36, 175]

The resulting “authentication tag” value is:

[237, 94, 89, 14, 74, 52, 191, 249, 159, 216, 240, 28, 224, 147, 34,
82]

(draft08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.8)

A.1.9. Encoded JWE Ciphertext

Note

AES GCM encrypt function will produce:

  • Ciphertext
  • authentication tag

Base64url encode the resulting Ciphertext to create the Encoded JWE Ciphertext.

This result is:

_e21tGGhac_peEFkLXr2dMPUZiUkrw

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.9 )

A.1.10. Encoded JWE Integrity Value

Base64url encode the resulting “authentication tag” to create the Encoded JWE Integrity Value.

This result is:

7V5ZDko0v_mf2PAc4JMiUg

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.10 )

A.1.11. Complete Representation

Assemble the final representation: The Compact Serialization of this result is 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 Integrity Value in that order, with the five strings being separated by four period (‘.’) characters.

The final result in this example (with line breaks for display purposes only) is:

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
M2XxpbORKezKSzzQL_95-GjiudRBTqn_omS8z9xgoRb7L0Jw5UsEbxmtyHn2T71m
rZLkjg4Mp8gbhYoltPkEOHvAopz25-vZ8C2e1cOaAo5WPcbSIuFcB4DjBOM3t0UA
O6JHkWLuAEYoe58lcxIQneyKdaYSLbV9cKqoUoFQpvKWYRHZbfszIyfsa18rmgTj
zrtLDTPnc09DSJE24aQ8w3i8RXEDthW9T1J6LsTH_vwHdwUgkI-tC2PNeGrnM-dN
SfzF3Y7-lwcGy0FsdXkPXytvDV7y4pZeeUiQ-0VdibIN2AjjfW60nfrPuOjepMFG
6BBBbR37pHcyzext9epOAQ.
48V1_ALb6US04U3b.
_e21tGGhac_peEFkLXr2dMPUZiUkrw.
7V5ZDko0v_mf2PAc4JMiUg

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.11 )

A.1.12. Validation

This example illustrates the process of creating a JWE with an Authenticated Encryption algorithm.

These results can be used to validate JWE decryption implementations for these algorithms. Note that since the RSAES OAEP computation includes random values, the encryption results above will not be completely reproducible.

However, since the AES GCM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.

(draft 08, http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-A.1.12 )

A.2. Example JWE using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256

This example encrypts the plaintext “Live long and prosper.” to the recipient using RSAES-PKCS1-V1_5 for key encryption and AES_128_CBC_HMAC_SHA_256 for content encryption. The representation of this plaintext is:

[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2 )

A.2.1. JWE Header

The following example JWE Header (with line breaks for display purposes only) declares that:

  • the Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
  • the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext.
{"alg":"RSA1_5","enc":"A128CBC-HS256"}

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.1 )

Note

  • CEK は RSA AES PKCS1 V.1.5 で非対称暗号化されて JEK となる
  • Plaintextは AES_128_CBC_HMAC_SHA_256 でCEKを使った共有鍵暗号化で Ciphertextとなる

A.2.2. Encoded JWE Header

Base64url encoding the octets of the UTF-8 representation of the JWE Header yields this Encoded JWE Header value:

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.2 )

Note

  • JWE Header JSONのオクテットストリングをBase64URL化 -> EJH

A.2.3. Content Encryption Key (CEK)

Generate a 256 bit random Content Encryption Key (CEK). In this example, the key value is:

[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,
44, 207]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.3 )

Note

  • CEK を32オクテット乱数で生成

A.2.4. Key Encryption

Encrypt the CEK with the recipient’s public key using the RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key.

Note

  • 相手の公開鍵を使ってCEKを非対称暗号化
  • RSA AES PKCS1 v.1.5

This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks for display purposes only):

{"kty":"RSA",
 "n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl
      UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre
      cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_
      7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI
      Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU
      7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw",
 "e":"AQAB",
 "d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq
      1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry
      nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_
      0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj
      -VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj
      T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ"
}

The resulting JWE Encrypted Key value is:

[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151,
176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181,
156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156,
116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223,
226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66,
212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253,
215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128,
66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199,
54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151,
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,
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,
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,
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,
146, 114, 165, 204, 71, 136, 41, 252]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.4 )

A.2.5. Encoded JWE Encrypted Key

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
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.5 )

Note

  • 非対称暗合化で生成された JEK を Base64URLして EJEK

A.2.6. Initialization Vector

Note

  • 初期化ベクタは 16 オクテットランダムで作ってみる

Generate a random 128 bit JWE Initialization Vector. In this example, the value is:

[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]

Base64url encoding this value yields this Encoded JWE Initialization Vector value:

AxY8DCtDaGlsbGljb3RoZQ

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.6 )

A.2.7. Additional Authenticated Data

Let the Additional Authenticated Data encryption parameter be the octets of the ASCII representation of the Encoded JWE Header value. This AAD value is:

[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,
74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85,
50, 73, 110, 48]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.7 )

A.2.8. Plaintext Encryption

Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from Appendix A.3 are detailed in Appendix B. The resulting Ciphertext is:

[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,
112, 56, 102]

The resulting Authentication Tag value is:

[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100,
191]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-A.2.8 )

Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation

This example shows the steps in the AES_128_CBC_HMAC_SHA_256 authenticated encryption computation using the values from the example in Appendix A.3.

As described where this algorithm is defined in Sections 4.8 and 4.8.3 of JWA, the AES_CBC_HMAC_SHA2 family of algorithms are implemented using Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode with PKCS #5 padding to perform the encryption and an HMAC SHA-2 function to perform the integrity calculation - in this case, HMAC SHA-256.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B )

B.1. Extract MAC_KEY and ENC_KEY from Key

The 256 bit AES_128_CBC_HMAC_SHA_256 key K used in this example is:

[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,
44, 207]

Use the first 128 bits of this key as the HMAC SHA-256 key MAC_KEY, which is:

[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206]

Use the last 128 bits of this key as the AES CBC key ENC_KEY, which is:

[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44,
207]

Note that the MAC key comes before the encryption key in the input key K; this is in the opposite order of the algorithm names in the identifiers “AES_128_CBC_HMAC_SHA_256” and “A128CBC-HS256”.

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.1 )

B.2. Encrypt Plaintext to Create Ciphertext

Encrypt the Plaintext with AES in Cipher Block Chaining (CBC) mode using PKCS #5 padding using the ENC_KEY above. The Plaintext in this example is:

[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]

The encryption result is as follows, which is the Ciphertext output:

[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,
112, 56, 102]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.2 )

B.3. 64 Bit Big Endian Representation of AAD Length

The Additional Authenticated Data (AAD) in this example is:

[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,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]

This AAD is 51 bytes long, which is 408 bits long. The octet string AL, which is the number of bits in AAD expressed as a big endian 64 bit unsigned integer is:

[0, 0, 0, 0, 0, 0, 1, 152]

Note

  • AADのビット数です。オクテット数ではありません。

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.3 )

B.4. Initialization Vector Value

The Initialization Vector value used in this example is:

[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.4 )

B.5. Create Input to HMAC Computation

Concatenate the AAD, the Initialization Vector, the Ciphertext, and the AL value. The result of this concatenation is:

[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,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111,
116, 104, 101, 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, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.5 )

B.6. Compute HMAC Value

Compute the HMAC SHA-256 of the concatenated value above. This result M is:

[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105,
86, 229, 116]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.6 )

B.7. Truncate HMAC Value to Create Authentication Tag

Use the first half (128 bits) of the HMAC output M as the Authentication Tag output T. This truncated value is:

[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]

( https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#appendix-B.7 )

«  Holder-of-Key JSON Web Signature (JWS)   ::   Contents   ::   JSON Web Key (JWK)  »