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 From: Brian Campbell <bcampb...@pingidentity.com> Sent: Monday 5 August 2024 20:14 To: Pieter Kasselman <pieter.kassel...@microsoft.com> Cc: Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org>; RFC Errata System <rfc-edi...@rfc-editor.org>; prkassel...@gmail.com; oauth@ietf.org Subject: Re: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060) By definition a JWT is only ever a JWS or JWE so, while I suppose it's not wrong, that text is much more complicated than necessary and has conditional parts that are never relevant (like all of the original text). I'm not entirely sure what would be most appropriate for the "Corrected Text" but maybe something like this: "Verify the resulting JOSE Header by processing parameters and values whose syntax and semantics are both understood and supported while ignoring those that are not." or this: "Verify the resulting JOSE Header according to RFC7515 or RFC7516." or even just removal of the whole of that step 5? On Thu, Aug 1, 2024 at 8:33 AM Pieter Kasselman <pieter.kassel...@microsoft.com<mailto:pieter.kassel...@microsoft.com>> wrote: Thanks Paul Brian, how about the following: 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. * If the JWT is a JWS, the steps specified in RFC7515 takes precedence when validating JOSE Header parameters. * If the JWT is a JWE, the steps specified in RFC7516 takes precedence when validating JOSE Header parameters. Cheers Pieter From: Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org<mailto:40aiven...@dmarc.ietf.org>> Sent: Wednesday, July 31, 2024 7:56 PM To: Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> Cc: Pieter Kasselman <pieter.kassel...@microsoft.com<mailto:pieter.kassel...@microsoft.com>>; 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: Re: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060) You don't often get email from paul.wouters=40aiven...@dmarc.ietf.org<mailto:paul.wouters=40aiven...@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> The ADs can make edits. Go ahead and propose your edits via this email thread. Paul On Wed, Jul 31, 2024 at 12:45 PM Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote: I honestly don't know. Perhaps the copied AD or someone on the receiving end of the also copied rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org> can advise on the best course of action with respect to the errata process. On Wed, Jul 31, 2024 at 8:01 AM Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> wrote: Thanks Brain – is there a way to edit errata, or do I just submit another one? From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org<mailto:40pingidentity....@dmarc.ietf.org>> Sent: Wednesday, July 31, 2024 2:49 PM To: RFC Errata System <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> Cc: m...@microsoft.com<mailto:m...@microsoft.com>; n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp>; paul.wout...@aiven.io<mailto:paul.wout...@aiven.io>; prkassel...@gmail.com<mailto:prkassel...@gmail.com>; oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060) That is a good catch of an inconsistency in JWT/RFC7519 that is deserving of errata. Note however that JWE/RFC7516 says that the "rules about handling Header Parameters that are not understood by the implementation are also the same [as JWS]"* so the correcting errata text should probably be more generally applicable to all JWTs. * see https://datatracker.ietf.org/doc/html/rfc7516#section-4 On Wed, Jul 31, 2024 at 7:27 AM RFC Errata System <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> wrote: The following errata report has been submitted for RFC7519, "JSON Web Token (JWT)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8060 -------------------------------------- Type: Technical Reported by: Pieter Kasselman <prkassel...@gmail.com<mailto:prkassel...@gmail.com>> Section: 7.2 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 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. If the JWT is a JWS, the steps specified in RFC7515 takes precedence when validating JOSE Header parameters. 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 which requires that the processing rules of RFC 1515 be used if the JWT is a JWS (defined in RFC 1515). RFC 7515 does not 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 (repeated below for convenience). "Unless listed as a critical Header Parameter, per Section 4.1.11, all Header Parameters not defined by this specification MUST be ignored when not understood." A discussion with the authors at IETF 120 confirmed that all header parameters that are not understood must be ignored. The proposed errata aims to clarify that if the JWT is a JWS, the processing rules of RFC 7151 should apply (including ignoring header parameters that are not understood). This is consistent with point 7.2, which requires that RFC 7515 [JWS] rules applies and avoids the impression that a new requirement on when parameters are ignored is being introduced in (i.e. the need to be explicitly defined as needing to be ignored). Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC7519 (draft-ietf-oauth-json-web-token-32) -------------------------------------- Title : JSON Web Token (JWT) Publication Date : May 2015 Author(s) : M. Jones, J. Bradley, N. Sakimura Category : PROPOSED STANDARD Source : Web Authorization Protocol Stream : IETF Verifying Party : IESG _______________________________________________ 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. 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
