Hacker News Reader

Comment by ajross | Hacker News Reader

A client cert can be stored, so it provides at least a little bit of identification certainty. It's very hard to steal or impersonate a specific client cert, so the site has a high likelihood of knowing you're the same person you were when you connected before (even though the initial connection may very well not have ID'd the correct person!). That has value.

But it also doesn't involve any particular trust in the CA either. Lets Encrypt has nothing to offer here so there's no reason for them to try to make promises.

View on HN

Eh, it's pretty easy to impersonate if the values in the certificate aren't checked, and you could get one from any of a list of public CAs.

If you're relying on a certificate for authentication - issue it yourself.

Point being that if you get a valid TLS connection from a client cert, and then you get another valid connection from the same cert tomorrow, you can be very certain that the entity connecting is either the same software environment that connected earlier, or an attacker that has compromised it. You can be cryptographically certain that it is not an attacker that hasn't effected a full compromise of your client.

And there's value there, if you're a server. It's why XMPP wants federated servers to authenticate themselves with certificates in the first place.

If that's all you want to accomplish, you don't need WebPKI. Just generate a private key and a self-signed certificate.

(This is basically how Let's Encrypt / ACME accounts work)

How do I convince the tens of thousands of other servers that my private key can be trusted without some kind of third party trust architecture?

There's DANE but outside of maybe two countries that's impractical to set up because DNS providers keep messing up DNSSEC.

If you are trusting a user since they are the same one that originally contacted you, you don't. It's tofu

I can't believe this was downvoted. Seriously a Certificate is binding a public key and the attributes (mainly the identity). If you don't need to use the attributes, you don't need a certificate!

> This is basically how Let's Encrypt / ACME accounts work

That's how they're implemented. How they "work" is a trivial pushbutton thing as documented by a well-known and trusted provider who cares deeply about simple user experience.

"Just self-sign a cert" is very much not the story XMPP wants their federated server operators to deal with.

Reply on news.ycombinator.com