Mike, I think that the text is somewhat tone deaf to the issue that Robert raises, and which I have said many times. The question is not how to I make sure it will work, but how do I make sure that it will fail when it is not supposed to work. Use of 'crit' does that quite well. It is not clear that your favored method 1 would do this. Jim > -----Original Message----- > From: jose [mailto:jose-bounces@xxxxxxxx] On Behalf Of Mike Jones > Sent: Saturday, December 12, 2015 6:33 PM > To: Robert Sparks <rjsparks@xxxxxxxxxxx>; General Area Review Team <gen- > art@xxxxxxxx>; ietf@xxxxxxxx; jose@xxxxxxxx; draft-ietf-jose-jws-signing-input- > options@xxxxxxxx > Subject: Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options- > 06 > > Hi Robert. Thanks for the useful review. Replies are inline below... > > > -----Original Message----- > > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > > Sent: Friday, December 4, 2015 11:08 AM > > To: General Area Review Team <gen-art@xxxxxxxx>; ietf@xxxxxxxx; > > jose@xxxxxxxx; draft-ietf-jose-jws-signing-input-options@xxxxxxxx > > Subject: Gen-Art LC review: > > draft-ietf-jose-jws-signing-input-options-06 > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed by > > the IESG for the IETF Chair. Please treat these comments just like > > any other last call comments. > > > > For more information, please see the FAQ at > > > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Document: draft-ietf-jose-jws-signing-input-options-06 > > Reviewer: Robert Sparks > > Review Date: 4Dec2015 > > IETF LC End Date: 9Dec2015 > > IESG Telechat date: 17Dec2015 > > > > Summary: Almost ready for publication as Proposed Standard, but with a > > minor issue that should be addressed before publication. > > > > Minor issues: > > > > This document explicitly provides a way for interoperability to fail, > > but does not motivate _why_ leaving this failure mode in the protocol > > is a good tradeoff. > > > > Specifically, as the security considerations section points out, it is > > possible for an existing implementation to receive a JWS that has > > b64=false, which it will ignore as an unknown parameter, and (however > > unlikely) successfully decode the payload, and hence believe it has a > > valid JWS that is not what was sent. > > > > The idea that this failure can be avoided by making sure the endpoints > > all play nice through some unspecified agreement is dangerous. > > Specifically, I don't think you can rule out the case that the JWS > > escapes the controlled set of actors you are positing in option 1 from > > the list in the security considerations.. > > > > I would have been much more comfortable with a consensus to require 'crit'. > > (Count me in the rough if this proceeds with crit being optional). > > > > I assume there is a strong reason to allow for option 1. Please add > > the motivation for it to the draft, and consider adding a SHOULD use 'crit' > > requirement if option 1 remains. > > It's a reasonable request to have the draft say why "crit" isn't required. My > working draft adds the following new paragraph at the end of the security > considerations section to do this. Unless I hear objections, I'll plan on publishing > an updated draft with the paragraph shortly. > > "Note that methods 2 and 3 are sufficient to cause JWSs using this extension to > be rejected by implementations not supporting this extension but they are not > sufficient to enable JWSs using this extension to be successfully used by > applications. Thus, method 1 - requiring support for this extension - is the > preferred approach and the only means for this extension to be practically useful > to applications. Method 2 - requiring the use of <spanx > style="verb">crit</spanx> - while theoretically useful to ensure that confusion > between encoded and unencoded payloads cannot occur, is not particularly > useful in practice, since method 1 is still required for the extension to be usable. > When method 1 is employed, method 2 doesn't add any value and since it > increases the size of the JWS, its use is not required by this specification." > > > Nits/editorial comments: > > > > In the security considerations, the last sentence of the first > > paragraph needs to be simplified. I suggest replacing it with: > > > > "It then becomes the responsibility of the application to ensure that > > payloads only contain characters that will not cause parsing problems > > for the serialization used, as described in Section 5. The application > > also incurs the responsibility to ensure that the payload will not be > > modified during retransmission. > > I have simplified this in the manner that you suggested. > > Thanks again, > -- Mike > _______________________________________________ > jose mailing list > jose@xxxxxxxx > https://www.ietf.org/mailman/listinfo/jose