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
