This document specifies a container formatted in JSON [RFC7159] for holding encrypted binary data, coined JEF (JSON Encryption Format).JEF was derived from IETF's JWE [RFC7516] specification and supports a subset of the same algorithms [RFC7518]. Public keys are represented as JWK [RFC7517] objects while the encryption container itself utilizes a notation similar to JCS [JCS] in order to maintain a consistent "style" in applications using encryption and signatures, including providing header information in plain text.The JEF encryption scheme is fully compatible with the ES6 [ES6] JSON/JavaScript serialization and parsing specification.

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.

Prerequisite: A JSON object in accordance with [RFC7159] containing properly formatted JEF data.Parsing restrictions:

• The original property serialization order must be preserved.
• There must not be any not here defined properties inside of a JEF object.

Since JEF uses the same algorithms as JWE [RFC7516] the JWA [RFC7518] reference apply with one important exception: Additional Authenticated Data used by the symmetric ciphers. This difference is due to the way encryption meta-data is formatted. The process for creating Additional Authenticated Data is as follows:

• The top level properties tag and ciphertext (including leading or trailing ',' characters) must be deleted from the JEF object.
• Whitespace must be removed which in practical terms means removal of all characters outside of quoted strings having a value of x09, x0a, x0d or x20.
• Now the JEF object must be recreated using the actual text left after applying the previous measures.

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 encryption algorithm.

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:ECDH encryption object requiring the same private key as in the sample object while providing the public key information in line, instead of using a kid: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 through an external certificate path:ECDH encryption object requiring the same private key as in the sample object while providing the key information through an external public key:JWK [RFC7517] key set associated with the preceeding encryption object: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 crit 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: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 kid, nor a jwk 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:Multiple recipient encryption object requiring the same private keys as in the previous examples as well as using a global alg property: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 .