This is similar to the case when a server is unable to use its RSA key to sign with PSS passing (my slides for TLS WG in 2015 https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented by Eric), but instead this is about client keys/signatures.
I don't have a stake in this currently, but I understand the problem. In both cases the only current solution is to not negotiate TLS 1.3. On Tue, Oct 24, 2023 at 5:48 PM Andrei Popov <Andrei.Popov= 40microsoft....@dmarc.ietf.org> wrote: > Hi TLS, > > > > We would like to re-introduce > https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ > > (it’s intended for the TLS WG and the Standards track, despite what the > document says at the top; we’ll fix it as soon as the submission tool > reopens). > > > > In the course of TLS 1.3 deployment, it became apparent that a lot of > hardware cryptographic devices used to protect TLS client certificate > private keys cannot produce RSA-PSS signatures compatible with TLS. > > This draft would allow RSA-PKCS signatures in the client CertificateVerify > messages (and not in any other contexts), as a way to unblock TLS 1.3 > deployments. > > This is an unfortunate situation, and work is being done with hardware > vendors to reduce the likelihood of similar issues in the future, but > existing devices tend to stay around for years. > > > > Comments/suggestions are welcome, > > > > Cheers, > > > > Andrei > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
