Thank you Mike for updating the spec. I verified the -09 JWS examples, the HMAC check passes.
The examples now include the "crit" header, but the requirement for "crit" and why it's needed appears much later in the spec, in section six. Do you think the "Using crit with b64" section could be moved up, just before the "Examples" section? Happy holidays, Vladimir On 22/12/15 16:34, Mike Jones wrote: > It's clear that most people prefer the 100% safe option over the current text > that relies upon application semantics in some cases. Thanks, James, for > suggesting this and thanks to all of you who took the time to look at the > issue. > > I'll prepare a new draft reflecting this outcome. Vladimir, could I ask you > to once again verify the examples, once they've been updated? > > Thanks all, > -- Mike > > From: Preibisch, Sascha H [mailto:[email protected]] > Sent: Monday, December 21, 2015 9:54 AM > To: Roland Hedberg <[email protected]>; Nat Sakimura <[email protected]> > Cc: [email protected]; Axel Nennker <[email protected]>; Jim Schaad > <[email protected]>; Mike Jones <[email protected]>; Kathleen > Moriarty <[email protected]>; > [email protected]; [email protected]; Matthew > Miller <[email protected]>; John Bradley <[email protected]>; The IESG > <[email protected]>; Stephen Farrell <[email protected]> > Subject: Re: [jose] Stephen Farrell's Discuss on > draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT) > > +1 > > From: jose <[email protected]<mailto:[email protected]>> on behalf of > Roland Hedberg <[email protected]<mailto:[email protected]>> > Date: Monday, December 21, 2015 at 8:46 AM > To: Nat Sakimura <[email protected]<mailto:[email protected]>> > Cc: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>, Axel Nennker > <[email protected]<mailto:[email protected]>>, Jim Schaad > <[email protected]<mailto:[email protected]>>, Mike Jones > <[email protected]<mailto:[email protected]>>, Kathleen > Moriarty > <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" > > <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, > Matthew Miller <[email protected]<mailto:[email protected]>>, John Bradley > <[email protected]<mailto:[email protected]>>, The IESG > <[email protected]<mailto:[email protected]>>, Stephen Farrell > <[email protected]<mailto:[email protected]>> > Subject: Re: [jose] Stephen Farrell's Discuss on > draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT) > > +1 > > 21 dec. 2015 kl. 15:55 skrev Nat Sakimura > <[email protected]<mailto:[email protected]>>: > > I also think it is better to make the b64 parameter critical. Being > deterministic makes the life of programmers simpler. It also decreases the > vulnerability surface. So +1 to James's text. > > 2015-12-21 22:26 GMT+09:00 > <[email protected]<mailto:[email protected]>>: > I think that the larger a payload is the higher is the risk of a bad verify > and that few extra bytes don't matter then. > And I follow Vladimir's argument to try to keep the security concideration > section simpler. > > So +1 to James proposed text. > > -----Original Message----- > From: jose [mailto:[email protected]<mailto:[email protected]>] On > Behalf Of Matt Miller (mamille2) > Sent: Donnerstag, 17. Dezember 2015 18:19 > To: Kathleen Moriarty; [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Michael Jones; The > IESG; John Bradley; Stephen Farrell; > [email protected]<mailto:[email protected]> > Subject: Re: [jose] Stephen Farrell's Discuss on > draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT) > > 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]<mailto:[email protected]>> >> wrote: >> >> On Thu, Dec 17, 2015 at 9:32 AM, John Bradley >> <[email protected]<mailto:[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]<mailto:[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]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Djose-2Djws-2Dsigning-2Dinput-2Doptions-2D08-23section-2D6&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=6h1ckn5Dg9eXWhm7uBzIv5nlfE0hRhBXnepM4VkYTF4&e=> >>>>>> 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]<mailto:[email protected]>] >>>>>>> Sent: Thursday, December 17, 2015 2:32 PM >>>>>>> To: Mike Jones >>>>>>> <[email protected]<mailto:[email protected]>>; The >>>>>>> IESG >>>>>>> <[email protected]<mailto:[email protected]>> >>>>>>> Cc: [email protected]<mailto:[email protected]>; >>>>>>> [email protected]<mailto:[email protected]>; >>>>>>> draft-ietf-jose-jws-signing- >>>>>>> [email protected]<mailto:[email protected]>; >>>>>>> [email protected]<mailto:[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]<mailto:[email protected]>] >>>>>>>>> Sent: Thursday, December 17, >>>>>>>>> 2015 12:20 PM To: The IESG <[email protected]<mailto:[email protected]>> Cc: >>>>>>>>> [email protected]<mailto:[email protected]>; >>>>>>>>> Mike Jones >>>>>>>>> <[email protected]<mailto:[email protected]>>; >>>>>>>>> Jim Schaad >>>>>>>>> <[email protected]<mailto:[email protected]>>; >>>>>>>>> [email protected]<mailto:[email protected]>; >>>>>>>>> [email protected]<mailto:[email protected]>; >>>>>>>>> [email protected]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=F-Oeeqy3nqyCXNTlMMsbDn0uum3p2s8B_C_bPHv-iWU&e=> >>>>>>>>> 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-in<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Djose-2Djws-2Dsigning-2Din&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Ch214Lh2tm6Ix64rIOcKk79Za-NwaV61Nvq6pVT91Hk&e=> >>>>>>>>> put-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-inp<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Djose-2Djws-2Dsigning-2Dinp&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=_3qBc6exQH8Nd356HMWzlscgfNDHK0jEbj_cdpJtUXI&e=> >>>>>>>> ut-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]<mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=> >>>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> [email protected]<mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=> >> >> >> -- >> >> Best regards, >> Kathleen > _______________________________________________ > jose mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=B1oKcaNgmP1aOC-WZgfxNIOlZoW1gZ5MrL-Ju1XK9uc&e=> > @_nat_en > _______________________________________________ > jose mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwQFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=> > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose -- Vladimir Dzhuvinov :: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
