I prefer Jame’s proposal as well. — Justin
> On Dec 17, 2015, at 12:19 PM, Matt Miller (mamille2) <[email protected]> > wrote: > > I prefer James' proposed text. I believe this draft came about primarily > because there are use cases where the content to sign is large enough that > the burden of base64url encoding is too great. By that measure, I'm not sure > how worthwhile size-of-header arguments are, as content so large that > base64url might be prohibitive would dwarf the concerns around header size. > I think the risk of bad verifies outweighs the reduced-headher-size benefits. > > > -- > - m&m > > Matt Miller > Cisco Systems, Inc. > >> On Dec 17, 2015, at 08:39, Kathleen Moriarty >> <[email protected]> wrote: >> >> On Thu, Dec 17, 2015 at 9:32 AM, John Bradley <[email protected]> wrote: >>> 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. >> >> If we could get to a consensus on this and which text is preferred, >> that would be helpful. >> >> Thanks! >> Kathleen >> >> >>> >>> 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 >>>> >>> >> >> >> >> -- >> >> Best regards, >> Kathleen > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
