I read the draft. It's short and to the point, although some of the informative references might be improved, to something a bit more permanent.
Is there any need to comment on JWK, for the RSA part? Does it make sense to ask the COSE WG if they want to do something similar? OS On Wed, Mar 13, 2024, 11:51 AM Neil Madden <neil.e.mad...@gmail.com> wrote: > The datatracker is closed now until after IETF 119 (which I am also unable > to attend), 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 <neil.e.mad...@gmail.com> 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 > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
