On Tue, 2025-09-23 at 14:14 -0500, Orie 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.
Anecdotally, I removed (by default, it can technically be re-enabled) the ability to use alg:none from the library I provide years ago and never once remember having any request about it at all. I do not see any appeal for cases 1) and 2) either, there is nothing special in a JWS that would require a "null"-JWS be delivered to a third party rather than just delivering the bare payload. And you can always properly sign a JWS and then repackage it if really needed with a different signature later if there is really something important in the metadata of the JWS that would make sense to retain (perhaps AUD or expiration times?) Sounds like a solution in search of a problem with a big foot-gun on the side TBH. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
