Fair enough you did express your preference for the extra dot format at the time as being closer to the JSON format.
Others preferred not adding an extra segment and keeping the existing compact format. John B. On 2013-05-08, at 8:46 AM, Richard Barnes <[email protected]> wrote: > 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
