Thanks for your review, Barry. I’ve added the working group to this thread so they're aware of your comments. Replies are inline below…
-----Original Message----- From: Barry Leiba [mailto:[email protected]] Sent: Thursday, September 25, 2014 8:24 AM To: The IESG Cc: [email protected]; [email protected] Subject: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-jose-json-web-encryption-32: No Objection 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: ---------------------------------------------------------------------- -- Section 5.2 -- Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWE can be successfully decrypted, unless the algorithms used in the JWE are acceptable to the application, it SHOULD reject the JWE. It's a small point, but what does it mean for an algorithm to be "acceptable", if not to define this very point? That is, if I accept (don't reject) a decryption with algorithm X, doesn't that *mean* that algorithm X is acceptable to me? Would you prefer that the first “are acceptable” be changed to “MAY be used”? I believe that would remove any potential ambiguity. -- Section 7.2 -- recipients The "recipients" member value MUST be an array of JSON objects. Each object contains information specific to a single recipient. This member MUST be present, even if the array elements contain only the empty JSON object "{}" (which can happen when all Header Parameter values are shared between all recipients and when no encrypted key is used, such as when doing Direct Encryption). I'm not sure how to read this. Which of these is a correct version of the "recipients" member for the case in the second sentence?: a. "recipients": {} b. "recipients": [{}] c. "recipients": [] Can you word this to make the answer clearer in the text? The intent is b. I propose that the words “This member MUST be present, even if the array elements contain only the empty JSON object "{}"” be changed to “This member MUST be present with exactly one array element per recipient, even if some or all of the array element values are the empty JSON object {}”. Would that be clearer? -- Section 9 -- o If the object is using the JWS JSON Serialization or the JWE JSON Serialization, the members used will be different. JWSs have a "signatures" member and JWEs do not. JWEs have a "recipients" member and JWSs do not. But you say that unrecognized members should be ignored, so an object that contains both a "signatures" member and a "recipients" member would be considered valid, but might be judged to be either one or the other, depending upon the order of the checking. Does this matter? Possibly not, but I wanted to ask. There’s a reason that the introductory paragraph contains the caveat: All these methods will yield the same result for all legal input values; they may yield different results for malformed inputs. I believe that this caveat covers the case of malformed (or at least confused) input that you’re describing. Therefore, I believe that no specific edit is needed to the specification in response to this comment. -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
