Sorry – you’re right Brian. I replied too fast. I was thinking of something
else.
In fact, we removed instances of RSA1_5 from the examples in OpenID Connect as
part of the errata updates.
-- Mike
From: Brian Campbell <[email protected]>
Sent: Tuesday, March 5, 2024 9:40 AM
To: Michael Jones <[email protected]>
Cc: Neil Madden <[email protected]>; JOSE WG <[email protected]>
Subject: Re: [jose] Deprecation of legacy algorithms
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]<mailto:[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]<mailto:[email protected]>> On Behalf Of
Neil Madden
Sent: Tuesday, March 5, 2024 7:57 AM
To: JOSE WG <[email protected]<mailto:[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<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]<mailto:[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
