While this is been said many times before, it seems that it's time to say it again. The last point in the Message Signature or MAC Validation section at https://www.rfc-editor.org/rfc/rfc7515.html#section-5.2 is:
"Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid." "alg":"none" can only cause a problem if the application fails to validate whether the algorithms used are appropriate for use by the application in that context. The need to validate whether "alg":"none" is appropriate is no different than the need to validate whether use of RSA1_5 is appropriate. An ID Token using "alg":"none" sent over a TLS connect is fine, because TLS makes it tamper-proof. As it says at https://openid.net/specs/openid-connect-core-1_0.html#IDToken: "ID Tokens MUST NOT use "none" as the "alg" value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of "none" at Registration time." The context where the algorithm is used matters. In the above usage, "alg":"none" is safe and appropriate. The issues that have happened only happened in applications that didn't implement the algorithm appropriateness check in Section 5.2. If they're not doing it for "none", they probably aren't doing it for any algorithms, and so the application would still be vulnerable to using obsolete algorithms even if we deprecated "none". Fix the broken applications. Don't remove essential functionality that's been a standard for nearly a decade and has been in production use longer than that. -- Mike -----Original Message----- From: jose <[email protected]> On Behalf Of Manu Sporny Sent: Tuesday, March 5, 2024 1:46 PM To: Neil Madden <[email protected]> Cc: JOSE WG <[email protected]> Subject: Re: [jose] Deprecation of legacy algorithms On Tue, Mar 5, 2024 at 10:56 AM Neil Madden <[email protected]> wrote: > RSA1_5 - currently marked as Recommended- in the IANA registry. +1 to deprecate (or go further, MUST fail to verify for software released after 2023). > none - I'm not sure there has actually been a year where this algorithm > *hasn't* caused a vulnerability. +1 to deprecate (or go further, MUST fail to verify for software released after 2023). > I would also like to write a draft (either combined with the above or > separate) that establishes some baseline security properties for future > algorithm registrations: +1 -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/ _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
