Peter Gutmann <pgut...@cs.auckland.ac.nz> writes: > David Benjamin <david...@chromium.org> writes: > > >Either way I imagine our stack will just keep on ignoring it, so I don't feel > >about this all too strongly. But the topic came up so I thought I'd suggest > >this. > > I ignore it too. Client certs are so rare, and so painful to deploy, that I'm > not going to make things harder on users by adding complex and opaque > filtering to prevent them from working. My approach is to specify as few > constraints as possible, the client submits whatever certificate it has, and > it's then decided based on a whitelist for which the server can very clearly > report "not on the whitelist" when it rejects it. The design seems to be > based on the idea that each client has a smorgasbord of certs and the server > can specify in precise detail in advance which one it wants, when in reality > each client has approximately zero certs, and the few that do have one just > want the one they've got to work.
A typical macOS system will have many issued certs, typically with at most one that will work for any particular web site or web API. So the filter is somewhat important for client certs to work there in any kind of user-friendly way. In particular if the server provides no guidance, the UI will ask the user, presenting a dialog containing many certificates the user is not aware they have, leading to complete user confusion. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
