JSON Token Encryption Spec Results at IIW on Wednesday

We held a session on encryption for JSON Web Tokens at IIW on Wednesday, 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:

• 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/
• Defective Sign and Encrypt analysis: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.PDF
• 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:

• 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?

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”.

• Data format and how data formats affect streaming operations

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.

• Order of signing and encryption 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.

• Compress before encrypt?

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.

• What are we encrypting (payload or payload + signature)?

This was another area were the participants felt that we should reuse existing practice that has already been vetted by experts.

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.