Subject: [jose] FW: Draft write-up of discussion on JSON Serialization with some non-protected fields

From: Mike Jones <[email-masked]>
Date: Tue, 7 May 2013 22:25:09 +0000

FYI, this note had previously been sent to the JOSE interim working group meeting participants.  It discusses the correspondences between the agreed-upon JSON Serialization and Compact Serialization formats and how to transform one into the other.

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, May 01, 2013 12:37 PM
To: Jim Schaad; John Bradley; Richard Barnes
Cc: Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: RE: Draft write-up of discussion on JSON Serialization with some non-protected fields

A transformation from JWS and JWE objects using the compact serializations to ones using the JSON Serialization is always possible as simple syntactic transformation.  The transformation from the compact JWS "hdr.msg.sig" into a JSON-serialized JWS is:

  {"protected":"hdr",
   "signatures":[{"signature":"sig"}],
   "payload":"msg"
  }

The transformation from the compact JWE "hdr.ekey.iv.ct.tag" into a JSON-serialized JWE is:

  {"protected":"hdr",
   "recipients":[{"encrypted_key":"ekey"}],
   "initialization_vector":"iv",
   "ciphertext":"ct",
   "authentication_tag":"tag"
  }

Transformations from JSON Serializations for single recipients into the Compact Serializations are always possible.  When the "header" fields (containing unprotected header parameter values) aren't used, the transformation is purely syntactic - being the inverse of those above.

When "header" fields are used, the contents of their JSON objects are merged into the "protected" header object contents, with the resulting merged header contents being used as the header for the compact serializations.  For instance, this JWE:

  {"protected":"base64url("{"enc":"A128GCM"}")",
   "header":{"kid":"3"},
   "recipients":[
    {"header":{"alg":"A128KW"},
     "encrypted_key":"ekey"}],
   "initialization_vector":"iv",
   "ciphertext":"ct",
   "authentication_tag":"tag"
  }

Would use this header value in the compact serialization:

  base64url("{"enc":"A128GCM","kid":"3","alg":"A128KW"}")

The rest of the JSON serialization -> compact serialization is purely syntactic, and as above.

By design, a transformation from a multi-recipient JWE or multi-signature JWS to the compact serializations is not possible.

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, May 01, 2013 10:54 AM
To: John Bradley; Richard Barnes
Cc: Jim Schaad; Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: RE: Draft write-up of discussion on JSON Serialization with some non-protected fields

Yes, that was the agreement.  I can write up the transformation rules once my flight finished de-icing and is under way.

-- Mike
________________________________
From: John Bradley
Sent: 5/1/2013 11:50 AM
To: Richard Barnes
Cc: Jim Schaad; Mike Jones; Pete Resnick; Sean Turner; Matt Miller; Joe Hildebrand; Peter Saint-Andre; Brian Campbell; Karen O'Donoghue; Eric Rescorla; Hannes Tschofenig
Subject: Re: Draft write-up of discussion on JSON Serialization with some non-protected fields
For compact, I thought we agreed to put all the headers in the authenticated header segment and only send that.

Are you referring to having to merge the protected and unprotected headers?

John

Sent from my iPhone

On 2013-05-01, at 9:14 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
I started working on this last night.  It's not completely trivial, but it can be done.  I'll try to write it up on the plane on the way home.

On Wed, May 1, 2013 at 10:42 AM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
If you have a single recipient with protected data, I would like to see an example of this combined with the transformation logic to the compact case.

Can either of you provide this?

Jim
[SNIP]

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 8 May 2013 12:07:45 +1000

> A transformation from JWS and JWE objects using the compact serializations to ones using the JSON Serialization is always possible as simple syntactic transformation.

Great.
A "simple syntactic transformation" can’t work if "typ" has different values for the 2 serializations so "typ":"JWE-JS" should be dropped.

> {"protected":"base64url(“{"enc":"A128GCM"}”)",
>   "header":{"kid":"3"},
>   "recipients":[

From these examples it appears that the originator can arbitrarily decide which header fields are protected and which are not. For instance, the 3 header fields above ("enc":"A128GCM", "kid":"3", "alg":"A128KW") could be arranged in 8 different protected/unprotected combinations to create a valid JWE.

Yuck. This feels complex and dangerous. The 8 different combinations all have slightly different security properties. How are recipients supposed to choose which are safe to accept? If recipients only accept a subset we have major interoperability problems. If recipients MUST accept all combinations then I suspect we only get the security of the weakest combination (so there is very little value in allowing the others).

It would be much better to decide: AEAD details are protected; key exchange details are not protected (by the AEAD operation).

> By design, a transformation from a multi-recipient JWE or multi-signature JWS to the compact serializations is not possible.

A serialization that only supports the single-recipient (or single-signer) case might be acceptable (though not ideal) if it really simplifies this common case. However if JOSE defines a range of ways to create single-recipient messages (eg with all-protected, all-unprotected, or mixed-protection for header fields), then it is not acceptable for a JOSE serialization to only support 1 of these.
Either the messages JOSE defines are "safe" (fit-for-purpose) so serializations should support them, or such messages shouldn’t be defined at all.

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 8 May 2013 07:45:58 +0000

If you want to make the case that we need to specify that specific values need to be integrity protected in the JSON Serializations, providing justification for why they must be integrity protected, that would be a very useful contribution.  We could add those requirements to a future version of the JSON Serialization sections.  For the Compact Serialization, none of that reasoning is necessary or pertinent, since we decided to continue taking the conservative route of integrity protecting everything.

The "yuck" cases you cite only arise because the working group decided at the interim meeting to allow some unprotected headers for the JSON Serializations.  I agree that if we can clearly specify that some fields must be integrity protected, it will have the positive effect of reducing the set of unnecessary choices that would otherwise be available to implementers.

Do you have some idea of which header parameters must be integrity protected?  It sounds below like you do...

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Tuesday, May 07, 2013 7:08 PM
To: [email-masked]
Subject: Re: [jose] FW: Draft write-up of discussion on JSON Serialization with some non-protected fields

Great.

--
James Manger
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose