[Openid-specs-ab] [OAUTH-WG] JSON Token encryption spec results at IIW on Wednesday

Nat Sakimura sakimura at gmail.com
Tue Nov 9 07:38:20 UTC 2010


Thanks Mike,

Looking forward to the updated version of the spec.
Once I get it, I will update the relevant part of AB spec and CX spec.

=nat

On Tue, Nov 9, 2010 at 8:07 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 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:
>
> ·         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.
>
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en


More information about the Openid-specs-ab mailing list