[bvanderveen]

Can anyone explain to me why we couldn't just use client SSL certs everywhere? Before the first time you connect to a website, your browser asks if you want to generate a new cert or reuse an existing one, you make a choice, and from then on you interact with that site as an identity tied to that cert and you're done. From the servers point of view, the user's identity is a key fingerprint, which is just a property of the connection. Why is it more complicated than that?

Oh right, the benevolent overlords, in their wisdom, discerned that mere mortals can't be trusted with private key material.

Nevermind, move along.

[growse]

Conceptually, this is exactly how webauthn works. Except your identity is always per-site, and the site itself stores your per-site secret, encrypted by some mechanism you control (HSM or whatever).

[rokkitmensch]

The centralized PKI isn't ready yet, but the day the USG is able to generate your private key for you at birth and then sign your daily driver with it for you on demand, that's the day we get client side certificate authentication.

[minebreaker]

FAPI standardizes an OIDC extension for client authentication using mTLS, so I don't think there's anything wrong with it.

[u801e]

> Before the first time you connect to a website, your browser asks if you want to generate a new cert or reuse an existing one, you make a choice

The server has to have some way of verifying your certificate. The workflow I would like to see is that the server runs its own CA that it uses to sign client certificate signing requests and then uses that CA to verify any client side certificate presented. If combined with a username and password, it would effectively be 2FA without a shared secret (outside of TLS connection negotiation).

[bvanderveen]

What benefit would the site operator see by running a CA and requiring clients to do that dance vs allowing self-signed certs?

[u801e]

The same benefit we get by using the external certificate authority to verify that I'm connecting to a certain website and not some fraudulent version of it.

To put it another way, the benefit I get by having my computer verify that I'm connecting to news.ycombinator.com and not some fraudulent website is so that I don't inadvertently transmit my account credentials to a scammer.

The benefit news.ycombinator.com gets by verifying a client certificate I send them is that they can verify that the user u801e is establishing a connection to them and not some scammer who happens to have my account credentials.

Those benefits are lost if either the server or client sends a self signed certificate, because there's no one who we can use to verify the authenticity of the certificate. The reason using an external CA is not needed on the server side is, in my opinion, because the server is the one who's handling the account creation, so it doesn't need an external authority other than itself to verify whether the certificate is valid. If the server just accepted a self-signed certificate, then how does it verify that the certificate is valid?

[bvanderveen]

In my imagined system, there's no need for the CSR dance because hey, if the client can sign the crypto challenge and initiate a connection, then it holds the private key material associated with this certificate/account and they own it, and that's that.

My mental model is basically like SSH-ing into a box. All the client does is pin the server's public key fingerprint and moan if it changes. The only additional element is an affordance where the box would essentially allow all comers to create a user account and a corresponding `~/ssh/authorized_keys` with their pubkey in it.

In the web-app, of course it's not making unix user accounts, but it's associating the self-signed cert with a user account (how ever that might be implemented) the first time it sees a new cert. Whoever shows up with that cert in the future is automatically 'logged in' as the corresponding user account.

So, genuine question, what does it mean for the client cert to be potentially invalid? What could lead to that case in the system you're imagining? Under what cases would you either a) not grant a CSR in the first place or b) revoke a cert your CA signed?

[u801e]

> if the client can sign the crypto challenge and initiate a connection

How can the server verify it's the same client signing the crypto challenge with the same private key?

> what does it mean for the client cert to be potentially invalid?

The certificate's signature cannot be verified. Assume a client decides to create a certificate and send it as part of the TLS connection negotiation. The server would reject it because the signature on that certificate isn't valid since the server CA did not sign it.

> What could lead to that case in the system you're imagining?

Someone who's trying to access my account (assuming news.ycombinator.com requires a client side TLS certificate as part of the authentication process) tries to forge the client side certificate. If the certificate is self signed, how will the server know it's from me versus someone else? How do we maintain the association between a particular client and a key pair?

> Under what cases would you either a) not grant a CSR in the first place

For someone creating an account, there would be no reason to reject the CSR. For someone trying to add another device with a different key pair under the same account, not being able to show they have access to the first device would be a reason to reject it.

If we're talking about an account at a bank, a CSR could be rejected if the person is unable to establish that they're the actual account holder (through some form of out of band authentication like a bank official checking my drivers license and passport).

> or revoke a cert your CA signed?

If someone decides to delete their account, then revoking the certificate used as part of the authentication process would be the appropriate course of action.

[bvanderveen]

> Someone who's trying to access my account (assuming news.ycombinator.com requires a client side TLS certificate as part of the authentication process) tries to forge the client side certificate. If the certificate is self signed, how will the server know it's from me versus someone else? How do we maintain the association between a particular client and a key pair?

I could be deeply erroneous in my understanding of X.509 but I am pretty dang sure that a self-signed cert would in fact provide that guarantee.

All certificates (self-signed or otherwise) have an associated private key. In the case of a CA-signed cert, the CA never sees the private key of the cert it's signing. So in your scenario, the server can know it's you and not someone else (assuming you kept your private key secret…) because in establishing the connection, the client signed a challenge that only the holder of the certificate's private key could correctly sign. Whether the cert is signed by a CA or self-signed doesn't change this property.

The CA-signing doesn't provide the property of unique identity—public key crypto does that already. CA-signing just provides a "chain of blessings" that gives the peers on the connection a heuristic for determining how much they should trust the identity on the other end of the line.

Unless I'm wildly mistaken!

[snowstormsun]

Certificates also need to be rotated at some time.

[BlackFly]

Yes, just like passwords need to be rotated at some point. Of course in 2023 people have already reconsidered what the practical effect on security of that policy was as opposed to the theoretical effect. Perhaps client certificate rotation would be as unnecessary as password rotation for similar reasons or perhaps automation like for server certificates could be used for similar reason.

[akira2501]

the acme protocol handles this. is there space for an 'email-01' or similar mechanism for client certificate verification?

[growse]

Why are we desparate to jam X509 into every hole, regardless of whether or not it's a good idea?

mTLS for most cases is not a good idea. For the masses, it's certainly not a good idea.