[OAUTH-WG] alg:none RFC8725bis WGLC (was ... Re: Call for adoption for RFC8725bis)

[Brian Campbell <[e-mail]>]

Splitting topics again as per this message
<https://mailarchive.ietf.org/arch/msg/oauth/9iDsDNx8kkpBR4Gib5UbRNNiSZ4/> and
including the JOSE list due to being the WG of
draft-ietf-jose-deprecate-none-rsa15
<https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/>

Yes and even back in 2020ish the original RFC8725 probably should have been
stronger about discouraging RSAES-PKCS1-v1_5.

My rationale for suggesting a reference to the "deprecate" draft, however,
was primarily about wanting to see proper and accountable guidance
regarding the treatment of "alg":"none", which I believe is long overdue.
The "deprecate" draft was well ahead of the RFC8725bis draft in the
document lifecycle when that suggestion was made. I don't believe the cited
"precedent" around RFC9700 is really applicable to this case anyway. And
even if the "deprecate" draft continues to be held up unecessarly
<https://datatracker.ietf.org/doc/minutes-124-jose-202511051430/>, an
informative downref would be totally reasonable.

I did say here
<https://mailarchive.ietf.org/arch/msg/jose/wBQR1eCcZ4rpqsPV2qJ8NCnT9Fk/>
that I believe "alg":"none" has "caused immeasurable and irreparable harm"
but that's maybe too defeatist. I do think there's still some value to be
found in work that endeavors to fix past mistakes. The RFC8725bis draft
should take the opportunity to try.

https://datatracker.ietf.org/doc/minutes-124-jose-202511051430/
On Mon, Dec 1, 2025 at 8:49 AM Yaron Sheffer <[e-mail]> wrote:

