Ok, in any case, I don't think there was any agreement/consensus at the f2f, mainly just "you could do X" or "Y". So I think that comments from the WG on their feelings about the two possibilities are still helpful.
FWIW, I prefer the "extra dot" version because it's a much cleaner map to JSON. --Richard On Wed, May 8, 2013 at 8:15 AM, Mike Jones <[email protected]>wrote: > John’s recollection matches mine. The discussion was very short because > no one went to bat for changing the Compact Serializations. (If anyone > had, I’m certain that it would have been a longer, much more memorable > discussion.)**** > > ** ** > > Keeping the Compact Serializations intact was a core element of the > compromise agreed to wherein we also allowed the possibility of > non-integrity-protected header values in the JSON Serializations.**** > > ** ** > > I believe that we’re in a good place now as a result, where full > generality is possible in the JSON Serializations with multiple > recipients/signatures and where the Compact Serializations remains simple – > with optimizations intentionally employed that are enabled by capitalizing > on the by-design constraint that that the Compact Serializations are > restricted to a single recipient/signature.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* John Bradley [mailto:[email protected]] > *Sent:* Tuesday, May 07, 2013 8:22 PM > *To:* Richard Barnes > *Cc:* Mike Jones; [email protected] > *Subject:* Re: [jose] Selective header protection**** > > ** ** > > I remember standing at the white board and discussing it. People agreed > that we would put all the headers in a single protected JAON object. You > commented that that would work and be comparable with the existing compact > format, but we could add another dot separated segment if we wanted to have > unprotected headers. **** > > ** ** > > It was discussed. You disagreed and prefers the additional segment. **** > > ** ** > > John B. > > Sent from my iPhone**** > > > On 2013-05-07, at 7:18 PM, Richard Barnes <[email protected]> wrote:**** > > As I recall, there was no discussion of compact formats at the interim, > so both alternatives are available for comment. In both cases, all > top-level header fields are integrity-protected. **** > > > > On Tuesday, May 7, 2013, Mike Jones wrote:**** > > For context, I believe that the participants in the interim meeting had > agreed that for the compact serializations (which only support a single > recipient or signature), for simplicity reasons, we will continue to > require that all header fields be integrity protected. This means that the > dot-separated fields for JWS and JWE remain as they are. Yes, we’d > discussed possibly adding more dot-separated fields as a hypothetical > exercise, but decided not to do so for the single-recipient compact > serialization case.**** > > **** > > Other than recording the hypothetical discussion about possible adding > more fields to the compact serializations, and the > “JWE-PROPOSED-SUPER-SIMPLE” example, which was not discussed at the interim > meeting, “I believe that Richard’s note below accurately reflects the > discussions on this topic during the interim working group meeting.**** > > **** > > FYI, I’ll also forward a note I wrote that independently recorded these > decisions, which had previously been sent to the interim meeting > participants.**** > > **** > > -- Mike**** > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Tuesday, May 07, 2013 2:08 AM > *To:* [email protected] > *Subject:* [jose] Selective header protection**** > > **** > > Dear JOSE WG,**** > > **** > > [This will be better covered by the chair's minutes from the interim, but > I wanted to go ahead and post a summary so that related key wrapping > discussion can happen.]**** > > **** > > One of the topics discussed at the JOSE interim was how to deal with > header integrity for multiple recipients. There was agreement in the room > to proceed with a strategy of removing some header parameters from > integrity protection -- especially per-recipient parameters.**** > > **** > > At a high-level, the change to the syntax is as follows:**** > > -- For JWE, header parameters may be included at the top level of a JWE-JS > or within the "recipients" objects**** > > -- Unprotected parameters are expressed as a JSON dictionary under the > "header" parameter**** > > -- Protected parameters are base64-encoded and included under the > "protected" parameter**** > > **** > > Thus, for example, a JWE might have the following form:**** > > {**** > > "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",**** > > "recipients": [{**** > > "header": { "alg": "A128KW", "kid": "42" },**** > > "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"**** > > }],**** > > "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",**** > > "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",**** > > "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"**** > > }**** > > **** > > A complete set of examples is included below. Comments welcome!**** > > **** > > One area where comments would be especially helpful is the compact > serialization. In the examples below, there are two proposed compact > serializations based on the new format. Variant 1 maps "global" parameters > and "recipient" parameters to separate base64url-encoded parts. Variant 2 > combines them into a single dictionary. On the one hand, Variant 1 maps > more simply to the JSON format; on the other hand, Variant 2 keeps the same > number of components as the current compact serialization.**** > > **** > > Thanks,**** > > --Richard**** > > **** > > **** > > // Examples:**** > > // 1. Current JWE-JS format**** > > // 2. Proposed JWE-JS format**** > > // 3. Simple example of proposed JWE-JS format**** > > // 4. Current JWS-JS format**** > > // 5. Proposed JWS-JS format**** > > // 6. Proposed JWE-compact format (variant 1)**** > > // 7. Proposed JWE-compact format (variant 2)**** > > **** > > **** > > // JWE-CURRENT**** > > // header = base64({"alg":"A128KW","enc":"A128GCM","kid":"42"})**** > > {**** > > "recipients": [{**** > > "header": > "eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiNDIifQo",**** > > "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"**** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose**** > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
