Thanks for taking the time to provide these comments, Pete. Descriptions of the actions that were taken in the -38 drafts in response to them are included inline below.
> -----Original Message----- > From: Pete Resnick [mailto:[email protected]] > Sent: Tuesday, December 02, 2014 8:37 PM > To: The IESG > Cc: [email protected]; draft-ietf-jose-json-web- > [email protected] > Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-encryption-37: > (with COMMENT) > > Pete Resnick has entered the following ballot position for > draft-ietf-jose-json-web-encryption-37: Abstain > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I've got some suggestions for improvements below, but overall I cannot > support this document, so I'm entering an ABSTAIN. I don't think this WG has > actually fulfilled its charter with regard to this document set. The WG was > supposed to produce a "JSON syntax that can be used by applications to > describe secure data objects". I don't believe it did that. Instead, it > produced > a compact serialization for a particular purpose and then backed into a JSON > syntax. The compact serialization drove the effort and produced IMO a > substandard JSON serialization. I don't believe that (reliable) interoperable > implementations of the JSON serialization will be possible using this > document set. However, there is at least rough consensus that these > documents are usable as-is, and I don't think there's anything to be gained by > holding them up any further. > > I hope the WG will adopt some of the remaining comments, but my intention > is not to discuss this any further. If you wish to address any of the comments > and need clarification, I'm glad to help with that. > > ------ > > I really wish you would have factored out what's common between JWS and > JWE so you didn't have so much repeated text. (The same response applies as to the same comment in your JWS review.) > 1: Lose the last paragraph. It's not a core goal. Certainly not in the > charter. (The same response applies as to the same comment in your JWS review.) > 3.1: Failure to have an unprotected header in the compact serialization > means that these things are not round-trippable. That's very unfortunate > and I think a failure of the protocol. (The same response applies as to the same comment in your JWS review.) > 3.2: > > In the JWE JSON Serialization, a JWE object is represented as the > combination of these eight values... > > That's not true, and potentially confusing. In the JSON Serialization, the JWE > object is represented as a JSON object with 8 members: > > protected, whose value is BASE64URL(UTF8(JWE Protected Header)), > unprotected, whose value is JWE Shared Unprotected Header... > > etc. Good suggestion - thanks - done > 3.3: > > - Add "If this were part of an Protected Header, it would be encoded as..." The conditional language isn't appropriate here for the same reason that it isn't in your related JWS comment. > Please show the regular JSON Serialization, not just the compact. The > compact is lousy as an overview example. If you want to add the compact > after the JSON, that's OK. (The same response applies as to the similar comment in your JWS review.) > 4.1.2: Change "MUST reject" to "will be unable to decrypt". Done, using the same language as already used in 4.1.1. > Strike the last > sentence of the first paragraph. This sentence adds normative processing requirements, and so is necessary. > 5.1: > > It looks like steps 1, 2, 3, and 6 are actually one big step. They should > probably > be combined and clarified in some way. As previously discussed, all of 2-6 are steps dependent upon the key management mode used to determine and encode the CEK value. It's not clear to me, editorially, that combining a bunch of simple steps with a single action into a bigger combined step with multiple conditional actions would result in a clearer specification. > 4 and 5 could be reasonably combined. As previously discussed, their actions are different. > 19 - Delete everything after the first sentence (and optionally point to > section 7). (The same response applies as to the similar comment in your JWS review.) > 5.2: If these things are steps, start with the verb. See 2 below as an > example, > but look at the other steps as well. I reworked the steps to eliminate non-steps and to have them start with a verb in response to your comments on the -33 drafts (thanks!). The only ones that don't start with a verb start with a conditional phrase determining whether the step applies, followed by the verb. > 1 - Say what to parse out and refer to section 7. Again, don't privilege > compact. (The same response applies as to the similar comment in your JWS review.) > 4 could be significantly shortened if you didn't separate the > serializations. Just make it the union. If some of the members are absent > (for whatever reason), that's fine. The instructions would be confusing if they directed implementers to use values that cannot exist, which your proposed change would do. > 4 and 5 should be combined. They do different, although admittedly conceptually related, things. > 8-11 seem like they could be combined/refactored in some useful way. As previously discussed, all of 8-11 are steps dependent upon the key management mode used to determine and encode the CEK value. It's not clear to me, editorially, that combining a bunch of simple steps with a single action into a bigger combined step with multiple conditional actions would result in a clearer specification. > (I'll also note here that the "recipient" construct is still weird to me. > It's just a "key owner" or something like that, right?) (See the discussion of the "recipient" terminology in my response to your JWS comments.) > 14 and 15 - Ditch the parenthetical. (The same response applies as to the similar comment in your JWS review.) > 18 is kind of silly. If decryption failed, it failed. No need to > additionally "reject" (whatever that is supposed to mean). The second and > third sentences are just implementation detail. Delete 18. The draft has been changed to use the "MUST be considered invalid" language you'd agreed to earlier, rather than the "reject" language that you objected to. The current language making it an application decision what to do when validations or decryptions fail in the multi-recipient case is due to Jim Schaad's input in http://trac.tools.ietf.org/wg/jose/trac/ticket/101. > 9: It took me a bit to figure out why this section is here. This is only a > problem > for the Compact Serialization. The second bullet makes this > clear: For > the JSON Serialization, the answer is, "They're different if they're > different." I > suggest rewriting this section to make it clear that you're trying to help > folks > who need to distinguish between compact serializations. As previously discussed, it's also needed for the JSON Serializations, hence bullet 2. Bullets 3 and 4 also apply to both serializations. Only bullet 1 is specific to the compact serializations. > Appendix A: Leaving the JSON Serialization until the end and putting a > compact serialization in every example stinks. Let's not make it harder for > implementers to figure out how to use the JSON Serialization. As previously discussed, other than the last two examples, the examples are there to describe properties of algorithms, not of serializations, so both serializations aren't needed to illustrate those points. The compact serialization examples are fine for that purpose. That being said, draft-ietf-jose-cookbook is chock full of examples of both serializations. It's scheduled for the December 18th telechat. Thanks again, Pete! -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