> Adding to Mike’s response: the BCP, already in the published RFC8725,
> includes a SHOULD NOT for RSA-PKCS1 v1.5. And it was published 4 years
> *before* the “deprecate” draft.
>
> Thanks,
> Yaron
>
> *From: *Michael Jones <[e-mail]>
> *Date: *Monday, 1 December 2025 at 17:33
> *To: *Brian Campbell <bcampbell=[e-mail]>,
> Rifaat Shekh-Yusef <[e-mail]>
> *Cc: *oauth <[e-mail]>
> *Subject: *[OAUTH-WG] Re: Call for adoption for RFC8725bis
>
> Hi Brian,
>
>
>
> Your message was sent about the same time as I was sending the “*Next
> steps for draft-ietf-oauth-rfc8725bis
> <https://mailarchive.ietf.org/arch/msg/oauth/pz9Frw1P5t8nndEkPhVC3ApkZ8c/>*”
> message summarizing what we’d achieved to date with the RFC8725bis draft.
> Now that working group last call has started, I wanted to also explicitly
> reply to your message saying what the authors have done as a result of your
> feedback, which we appreciate.
>
>
>
> I’ll reply to the rest of the points in your note inline below, with my
> responses prefixed by “Mike>”.
>
>
>
> *From:* Brian Campbell <bcampbell=[e-mail]>
> *Sent:* Friday, November 7, 2025 3:21 PM
> *To:* Rifaat Shekh-Yusef <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] Re: Call for adoption for RFC8725bis
>
>
>
> The acknowledgements updates did happen and a changes from RFC8725 part
> was added but I don't believe anything in the first paragraph has been
> addressed or acknowledged.
>
>
>
> On Fri, Aug 8, 2025 at 5:39 PM Brian Campbell <*[e-mail]
> <[e-mail]>*> wrote:
>
> As I said during the meeting, I am supportive of doing this work but do
> hope the authors have appetite for what they might be signing up
> for. Aaron's review points to some of the work needed.
>
>
>
> Mike> Aaron’s review comments were addressed in
> draft-ietf-oauth-rfc8725bis-02 in a PR that he approved.
>
>
>
> The *https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/
> <https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/>* work
> should almost certainly be referred to.
>
>
>
> Mike> First, I’ll observe that RFC 8725 already included substantial
> treatment of “alg”: “none”, which was retained in this draft, so I believe
> this topic is already well covered in the specification.  Next, I’ll note
> that the draft you cite has not reached WGLC and is still subject to
> change.  As I wrote in my next steps message “There’s precedent in OAuth
> for not holding up publishing a BCP because other developments may update
> the BCP later.  In particular, we decided not to hold the OAuth Security
> BCP [RFC 9700] until we’d addressed already known vulnerabilities,
> including the one being addressed in rfc7523bis.  Our logic was that it is
> better to publish the BCP in a timely fashion to get a set of useful
> information out to people and that the BCP will be updated when the
> mitigations for additional vulnerabilities are settled.  As an individual
> I’ll say that I think that precedent should also apply here.”
>
>
>
> I believe the current text around compression in JWE is a bit overreaching
> and lacking in subtlety about when it's reasonable to use.
>
>
>
> Mike> As asked on the OAuth office hours call on Monday, November 17,
> 2025, are there new JWT best practices that have emerged on this topic
> since RFC 8725 was published that you can cite that you believe should be
> included in the draft, Brian?  If so, please provide proposed text.
>
>
>
> I'm not terribly thrilled about the way explicit typing has worked in
> practice but I'm admittedly not sure how it could be improved at
> this point. I'm sure there's more once the box is opened.
>
>
>
> Mike> As asked on the OAuth office hours call on Monday, November 17,
> 2025, are there new JWT best practices that have emerged on this topic
> since RFC 8725 was published that you can cite that you believe should be
> included in the draft, Brian?  If so, please provide proposed text.
>
>
>
> It seems the draft is largely a rehash of RFC8725 with some additions and
> likely other updates. It should probably explicitly obsolete RFC8725 and
> indicate that it updates BCP 225 by replacing 8725.
>
>
>
> Mike> The specification does both of these things (and says so in the
> Abstract).
>
>
>
> A more formal section that describes the changes from RFC8725 would also
> be nice and is AFAIK common practice in such a document.
>
> Mike> Appendix A does this.
>
>
>
> Similarly it'd be good etiquette to, in the acknowledgements, distinguish
> between contributors to the original document and those that have
> contributed to the updates. I know from some github interactions, for one
> example, that ⁨Filip Skokan⁩ has helped guide some of the updated text
> but he's not mentioned at present.
>
>
>
> Mike> Section 6.1 is the acknowledgements from RFC 8725.  Section 6.2 is
> the acknowledgements for this specification.
>
>
>
> As also somewhat gratuitously mentioned at the meeting, a few years back I
> did a talk a few times on JWT vulnerabilities and tried to take a balanced
> look at many of the criticisms. I don't think there's anything novel or
> unknown in it, but I think it might provide some useful perspective. If
> anyone is interested in seeing that, or just helping drive the meager view
> count up, a recording of one instance of the talk is here *https://www.youtube.com/watch?v=IgKRGS6cQWw
> <https://www.youtube.com/watch?v=IgKRGS6cQWw>*
>
>
>
> Mike> Again, if there are additional JWT best current practices that have
> emerged since RFC 8725 was published that you believe should be included,
> please cite them and provide proposed text for the draft.
>
>
>
>                                                            Thanks,
>
>                                                            -- Mike
>
>
>
> On Wed, Aug 6, 2025 at 11:03 AM Rifaat Shekh-Yusef <*[e-mail]
> <[e-mail]>*> wrote:
>
> All,
>
> This is a call for adoption for the *RFC8725bis* draft that was discussed
> during the last IETF meeting in Madrid:
> *https://datatracker.ietf.org/doc/draft-sheffer-oauth-rfc8725bis/
> <https://datatracker.ietf.org/doc/draft-sheffer-oauth-rfc8725bis/>*
>
> Remember that adoption does not mean a document is finished, only that it
> is an acceptable starting point.
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by August 22nd.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list -- *[e-mail] <[e-mail]>*
> To unsubscribe send an email to *[e-mail]
> <[e-mail]>*
>
>
> *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._