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
