Sorry I just recounted, it is a extra 20 bytes per message with the encoded header and not 6.
That is a bit more but probably not worth dying over. I still prefer the smaller option. John B. > On Dec 17, 2015, at 3:04 PM, John Bradley <[email protected]> wrote: > > I prefer making crit only required if the producer is not certain that all > potential recipients understand/the extension. > > However it would not be the end of the world for me from a size perspective > if crit was always required. Trading 6 octets for saving 1/4 of the body > size is not a bad trade off. > > The issue for me is more always requiring something to be sent that is known > to not be used. > > So I am on the not forcing crit side but could live with the consensus if it > goes the other way. > > John B. > >> On Dec 17, 2015, at 2:48 PM, Stephen Farrell <[email protected]> >> wrote: >> >> >> Great. For completeness, the alternative proposed by James Manger >> (which I'd also prefer) was: >> >> The "crit" Header Parameter MUST be included with "b64" in its set >> of values to ensure the JWS is rejected (instead of being >> misinterpreted) by implementations that do not understand this >> specification. >> >> My discuss then is asking if, after all this discussion, the WG >> prefer the above or that below. I'll take the WG chairs word on what >> they conclude as the outcome. >> >> S. >> >> On 17/12/15 13:44, Mike Jones wrote: >>> Sure, I'm obviously fine asking the working group what they think of the >>> new text. Working group - this new text at >>> https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-08#section-6 >>> is: >>> >>> 6. Using "crit" with "b64" >>> >>> If a JWS using "b64" with a value of "false" might be processed by >>> implementations not implementing this extension, then the "crit" >>> Header Parameter MUST be included with "b64" in its set of values to >>> cause such implementations to reject the JWS. Conversely, if used in >>> environments in which all participants implement this extension, then >>> "crit" need not be included, since its inclusion would have no >>> effect, other than increasing the JWS size and processing costs. >>> >>> Thanks all, >>> -- Mike >>> >>>> -----Original Message----- >>>> From: Stephen Farrell [mailto:[email protected]] >>>> Sent: Thursday, December 17, 2015 2:32 PM >>>> To: Mike Jones <[email protected]>; The IESG <[email protected]> >>>> Cc: [email protected]; [email protected]; >>>> draft-ietf-jose-jws-signing- >>>> [email protected]; [email protected] >>>> Subject: Re: Stephen Farrell's Discuss on >>>> draft-ietf-jose-jws-signing-input- >>>> options-08: (with DISCUSS and COMMENT) >>>> >>>> >>>> Hiya, >>>> >>>> On 17/12/15 13:20, Mike Jones wrote: >>>>> Thanks for your review, Stephen. Replies inline below... >>>>> >>>>>> -----Original Message----- From: Stephen Farrell >>>>>> [mailto:[email protected]] Sent: Thursday, December 17, >>>>>> 2015 12:20 PM To: The IESG <[email protected]> Cc: >>>>>> [email protected]; Mike Jones >>>>>> <[email protected]>; Jim Schaad <[email protected]>; >>>>>> [email protected]; [email protected]; [email protected] Subject: >>>>>> Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input- >>>>>> options-08: (with DISCUSS and COMMENT) >>>>>> >>>>>> Stephen Farrell has entered the following ballot position for >>>>>> draft-ietf-jose-jws-signing-input-options-08: Discuss >>>>>> >>>>>> 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-op >>>>>> tions/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> >>>>>> >>>>>> >>>>>> >>>> The "crit" point raised in the gen-art review and maybe elsewhere is I >>>> think >>>>>> correct but I don't think section 6 of -08 is a good resolution of >>>>>> this topic. However, I'll clear if this is the WG consensus but it's >>>>>> hard to know that's the case for text just added yesterday. To >>>>>> resolve this discuss we just need to see what the WG list says about >>>>>> the new text. >>>>> >>>>> Jim's shepherd write-up at >>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-opt >>>>> ions/shepherdwriteup/ records the working group's desire to not >>>>> require the use of "crit" >>>>> when it isn't needed. He wrote: >>>>> >>>>> "(6) The fact that there are two different versions of encoding that >>>>> produce the same text string for signing is worrisome to me. The WG >>>>> had the ability to address this when producing the JWS specification >>>>> and decided not to do so that time. In this document, the desire to >>>>> allow for things to be smaller has lead to the fact that the b64 and >>>>> crit headers can be omitted as being implicit. This was the desire of >>>>> the WG, but I personally feel that it is the wrong decision." >>>> >>>> Fair enough, so the chair/shepherd, gen-art reviewer and seems like a few >>>> IESG members all find the current position unconvincing as does the one >>>> implementer who posted to the WG list since the new text was added. >>>> Wouldn't you agree there's enough there to justify asking the WG once more >>>> what they think about that 13 byte overhead to prevent interop and maybe >>>> even security problems? >>>> >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> >>>>>> >>>> COMMENT: >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> >>>>>> >>>>>> >>>>>> >>>> - abstract: the description of the update to 7519 is odd. It seems to be >>>> saying >>>>>> "Here we define a thing. This specification updates 7519 to say you >>>>>> must not use this thing." but prohibiting is an odd verb to use >>>>>> there. (Since it wasn't previously there to be allowed or not.) >>>>> >>>>> Would you like this text better? >>>>> >>>>> "This specification updates RFC 7519 by stating that JSON Web Tokens >>>>> (JWTs) MUST NOT use the unencoded payload option defined by this >>>>> specification." >>>> >>>> Better yep. Thanks. >>>> >>>>> >>>>> Or do you think this spec doesn't need to have the "Updates 7519" >>>>> clause at all? People seemed split on whether this was needed or not. >>>> >>>> Happens all the time. Personally I mostly don't care about updates which is >>>> the case this time too:-) >>>> >>>>> >>>>>> - section 6: "It is intended that application profiles specify up >>>>>> front whether" "intended" is very wishy washy and "up front" makes no >>>>>> sense at all. >>>>> >>>>> How about this wording change? "It is intended that application >>>>> profiles specify up front whether" -> "Application profiles should >>>>> specify whether" >>>> >>>> Also better, >>>> Ta, >>>> S. >>>> >>>> >>>>> >>>>> Thanks again, -- 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 > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
