> At least as a client, you can't read anything into seeing a cert request from > the server, it's just a standard part of the handshake, like a keyex or a > finished. This is exactly my argument: when a client receives a cert request the client cannot satisfy, the RFC says send an empty Certificate and continue with the handshake...
-----Original Message----- From: Peter Gutmann <pgut...@cs.auckland.ac.nz> Sent: Monday, October 23, 2023 7:41 PM To: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Request mTLS Flag Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org> writes: >Yes, but, arguably, such broken clients won't be fixed by adding new >extensions/flags/etc. If they do not comply with the simple RFC >language that exists, can we expect them to implement the new flag correctly? I would argue that it's the server that's broken, not the client. An awful lot of (non-WWW) servers automatically request a client cert without anyone running the server being aware of it, or when asked, how to disable it. The clients then sleepwalk their way past it with a zero-length reply and things continue as normal with neither the server admin nor the client-side user being aware that certificate auth was requested and denied. At least as a client, you can't read anything into seeing a cert request from the server, it's just a standard part of the handshake, like a keyex or a finished. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
