|
|
|
|
|
|
by bvanderveen
1072 days ago
|
|
|
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? |
|
|
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.