> Le 13 mars 2024 à 12:51, Neil Madden <[email protected]> a écrit : > > The datatracker is closed now until after IETF 119 (which I am also unable to > attend),
s/until after/until the beginning of/ Marc. > but I have created a draft for deprecating these algorithms that I intend to > submit when it re-opens. > > Working draft: > https://neilmadden.github.io/jose-deprecate-none-rsa1_5/draft-madden-jose-deprecate-none-rsa15.html > Git repo: https://github.com/NeilMadden/jose-deprecate-none-rsa1_5 > > -- Neil > >> On 5 Mar 2024, at 15:56, Neil Madden <[email protected] >> <mailto:[email protected]>> 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 >> <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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
