[cestith]

You're familiar I'm sure with your browser authenticating that a TLS certificate is within its valid date range and assigned to the hostname of the server? You're probably also aware that your OS and/or browser have a list of certificate authorities one of which must have signed the certificate (or via a chain of CAs from a trusted root, with each CA cert signed by one closer to the root). Client certs work the same way except it's the server verifying all of this for the client (browser, mail user agent, whatever).

At $work we have several systems in which the server only accepts requests, or only accepts certain kinds of requests, from clients with client certificates with specific restrictions. Depending on the application and its authN/authZ needs, any of the solutions I'm about to mention might be combined with some combination of a username/password, with a time-based token, a JWT, IP range restrictions, an API key, or whatever else in addition to the client cert requirement - or sometimes the cert is sufficient by itself. Some just trust anything that was issued by the right CA and is in its proper date range. Sometimes we also verify that the certificate matches an assigned hostname of the client. Sometimes we trust certs by the right CA to connect, but parse the hostname out of the cert and check whether that client's hostname or the subdomain it's in has authorization to do certain things. Semantic hostnames might look long and confusing at first, but they can be used very easily for things like that. Semantic host names and naming schemes could be its own article.

This isn't a general use case for the general public because of deployment headaches. Which CAs do we trust? Is it the same as those issuing server certs? Will services be set up especially to issue client certs? Who's supporting the users to get the certs installed, many of whom enter the wrong email when signing up for services? We can do this in a corporate network pretty easily. We have automation systems for servers. We have another, different automation system for administration of Laptop, desktop, and mobile client devices. We just put what cert we want everywhere we want it.

A big problem I see with client certs and the general public is multi-device users. If you're logging into Google from your home desktop, your work desktop, a couple of laptops, a tablet, and a phone that's one email address but half a dozen different certificates. Some applications, especially cross-platform ones, insist on their own certificate store even if the OS provides a shared one. So for mail, a couple of browsers, and two other native apps, congratulations that's maybe two dozen. One can export and import client certs, but there's no simple way to get less technical end users to do that. So do we make it easier to configure multiple client devices and all their applications with the same certificate and key? Are end users going to remember to update them all when one is lost in a breach or it expires? Or do we expect all the service providers to trust multiple certificates signed by multiple different CAs for each user, then have the user upload the public (but not the private!) part of each cert/key pair to all of those services to say they should be trusted? Or does every service require its own CA to sign your cert for its own service, so you need an Apple cert, a Google cert, an Amazon cert... ad nauseum?

Tools like Bitbucket or Gitlab let you upload your public SSH key in the web UI to provide auth for the git repos. You can also have (hopefully with separate keys) automated applications that interact with git auth against a repository or all the repos in a project. That's the sort of interface one might expect a web application to offer for TLS certificates. *

* A certificate is basically the public key portion of a public/private key pair that's been signed by some CA. Preferably that CA is a broadly trusted one, except in very particular circumstances.

[bo1024]

Thanks, this explanation and discussion is very helpful. It does confirm how I suspected things to work.

I have trouble understanding the need for the "signing" part of client-side certificates. Currently if I create an account at a website with a username/password, there's no need to get my account signed by a trusted third party. So why not let me create the account with a username/publickey instead? Why does a third party CA need to be involved?

And actually (as I mentioned in another post just now), one thought is to have keypairs supplement passwords rather than replace them. Basically when I move to a new device, I can still log in to the website with a password, and then the site will give me the option to add the device's public key so I can seamlessly log in automatically next time.

[0xCMP]

Ideally they would run some kind of CA and users would generate keys local to the device with some kind of alternate authentication when setting up the device initially.

Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.

When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.

[cestith]

> Ideally they would run some kind of CA and users would generate keys local to the device with some kind of alternate authentication when setting up the device initially.

This presents a bit of a chicken and egg problem for how to secure the initial signup. Most services now use "control of email address" which has its own issues.

> Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.

There are concerns about tracking, but that can be done without a private key. There are pros and cons for both singular and multiple keys one of the pros for a single keypair being your keypair does identify you as you. That's bad for tracking but it's good for more trustworthy authentication. Ideally, for some uses you could as a person get a signed personal cert and it'd be as good as government ID.

> When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.

A good first step for reused or unique-per-service or even unique-per-service-and-device keypairs would be to allow a user authenticated by password or whatever to upload a public cert (possibly via web form) and enable access to the account (or portions of the account) going forward only to sessions initiated with that client cert and key.

S/MIME handles some issues of key propagation pretty simply in that a sender, A, signing a message is sufficient for the recipient, B, to then send encrypted email to B. The initial S/MIME installation of the user's own S/MIME certificate is still more involved. However, it might be as simple with web apps and other apps that use a web or web-like remote API to have an option to auto-trust certs going forward that are used to log in to the account by other means (like password and Yubikey).