-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/20/14, 10:21 AM, Richard Barnes wrote: > > > On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones > <[email protected] <mailto:[email protected]>> > wrote: > > Thanks for your review, Richard. Responses are inline below... > >> -----Original Message----- From: jose >> [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Richard Barnes >> Sent: Wednesday, October 01, 2014 8:37 PM To: The IESG Cc: >> [email protected] > <mailto:[email protected]>; jose- >> [email protected] <mailto:[email protected]>; > [email protected] <mailto:[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 >
As I think I've said in previous discussions about the JSON serialization, I can live with something verbose *BUT* would rather like a lighter syntax for the single-encrypt JSON serialization. While multiple recipients is not quite as rare in encryption as it is for signing, single-encrypt is still the more common usecase, and so optimizing for it seems like a good thing. > > > >> ---------------------------------------------------------------------- > >> > 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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose > > Thanks again, -- Mike > > > > > _______________________________________________ jose mailing list > [email protected] https://www.ietf.org/mailman/listinfo/jose > - -- - - m&m Matt Miller < [email protected] > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJURT4lAAoJEDWi+S0W7cO1oUoH/icet/JldtOQKwedTjDu2bY0 J8y9Ahy9rVgN8TbDxoKhSt/GFu2CIIZ5BaNvcV7uViHlI6ip8gPhbhmcIyNiAOUj ZEFk8Xu5UfOmWDYdxSfJy+R9I7mGJZDY5ikZGrMgp3Kz/JUNFv8Q3XHte4Dq2txJ ELkRob7PSQnbcf2qycamGH9vEEeVKGMvz+UFU2jwcwF3ewi8kJFXSYbhP2bgSSfu pgS3nURakFa7hpQjoFFDsrF0USFojlUfYUaqeiWwg4NRUrKwZ42hcgd3RRKj+TbY t1AZq+9pLzNQ4bmJEC9rp3cBN/8bXxOT28CHNqeVZyPD7owKK+HAp3mValwA06k= =J5EG -----END PGP SIGNATURE----- _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
