This document specifies a container formatted in JSON [RFC8259] for holding encrypted binary data, coined JEF (JSON Encryption Format).JEF is loosely derived from IETF's JWE [RFC7516] specification and supports the same JWA [RFC7518] and RFC8037 [RFC8037] encryption algorithms. Public keys are represented as JWK [RFC7517] objects while the encryption container itself utilizes a notation similar to the JSON Signature Format [JSF] in order to maintain a consistent "style" in applications using encryption and signatures, including providing header information in plain text. The latter was the primary motivation for creating an alternative to JWE.

The following sample object is used to visualize the JEF specification:The sample object can be decrypted by using the EC private key defined in Test Vectors.

JEF containers always start with a top-level JSON object.

JSON objects are described as tables with associated properties. When a property holds a JSON object this is denoted by a link to the actual definition. Properties may either be mandatory (M) or optional (O) as defined in the "Req" column.Array properties are identified by [ ] x-y where the range expression represents the valid number of array elements. In some JSON objects there is a choice from a set of mutually exclusive alternatives.
This is manifested in object tables like the following:

Property selection 1	Type selection 1	Req	Comment selection 1
Property selection 2	Type selection 2		Comment selection 2

The table below shows how the data types used by this specification are mapped into native JSON types:

Note that "Type" refers to the element type for arrays.

The following tables describe the JEF JSON structures in detail.

JEF implementors are presumed to be familiar with JWE [RFC7516].Prerequisite: A JSON object in accordance with [RFC8259] containing properly formatted JEF data.Note that there must not be any not here defined properties inside of a JEF object and that the use of JCS [RFC8785] implies certain constraints on the JSON data.Since JEF uses the same algorithms as JWE, the JWA [RFC7518] reference apply with one important exception: the Additional Authenticated Data used by the symmetric ciphers. This difference is due to the way encryption meta data is formatted. For recreating the Additional Authenticated Data the following steps must be performed:

1. Delete the top level properties "iv", "tag" and "cipherText" from the JEF object.
2. Retrieve the Additional Authenticated Data by running the JCS [RFC8785] canonicalization method over the remaining JEF object.

Applied on the Sample Object, a conforming JEF Additional Authenticated Data process should return the following JSON string:Note that the output string was folded for improving readability. The Additional Authenticated Data string is subsequently UTF-8 encoded before being applied to the decryption algorithm.

Encryption is analogous to decryption but requires adding the "iv", "tag" and "cipherText" properties after the creation of the Additional Authenticated Data.

This specification does (to the author's knowledge), not introduce additional vulnerabilities over what is specified for JWE [RFC7516].

This section holds test data which can be used to verify the correctness of a JEF implementation.All encryption tests encrypt the string below (after first having converted it to UTF-8):The Sample Object (available in file p256#ecdh-es+a128kw@a128gcm@kid.json), can be decrypted by the following EC private key, here expressed in the JWK [RFC7517] format:ECDH encryption object requiring the same private key as in the sample object while using a different set of algorithms both for key encryption and content encryption. The public key is specified through a keyId:ECDH encryption object requiring the same private key as in the sample object while providing the public key information in line:ECDH encryption object requiring the same private key as in the sample object but assuming it is known through the context:ECDH encryption object requiring the same private key as in the sample object while providing the key information through an in-line certificate path:ECDH encryption object requiring the same private key as in the sample object while providing the key information in line. In addition, this object declares extensions:EC private key for decrypting the subsequent object:ECDH encryption object requiring the private key above:EC private key for decrypting the subsequent object:ECDH encryption object requiring the private key above:ECDH private key for decrypting the subsequent object:ECDH encryption object requiring the private key above:ECDH private key for decrypting the subsequent object:ECDH encryption object requiring the private key above:RSA private key for decrypting the subsequent object:RSA encryption object requiring the private key above:RSA encryption object requiring the same private key as in the previous example but relying on that this being implicitly known since the encryption object neither contains a keyId, nor a publicKey property:RSA encryption object requiring the same private key as in the previous example while using a different set of algorithms both for key encryption and content encryption:Multiple recipient encryption object requiring the same private keys as in the previous examples:AES key named "a128bitkey" here provided in hexadecimal notation:Encryption object requiring the key above for decryption:AES key named "a256bitkey" here provided in hexadecimal notation:Encryption object requiring the key above for decryption:AES key here provided in hexadecimal notation:Encryption object requiring the implicit key above for decryption:AES key named "a256bitkey" here provided in hexadecimal notation:Encryption object requiring the key above for decryption:AES key named "a512bitkey" here provided in hexadecimal notation:Encryption object requiring the key above for decryption:

JEF was developed by Anders Rundgren (anders.rundgren.net@gmail.com) as a part of the OpenKeyStore [OPENKEY] project .