I realized I used the word "context" in two different, uh, contexts, so that was probably very confusing.
What I meant to say is that TLS client certificate decisions need to be remembered session-wide, for some appropriate notion of session. So browsing profile or something of that nature. But within that scope, some contexts are capable of prompting (user-visible tab) and others are not (a service worker script, or a tab in the process being closed). It would be a problem for the latter to poison the former, but they also rather thoroughly share an HTTP session. It's a mess. Client certificates are the bane of my existence. :-) On Tue, Nov 7, 2023 at 10:46 PM David Benjamin <david...@chromium.org> wrote: > On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: >> > >> > - Some Java TLS libraries (used to?) fail the handshake when the >> > client has no configured certs, or the list of issuer CA DN hints >> > does include any of its available (typically just zero or one) >> > certificates. >> > >> > They could just proceed without a certificate, or return a default >> > one, but they don't. >> >> A colleague discovered a case where sending CertificateRequest to Chrome >> causes it to fail, instead of just proceeding without a certificate >> (which would have worked). >> > > I don't know the details of that case, but this would not surprise me. If > we are in a context where we are unable to prompt the user (e.g. in a > background context where we cannot show UI), that is the only viable > option. TLS client certificate decisions in a browser, and generally in an > HTTPS stack, have to be remembered context-wide. Otherwise we cannot do > socket reuse or session resumption, and have to prompt the user on every > HTTP request. > > But even continuing without a certificate is a decision. That means, if we > automatically proceed without a certificate in unpromptable contexts, we > poison the context and prevent the user from making an actual decision > later. Moreover, this can even apply when there are zero matching > certificates. On some platforms (e.g. Android), where the platform's > security model (quite reasonably) prevents applications from directly > enumerating the client certificate store, querying and prompting is a > single combined operation. But this means we cannot even check for zero or > non-zero certificates without triggering a prompt in the non-zero case, > which again means we cannot trigger this code from background contexts. > > Moreover, on such platforms, the application is entirely at the mercy of > the platform as to what kind of filtering or prompt suppressions are > applied. On older Androids, this single combined operation does not > automatically suppress empty prompts, and does not filter based on the CA > list. Newer ones are capable, but it further makes optional > CertificateRequests incoherent. > > Ultimately, TLS client certificates, and how they're used in practice, > are just not suitable for user-facing HTTPS applications. But there is such > a long history of existing usage, that the ship has not only sailed but > also circumnavigated the globe a couple times. It's too late to simply say > "oh this was a mistake, let's not do that anymore". :-( > > David >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
