The subtext here, I think, is that the actual legitimacy of those cases is considered very questionable by many/most folks with knowledge of the larger situation. Such cases would have been easily and directly served by just sending the bare payload (maybe properly encoded for context) without any conception of JW[S/T]. Introducing a signature that's not a signature (which is what "alg":"none" does) violates the layering and semantic meaning of JWS/JWT in a way that enables applications and libraries to (understandably) easily and repeatedly make mistakes that completely undermine the security assurances of the whole stack. It is a specification design mistake that has caused immeasurable and irreparable harm across the board, including reputational damage to JOSE, JWT, and the IETF itself. The "legitimate use cases" are not actually legitimate and unnecessarily accommodating them in JWS/JWT has caused serious and widespread collateral damage.
So, when I said that I thought that the text at https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-02.html#section-1.1-4 (and quoted below) provides even-handed treatment, I was trying to graciously say that I thought Neil had been unduly and admirably gracious in his treatment of the subject. 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. Given this discussion, I'd suggest the word "legitimate" be replaced with "ill-conceived" in that text. Or, barring that, just removed. If, as has been suggested, the OpenID Connect cases are added to the draft, they should not be legitimized but rather qualified as the unnecessary mistakes that they are. On Tue, Sep 23, 2025 at 1:14 PM Orie <[email protected]> wrote: > > > On Tue, Sep 23, 2025 at 1:51 PM Neil Madden <[email protected]> > wrote: > >> >> >> On 22 Sep 2025, at 20:54, Orie <[email protected]> wrote: >> >> >> Hi, >> >> I recently reviewed: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-alg-none/10/ >> >> >> I kinda wish I’d not seen that. >> > > ha : ) > > >> >> 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. >> >> >> Helpful for whom and for what reason? I’m not averse to adding some text >> if it serves a concrete purpose, but as I said to Mike, it feels like >> muddying the waters. I’m not really sure why it’s helpful for a reader to >> see specific examples. >> > > Well in the spirit of the current text, if there are legitimate use cases, > let's name them... If there are not, let's remove the sentence about them > existing. > > I'm speculating, but I imagine the legitimate use cases are: > > 1. Delivering unsigned JWS over TLS (Who does this, why do they do this?) > 2. Delivering unsigned JWS as part of requesting a signature (Who does > this, why do they do this?) > > 2 is maybe the same case as the lamps doc? > > I legitimately do not know why anyone would use alg none today.... If > it's still relevant for compatibility, we should be able to point to > systems that are still operational that require it. > If we can't, there might be no legitimate use. > > And as a side benefit, if there are protocols that were built by the IETF > that still require alg none, and it might be time to make them historic, > perhaps this could help identify those cases. > The end goal of the draft is to make the internet safer, the more > explicit we can be about where this has been used in the past the better > IMO. > > >> >> — Neil >> >> >> -- _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]
