I can absolutely appreciate the "make it worth my while to wrestle w/ the RFC errata system " sentiment but am not in a position myself to spend more time on errata right now.
On Tue, Feb 11, 2025 at 4:10 AM Deb Cooley <debcool...@gmail.com> wrote: > Can I talk you into looking at the other three reported errata on that > RFC? (RFC 7519 and Erratas: 5906, 7720, and 8225) > To make it worth my while to wrestle w/ the RFC errata system... > > Deb > > On Mon, Feb 10, 2025 at 5:56 PM Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> Pieter said errata in July of last year and we've had this very >> intermittent conversation about https://www.rfc-editor.org/errata/eid8060 >> in the intervening months. I think it's ready for those edits and button >> pushing you mentioned. No impact on RFCs 7797 or 8725 (BCP 225). These are >> the edits I think we've agreed on as validated/verified technical errata: >> >> Section 7.2 says: >> >> 5. Verify that the resulting JOSE Header includes only parameters >> and values whose syntax and semantics are both understood and >> supported or that are specified as being ignored when not >> understood. >> >> It should say: >> >> 5. Verify the resulting JOSE Header according to RFC7515 or RFC7516. >> >> Notes: >> Validation step 5 in section 7.2 of RFC 7519 states that header >> parameters should only be ignored if they are explicitly specified as >> needing to be ignored. >> >> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that >> the processing rules of RFC 7515 should be followed if the JWT is a JWS, or >> the rules of RFC7516 should be followed if the JWT is a JWE. Neither RFC >> 7515 nor RFC 7516 include any special provisions for only ignoring header >> parameters if they are specified as being ignored, but instead requires all >> header parameters to be ignored if they are not understood, except if they >> are critical. >> >> >> >> >> >> On Sat, Feb 8, 2025 at 4:37 AM Deb Cooley <debcool...@gmail.com> wrote: >> >>> Errata? Did I hear you say errata? >>> >>> I can push the buttons to properly dispatch this. I think this includes >>> editing an errata and certainly includes adding notes to it. I need to >>> know what edits and or comments you want made, and what outcome (reject, >>> validate, hold for document update). Also how it affects RFCs 7797 and >>> 8725 (BCP 225), since I see that 7519 is updated by these. >>> >>> While we are doing this work, there are three others (5906, 7720, and >>> 8225) at: >>> https://www.rfc-editor.org/errata_search.php?rfc=7519&rec_status=2&area_acronym=sec&presentation=table >>> . Take a peek and tell me how to mark them (reject, validate, HFDU). The >>> tooling for this is, hmmmm old, so I like to do these in groups. >>> >>> If there is appetite, we can look at other oauth errata... >>> >>> Deb >>> >>> >>> >>> On Fri, Feb 7, 2025 at 2:56 PM Brian Campbell <bcampbell= >>> 40pingidentity....@dmarc.ietf.org> wrote: >>> >>>> Apologies Pieter, this fell "below the fold" in my inbox so to speak >>>> and I lost track of responding to it. Thanks for the proposed new "notes" >>>> for the errata, which I do think are sufficient now. In conjunction with >>>> that simple "corrected text" you had of "5. Verify the resulting JOSE >>>> Header according to RFC7515 or RFC7516." >>>> >>>> On Thu, Nov 21, 2024 at 8:25 PM Pieter Kasselman <pie...@spirl.com> >>>> wrote: >>>> >>>>> Brian, as discussed at IETF 121, it would be good to wrap up on this >>>>> errata. Is the below sufficient, or are there additional refinements or >>>>> steps to take? >>>>> >>>>> Cheers >>>>> >>>>> Pieter >>>>> >>>>> -------------------------------- >>>>> >>>>> Hi Brian, agreed, and thanks for pointing that out. Suggestion below: >>>>> >>>>> >>>>> >>>>> Notes >>>>> ----- >>>>> Validation step 5 in section 7.2 of RFC 7519 states that header >>>>> parameters should only be ignored if they are explicitly specified as >>>>> needing to be ignored. >>>>> >>>>> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that >>>>> the processing rules of RFC 7515 should be followed if the JWT is a JWS, >>>>> or the rules of RFC7516 should be followed if the JWT is a JWE. Neither >>>>> RFC 7515 nor RFC 7516 include any special provisions for only ignoring >>>>> header parameters if they are specified as being ignored, but instead >>>>> requires all header parameters to be ignored if they are not understood, >>>>> except if they are critical. >>>>> >>>>> This errata clarifies that JOSE Header parameters should be verified >>>>> according to RFC7515 (JWS) or RFC7516 (JWE). >>>>> >>>>> >>>>> >>>>> >>>>> From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> >>>>> <<bcampbell=40pingidentity....@dmarc.ietf.org>> >>>>> Sent: Monday 12 August 2024 19:46 >>>>> To: Pieter Kasselman <pieter.kassel...@microsoft.com> >>>>> <<pieter.kassel...@microsoft.com>> >>>>> Cc: David Waite <da...@alkaline-solutions.com> >>>>> <<da...@alkaline-solutions.com>>; Paul Wouters >>>>> <paul.wout...@aiven.io> <<paul.wout...@aiven.io>>; RFC Errata >>>>> System <rfc-edi...@rfc-editor.org> <<rfc-edi...@rfc-editor.org>>; >>>>> prkassel...@gmail.com; oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060) >>>>> >>>>> Thanks Pieter, >>>>> >>>>> That sounds good to me. I think a bit of the explanatory text in the >>>>> "Notes" part of the errata likely needs to be adjusted accordingly too. >>>>> >>>>> >>>>> >>>>> On Mon, Aug 12, 2024 at 5:01 AM Pieter Kasselman >>>>> <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> >>>>> wrote: >>>>> Thanks David and Brian. >>>>> >>>>> Unless there are any concerns with adopting the alternative text, I would >>>>> suggest the following for the errata in section 7.2 bullet 5: >>>>> >>>>> Original Text >>>>> ------------- >>>>> 5. Verify that the resulting JOSE Header includes only parameters >>>>> and values whose syntax and semantics are both understood and >>>>> supported or that are specified as being ignored when not >>>>> understood. >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> 5. Verify the resulting JOSE Header according to RFC7515 or RFC7516. >>>>> >>>>> Cheers >>>>> >>>>> Pieter >>>>> >>>>> From: David Waite >>>>> <david=40alkaline-solutions....@dmarc.ietf.org<mailto:40alkaline-solutions....@dmarc.ietf.org>> >>>>> Sent: Monday 5 August 2024 22:43 >>>>> To: Pieter Kasselman >>>>> <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> >>>>> Cc: Paul Wouters >>>>> <paul.wouters=40aiven...@dmarc.ietf.org<mailto:40aiven...@dmarc.ietf.org>>; >>>>> RFC Errata System >>>>> <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>; >>>>> prkassel...@gmail.com<mailto:prkassel...@gmail.com>; >>>>> oauth@ietf.org<mailto:oauth@ietf.org> >>>>> Subject: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060) >>>>> >>>>> >>>>> >>>>> On Aug 5, 2024, at 1:52 PM, Pieter Kasselman >>>>> <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:pieter.kasselman=40microsoft....@dmarc.ietf.org>> >>>>> wrote: >>>>> >>>>> I tried to keep the changes to additional text that would scope the >>>>> processing rules more precisely for the JWT/JWS/JWE cases (point 7 in the >>>>> processing steps references JWS and JWE separately, so thought I would >>>>> propose text that does something similar to that). The idea of additional >>>>> text is that a reader who is familiar may find it easier to process the >>>>> delta. >>>>> >>>>> However, if we want to change the text, I like your second option: >>>>> >>>>> "Verify the resulting JOSE Header according to RFC7515 or RFC7516." >>>>> >>>>> I don’t think we should delete the bullet completely. >>>>> >>>>> Cheers >>>>> >>>>> Pieter >>>>> >>>>> I prefer this over the current text, which might be incorrectly construed >>>>> to provide counter guidance to the “crit” protected header parameter. >>>>> >>>>> -DW >>>>> _______________________________________________ >>>>> OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> >>>>> To unsubscribe send an email to >>>>> oauth-le...@ietf.org<mailto:oauth-le...@ietf.org> >>>>> >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). Any >>>>> review, use, distribution or disclosure by others is strictly prohibited. >>>>> If you have received this communication in error, please notify the >>>>> sender immediately by e-mail and delete the message and any file >>>>> attachments from your computer. Thank you. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibited. >>>> If you have received this communication in error, please notify the sender >>>> immediately by e-mail and delete the message and any file attachments from >>>> your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list -- oauth@ietf.org >>>> To unsubscribe send an email to oauth-le...@ietf.org >>>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
