On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones <[email protected]> wrote:
> Thanks for your review, Richard. Responses are inline below... > > > -----Original Message----- > > From: jose [mailto:[email protected]] On Behalf Of Richard Barnes > > Sent: Wednesday, October 01, 2014 8:37 PM > > To: The IESG > > Cc: [email protected]; jose- > > [email protected]; [email protected] > > Subject: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-encryption- > > 33: (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-jose-json-web-encryption-33: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Overall, this document is in much more solid shape than when it began. > > Thanks to the WG for a lot of hard work. I only have one remaining > concern, > > that should hopefully be easy to address. > > > > Section 7.2. > > I've had several implementors trying to use JWE in the JSON > serialization ask > > why it was necessary to include a "recipients" array in cases where > there's only > > one recipient. It seems like this is going to be a major barrier to > deployment and > > re-use, so I would propose including the following text: > > """ > > In cases where the JWE is encrypted for only one recipient, the > "recipients" array > > will contain a single object. In such cases, the elements of the > "recipients" array > > MAY be included at the top level of the JWE object. If the generator of > a JWE > > chooses to use this representation then all unprotected header parameters > > MUST be carried in the "header" field, and the "unprotected" field MUST > be > > absent. A JSON-formatted JWE that contains a "recipients" field MUST NOT > > contain a "header" or "encrypted_key" field, and vice versa. > > """ > > This may also require some other changes where "recipients" is relied > on, e.g., in > > Section 9. > > My response to this parallels that to the similar DISCUSS about JWS. > > That said, I actually have marginally *more* concerns about this proposal > than the JWS one, because you're making an arbitrary choice between the > multi-recipient "unprotected" parameter and the per-recipient "header" > parameter, and dictating that one be used in preference to another in the > proposed case where "recipients" array is not present. This adds an > additional level of non-parallelism that isn't present in the JWS case. > > For those following along, here are the two mostly equivalent syntaxes > that implementations would have to support in Richard's proposal: > > {"protected":"<integrity-protected shared header contents>", > "unprotected":<non-integrity-protected shared header contents>, > "recipients":[ > {"header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>"}], > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > and > > {"protected":"<integrity-protected shared header contents>", > "header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>", > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > Plus, there would be a third syntax if use of the "unprotected" parameter > were not arbitrarily ruled out, as his proposal does: > > {"protected":"<integrity-protected shared header contents>", > "unprotected":<non-integrity-protected shared header contents>, > "header":<per-recipient unprotected header 1 contents>, > "encrypted_key":"<encrypted key 1 contents>", > "aad":"<additional authenticated data contents>", > "iv":"<initialization vector contents>", > "ciphertext":"<ciphertext contents>", > "tag":"<authentication tag contents>" > } > > During the Denver interim meeting in April 2013 and subsequent working > group decisions we all agreed to a specific syntax for the JWE JSON > Serialization. We explicitly agreed to have a "recipients" array, since > this serialization enables multiple recipients. This syntax was > incorporated in draft -11 in May 2013 and has been stable since then. > Given you were an inventor of this syntax, Richard, I'm surprised to see > you questioning it now, this late in the process. > > I'll therefore ask you to withdraw this DISCUSS, since having multiple > syntaxes to represent the same semantics can only hurt interoperability. > FWIW, I'm not necessarily proposing multiple syntaxes. I would be A-OK with requiring that single-recipient JWEs follow the simplified syntax. My comments on the JWS thread about the multiple-recipient case reducing to the single-recipient case also apply here. An implementor is going to have to build a single-recipient version *anyway*, since that's how the crypto works, so we might as well make the syntax match. --Richard > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3.3. > > Why doesn't this example include the JSON encoding? > > Same answer as to your parallel question on JWS. > > > Section 4.1.3. > > "This Header Parameter MUST be integrity protected" > > Why is this the case? There is no security reason that "zip" must be > integrity- > > protected, and this requirement isn't made for any other parameter. > > ekr and others stated reasons for this when the compromise about allowing > some non-integrity-protected parameters was reached. I believe that they > boiled down to ensuring that an attacker couldn't vary the contents of the > plaintext by changing the "zip" parameter value as part of an attack. > Given the effectiveness of the CRIME attack against compression in SPDY > since then, this advice seems all the more sound in retrospect. > > > Section 7.2. > > The requirement that the "recipients" field MUST be present seems odd. > > What's the justification for this? > > Simplicity. The structure of a JWE using the JSON Serialization is always > the same that way, simplifying generators and parsers. If this weren't the > case, they'd have to have a special case for the situation where the > "recipients" array was omitted. > > > Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook. > > Developers have found the examples to be useful in practice. Having more > in the cookbook just adds value, without detracting from the value of the > examples in the JWE spec. > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > Thanks again, > -- Mike >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
