The JWE RSA1_5 alg is not required for OpenID Connect as far as I know? On Tue, Mar 5, 2024 at 9:39 AM Michael Jones <[email protected]> wrote:
> I would not support deprecation of either of these algorithms. They are > both required for OpenID Connect and are in extremely widespread use. > > > > *From:* jose <[email protected]> *On Behalf Of *Neil Madden > *Sent:* Tuesday, March 5, 2024 7:57 AM > *To:* JOSE WG <[email protected]> > *Subject:* [jose] Deprecation of legacy algorithms > > > > Hi all, > > > > Leaving aside all the exciting work on shiny new algorithms to *add* to > JOSE, I would like to raise the prospect of deprecating some existing > algorithms that have passed their best. Before I start work on writing the > drafts for these, I'd like to gauge if there is some support or this is > likely to be wasted effort. The algorithms I think that should be > deprecated are: > > > > RSA1_5 - currently marked as Recommended- in the IANA registry. PKCS#1 > v1.5 padding for encryption has been a source of repeated vulnerabilities > over the years, and they keep cropping up. I believe the main reason this > exists at all was to allow continued use of legacy hardware, in particular > where FIPS approval was required. However, PKCS#1 v1.5 padding has been > forbidden by FIPS (for encryption) since the end of this 2023 [1]. If > someone is really stuck with a hardware device that only supports this > encryption mode then they can use it to encrypt local files containing keys > for other algorithms rather than using it directly. > > > > none - I know this one is more controversial in some quarters, but > alg=none has been responsible for a steady stream of serious security > vulnerabilities, and even spawned its own website: > https://www.howmanydayssinceajwtalgnonevuln.com. I'm not sure there has > actually been a year where this algorithm *hasn't* caused a vulnerability. > I've yet to see a genuine use-case for it in the wild. The pain:gain ratio > on this algorithm is extremely high. > > > > 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: > > > > * All signature algorithms MUST achieve unforgeability under chosen > message attack (EUF-CMA). > > * All encryption algorithms MUST achieve at least IND-CCA2. > > > > [1]: > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf > (see > table 5 on page 15) > > > > Thoughts? > > > > -- Neil > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- _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] https://www.ietf.org/mailman/listinfo/jose
