FYI, Benoit, "crit" is now required with "b64", as you'd requested.
-----Original Message----- From: Benoit Claise [mailto:[email protected]] Sent: Thursday, December 17, 2015 12:12 AM To: Mike Jones <[email protected]>; The IESG <[email protected]> Cc: [email protected]; Jim Schaad <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: Benoit Claise's No Objection on draft-ietf-jose-jws-signing-input-options-07: (with COMMENT) Thanks Mike. Regards, Benoit > Thanks for your review, Benoit. Per my reply to Stefan, I've added the new > normative section titled "Using "crit" with "b64"" to specify requirements > for situations in which implementations might not understand one another. As > you can see in draft -08 and my reply to Robert Sparks, "crit" is now > required in all situations in which the participants might not understand one > another. > > I've also adopted Stefan's recommendation that "b64" not be included with a > value of "true". > > Thanks again, > -- Mike > > -----Original Message----- > From: Benoit Claise [mailto:[email protected]] > Sent: Wednesday, December 16, 2015 11:11 PM > To: The IESG <[email protected]> > Cc: [email protected]; Mike Jones > <[email protected]>; Jim Schaad <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Benoit Claise's No Objection on > draft-ietf-jose-jws-signing-input-options-07: (with COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-jose-jws-signing-input-options-07: 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 https://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: > https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As mentioned by Stefan in his OPS DIR review: > There are coexistence issues between implementations which understand the > notion of the "b64" parameter (i.e. implementing this RFC) and those who do > not (i.e. all existing JWS implementations). > The issues are discussed in Security Considerations (second para up until the > end). The issues with it are: > > * the conclusions are not as satisfactory as they could be. > Interoperability is either > > - left as an out-of-band and undescribed mechanism ("make sure that only > supporting implementations talk to each other") > - by explicitly marking support for b64 as critical (IMO the only good > solution) > - modifying the payload so that it contains unparseable characters (which > may or may not be possible for the sender depending on the payload > characteristics) > > * this is placed in Security Considerations while it has actual operational > impact on every transmitted message: in essence it states: > "Sometimes, sender and recipient may misunderstand each other without > noticing". Example given in the draft where the actual message is "NDA1" > while the recipient thinks it was told "405", without a way to notice. > Even if the misunderstanding is not related to security, it can/will have > significant implications for the application. > > I believe this can not be left as-is. Luckily, there seems to be an easy way > out: > > "Whenever the 'b64' header exists and is set to false, the 'crit' header MUST > also be present and contain 'b64'." > > This, maybe in conjunction with > > "When the content is intended to be base64 encoded, the 'b64' header SHOULD > NOT be present." > > This would make sure that implementations who know nothing of b64 are left > alone (there is no unknown extension, there is no criticality in any such > extension, and the sender did not intend to make use of the feature => all > good). While at the same time for unencoded payloads making deterministically > clear that unencoded transmission is happening, and is required to be > understood. > > This would at the same time make a complex piece of Sec Con go away. > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
