Is the concern here errors or prompting? From the original email, it sounded like the issue was that requesting client certificates showed undesirable UI to human-backed clients.
That one is a bit harder to avoid since no one is acting incorrectly per se. Clients for humans need to ask the human for consent before revealing identity information. They also need to be mindful of things like background contexts, in which prompting isn't possible. Also some platforms are such that querying for certs and prompting is one operation, which limits the solution space. All this together means that optional client certificates, for HTTPS services that are accessed by humans, basically does not work, even though everything works fine at the protocol level. Really the problem is that authentication for robots and authentication for humans have different UX requirements. But we're kind of stuck because this particular mechanism, years ago, got used for human authentication despite not actually being terribly suitable for it. On Tue, Oct 24, 2023, 12:37 Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Tue, Oct 24, 2023 at 04:11:53PM +0000, Andrei Popov wrote: > > > > 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... > > Sadly, that's not what actually reliably happens in practice, or at > least that was the case when I last looked. > > Perhaps all the guilty TLS stacks were fixed in the meantime? I am not > well placed to determine how much "friction" remains. > > -- > Viktor. > > _______________________________________________ > 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
