RSA1_5 : +1 to deprecate itnone: I'm unsure about this one. The none algorithm is the only algorithm that's guaranteed to be safe from cryptographic vulnerabilities :)
Vladimir On 05/03/2024 17:56, Neil Madden wrote:
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
