Also, note this text needs to appear in JWS, not JWA, since it's a general requirement on JWS implementations. So in addition to requiring implementations to be unnecessarily complex, it also breaks the clean separation between those documents.
On Wed, Sep 4, 2013 at 6:45 PM, Richard Barnes <[email protected]> wrote: > I think it's important to emphasize that an implementation MUST NOT allow > a global setting. In fact, I would argue that if "none" is in the > acceptable algorithm list, it MUST be the only thing in the list. Any > other way, and you end up with downgrade. > > --Richard > > > On Tue, Sep 3, 2013 at 6:47 PM, Mike Jones <[email protected]>wrote: > >> Your proposed text seems overly verbose. In particular, I believe >> you’ll find that the text I proposed already means the same thing / modulo >> the difference between RECOMMENDED and MUST. If the WG wants a MUST we >> could do that instead of RECOMMENDED. We can discuss that on tomorrow’s >> call.**** >> >> ** ** >> >> The correspondence is as follows:**** >> >> Your sentence 1 is covered in my sentence 1.**** >> >> Your sentence 2 is covered in my sentence 1.**** >> >> Your sentence 3 is covered in my sentences 1 & 2. In particular, the >> “per-object basis” is already covered by “in a JWS object”. (If it were >> not on a per-object basis, it would have said something like “in all JWS >> objects”.**** >> >> ** ** >> >> Cheers,** >> ** >> >> -- Mike** >> ** >> >> ** ** >> >> *From:* Richard Barnes [mailto:[email protected]] >> *Sent:* Tuesday, September 03, 2013 1:33 PM >> *To:* Mike Jones >> *Cc:* [email protected] >> *Subject:* Re: [jose] Text about applications and "alg":"none"**** >> >> ** ** >> >> This text is still far too weak, and does not reflect what I remember EKR >> saying (in particular, there is no MUST). It does not address the attack >> where an application may, in general, be willing to accept both signed and >> unsigned content, but each in specific contexts. Proposed text:**** >> >> ** ** >> >> """**** >> >> JWS implementations MUST provide an interface for applications to specify >> a list of "alg" values that are acceptable for the validation of a given >> JWS object. JWS implementations MUST NOT indicate that a JWS object is >> valid if the "alg" value for the object is "none", unless the application >> has specifically indicated that the value "none" is acceptable for the >> particular JWS object being validated. Applications using "none" MUST >> indicate support on a per-object basis, in order to avoid downgrade attacks >> that arise if more broadly-applicable preferences are specified.**** >> >> """**** >> >> ** ** >> >> I continue to believe that this is far too subtle, and that applications >> are very likely to get it wrong. It is far simpler and safer to require >> that a JWS implementation MUST reject an object with "alg":"none", and have >> another content type for unsigned content.**** >> >> ** ** >> >> Also, if "none" is going to remain, then it needs to be OPTIONAL. Given >> all the above limitations, I don't see how you could justify it being >> mandatory.**** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> ** ** >> >> On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <[email protected]> >> wrote:**** >> >> I took an action item during the last call to write text along the lines >> suggested by ekr about applications and "alg":"none". I propose that the >> following text be included:**** >> >> **** >> >> It is RECOMMENDED that libraries provide applications a means of >> specifying the list of acceptable algorithms used in a JWS object in a way >> that causes inputs using algorithms outside the specified set to be >> rejected. In particular, it is intended for applications to use this >> mechanism to exclude accepting inputs using "alg":"none" in security >> contexts where non-integrity protected inputs are not acceptable.**** >> >> **** >> >> Feedback/proposed wording refinements welcomed.**** >> >> **** >> >> -- Mike** >> ** >> >> **** >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
