Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)

[Mike Jones <[e-mail]>]

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:[e-mail]]
Sent: Thursday, September 25, 2014 8:24 AM
To: The IESG
Cc: [e-mail]; [e-mail]
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