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

[Mike Jones <[e-mail]>]

These comments have been addressed in the -34 drafts.

                                                            Thanks again,
                                                            -- Mike

From: Mike Jones
Sent: Tuesday, September 30, 2014 11:51 AM
To: 'Barry Leiba'
Cc: The IESG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)




-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Tuesday, September 30, 2014 9:44 AM
To: Mike Jones
Cc: The IESG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)



>>    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.



I did say it was a small point...  Yes, with lowercase "may"

(definitely not 2119 "MAY"), I think that'd be slightly better, so thanks.



OK



> 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?



I think that would have helped me.  Again, another small point.



OK



> 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.



Yes, that's fine; thanks for the answer.



Barry



                                                            Thanks again,

                                                            -- Mike