Hi, I recently reviewed: https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-alg-none/10/
It's possible there is useful material to reference here. I do think commentary on historical usage might be helpful, the current text states: > Although there are some legitimate use-cases for Unsecured JWS, these are relatively few in number and can easily be satisfied by alternative means. A reference for what these legitimate use cases are would be helpful. Regards, OS On Mon, Sep 22, 2025 at 12:46 PM Neil Madden <[email protected]> wrote: > Hi Mike, > > Thanks for the response. However, I have not heard from anyone else > expressing this opinion, or any opinion in support of “none” at all. The > consensus thus far has been in favour of deprecating “none”, with yourself > as a lone dissenting voice. Given that “none” will be deprecated by this > RFC (if published), I think adding text that names specific “legitimate” > uses only muddies the waters, creating potential confusion as to what > deprecation actually means. I therefore agree with Brian and Filip that the > current text is fine. > > Given that it’s been 18 months since I introduced the draft, with only a > handful of minor editorial changes in that time, I do think it’s ready for > last call. > > Best wishes, > > Neil > > > On 19 Sep 2025, at 18:08, Michael Jones <[email protected]> > wrote: > > The current description of “none” at > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-03.html#name-the-none-algorithm > is not evenhanded. It lists 9 cases where defective implementations or > deployments caused problems but fails to list the 2 legitimate and safe > uses of “none” that I provided in my review. The document will not be > ready for working group last call until this is addressed. > > Neil, please add this or similar text that section so that the legitimate > uses are called out for readers, providing a balanced treatment of the > subject: > One of the legitimate use cases for Unsecured JWSs is OpenID Connect ID > Tokens secured by sending them over a TLS connection, as described in > Section 2 of [OpenID.Core]. Another legitimate use is unsigned request > objects, as described in Section 6.1 of [OpenID.Core]. > That, or consider deleting all the references to the illegitimate uses. > > Thank you, > -- Mike > > *From:* Neil Madden <[email protected]> > *Sent:* Friday, September 19, 2025 2:19 AM > *To:* Brian Campbell <[email protected]>; [email protected] > *Cc:* Michael Jones <[email protected]>; Neil Madden < > [email protected]> > *Subject:* Re: [jose] Review of draft-ietf-jose-deprecate-none-rsa15-02 > > I’ve published a new draft -03 that addresses Mike’s review comments, > except for adjusting the text around “none” as per the feedback on the list > that the current text is fine. > > Chairs - I believe this is ready for WGLC now. > > Name: draft-ietf-jose-deprecate-none-rsa15 > Revision: 03 > Title: JOSE: Deprecate 'none' and 'RSA1_5' > Date: 2025-09-19 > Group: jose > Pages: 7 > URL: > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-03.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/ > HTML: > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-03.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-ietf-jose-deprecate-none-rsa15 > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-deprecate-none-rsa15-03 > > Cheers, > > Neil > > > On 31 Jul 2025, at 14:00, Brian Campbell <[email protected]> > wrote: > > That link > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#section-1.1-4 > points to the last paragraph of section 1.1. The 'none' algorithm > <https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#name-the-none-algorithm> > that > has the text: > > 'Although there are some legitimate use-cases for Unsecured JWS, these are > relatively few in number and can easily be satisfied by alternative means. > The small risk of breaking some of these use-cases is far outweighed by the > improvement in security for the majority of JWS users who may be impacted > by accidental acceptance of the "none" algorithm.' > > Which is the text I'm suggesting already provides pretty good and > even-handed treatment of the topic and shouldn't be changed. > > > On Wed, Jul 30, 2025 at 1:30 PM Michael Jones <[email protected]> > wrote: > > The use cases that I’m asking to have added for reference are about “alg”: > “none”, so readers will know why it exists and how it is used – not > “RSA1_5”. I agree with Brian that the text describing “RSA1_5” is already > fine. > > -- Mike > > *From:* Brian Campbell <[email protected]> > *Sent:* Wednesday, July 30, 2025 11:02 AM > *To:* Neil Madden <[email protected]> > *Cc:* Michael Jones <[email protected]>; [email protected]; > [email protected] > *Subject:* Re: [jose] Re: Review of > draft-ietf-jose-deprecate-none-rsa15-02 > > > On Wed, Jul 30, 2025 at 2:53 AM Neil Madden <[email protected]> > wrote: > > *1.1. > <https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#section-1.1>The > 'none' algorithm > <https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#name-the-none-algorithm>: > *After > the sentence beginning “Although there are some legitimate use-cases for > Unsecured JWS”, I suggest adding this text: > One of the legitimate use cases for Unsecured JWSs is OpenID Connect ID > Tokens secured by sending them over a TLS connection, as described in > Section 2 of [OpenID.Core]. Another legitimate use is unsigned request > objects, as described in Section 6.1 of [OpenID.Core]. > > > I’m open to adding something along these lines. I’ll raise a PR. > > > I thought the text in > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#section-1.1-4 > provies pretty good and even-handed treatment as is. I think it'd be a > mistake to list specific cases in the text here. > > > *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.* > > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
