> I think you're imagining some kind of TLS framework that simply doesn't exist currently. It's not clear if you're misunderstanding what exists now, or you're alluding to a different possibility without clearly articulating it.
It's possible that I am misunderstanding it, but it appears that the point of contention is what the server will do when it receives a certificate from the client.
Ideally, it would check if it's valid by checking it against a CA. So, if someone who manages the server signed the CSR, then the server can validate the certificate with a CA that it manages. If it uses a 3rd party CA, then it would validate it using that.
What I'm not sure about is whether a browser can map a particular client side certificate to present to a server based on the server side certificate presented to the client. If it could, then it would be easy to determine whether one has connected to the correct server since the browser wouldnt' try to present the client side TLS cert to the wrong server.
> Even if the site was impersonating something like amazon.com, Amazon hasn't issued client certificates to all of its users so the whole point is moot.
Which was the point of my original post. If we had worked in making the process of generating and using client side certificates more user friendly, then companies would have done so as part of the account creation process (meaning poeople would use their client cert in addition to their username and password as part of the authentication process).
What we have now is major companies like Amazon using SMS based 2FA that would easily be compromised by re-routing the verification code message to another device since that factor is not under my control, but at the mercy of the phone company.