JSON Token Spec - Encryption

JSON Token Spec Work Encryption

Location:Wednesday 4E

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Convener: Mike Jones

Notes-taker(s): Mike Jones

We held a session on encryption for JSON Web Tokens at IIW (Wednesday after lunch in space E), building upon the results from the JSON Tokens and No Base String sessions on Tuesday. Once again, substantial consensus emerged, which is described in the notes below.

These consensus decisions were in place by the start of the session:
 * Some use cases for JSON tokens require encryption
 * (plus all the decisions from the sessions on Tuesday)

It was agreed that these sets of high-level goals need to be achievable by application of signing and/or encryption:
 * Integrity
 * Confidentiality + Integrity
 * Non-Repudiation (which also implies Integrity)
 * Non-Repudiation + Confidentiality

Open issues identified at the start of the session were:
 * Should encryption and signing be accomplished via (1) separate but composable encryption and signing operations, (2) use of a small set of recommended composite operations that achieve the high-level goals, or (3) allowing for both possibilities?
 * Data format and how data formats affect streaming operations
 * Order of signing and encryption operations
 * Compress before encrypt?
 * What are we encrypting (payload or payload + signature)?

The primary consensus in the room was to invent as little as possible by reusing work that other experts have done in the space, while adapting their work to a JSON context. Participants provided the following references to work to borrow from: Defective Sign and Encrypt analysis:  http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.PDF
 * Cryptographic Message Syntax (CMS):  http://tools.ietf.org/html/rfc5652
 * Table of Algorithm Suites from WS-SecurityPolicy 1.2, section 6.1: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826547
 * XML Signature Syntax and Processing (Second Edition):  http://www.w3.org/TR/xmldsig-core/
 * XML Encryption Syntax and Processing:  http://www.w3.org/TR/xmlenc-core/
 * The TLS Protocol Version 1.0:  http://tools.ietf.org/html/rfc2246
 * Transport Layer Security Protocol Compression Methods:  http://tools.ietf.org/html/rfc3749
 * Compressed Data Content Type for Cryptographic Message Syntax (CMS):  http://tools.ietf.org/html/rfc3274
 * DEFLATE Compressed Data Format Specification version 1.3:  http://tools.ietf.org/html/rfc1951

Specific issues were resolved as follows:

The consensus was for (3) – that we should specify a small set of composite operations that will meet the needs of common use cases, while also enabling applications to compose encryption and signing operations in a general fashion, should the composite operations prove insufficient for their use cases. A subset of the composite algorithm suites in WS-SecurityPolicy 1.2 was suggested as an appropriate starting point. Paul Tarjan of Facebook had also suggested during the OpenID Summit on Monday that descriptive composite algorithm values be used, such as “AES-256-CBC HMAC-SHA-256”.
 * Should encryption and signing be accomplished via (1) separate but composable encryption and signing operations, (2) use of a small set of recommended composite operations that achieve the high-level goals, or (3) allowing for both possibilities?

For the same reasons as discussed during the signing session, the group reaffirmed that the order of the fields should be envelope.payload.signature, with the envelope containing sufficient information to determine the nature of the contents of the remaining fields. This order enables streaming operations, where content is created or analyzed in parallel with its transmission or reception, to the maximum extent possible, and also potentially minimizes buffering requirements imposed upon implementations.
 * Data format and how data formats affect streaming operations

It was recognized that no one-size-fits-all solution applies here and that different sets of operations are needed for different use cases. For instance, if non-repudiation is required, a signature of the plan text using public key cryptography must be present, which therefore must precede any other operations. Again, the group reaffirmed that we should reuse other work in this area to the extent possible.
 * Order of signing and encryption operations

Several participants pointed out existing practice in this area, including the use of the DEFLATE compression algorithm prior to encryption by TLS and CMS. It was agreed that we should similarly document how to optionally perform compression before encryption for those use cases where it makes sense.
 * Compress before encrypt?

This was another area were the participants felt that we should reuse existing practice that has already been vetted by experts.
 * What are we encrypting (payload or payload + signature)?

Special thanks go to Breno de Medeiros, whose crypto expertise was invaluable during this session, as well as Brad Hill, Diana Smetters and several other Googlers, John Bradley, Nat Sakimura, Joseph Holsten, Thomas Hardjono, Terry Hayes, Dick Hardt, Tony Nadalin, and others who contributed to this productive session.