Hacker News new | ask | show | jobs
by xorcist 2 days ago
> I trust governments much less that a conglomerate of competing corporations

Let's not create a world wide PKI based on a political ideology.

> country-issued certificates [...] every government will absolutely double-issue certificates

This is such a strange argument. If you register a .ru domain, do you really think you are safe should the Russian intelligence services ask for a valid certificate? Controlling the actual domain, they could issue ask many domain validated certificates as they wish.

The problem with our current SSL PKI, as so very many people have pointed out over the years, is that any CA is allowed to issue valid certificates for any domain name. There have been proposals to use X.509 extensions to remedy this, but they have seen lesser real world usage than the various certificate revocation schemes, which is very close to zero already.

If there was no way for a Russian CA to issue certificates for .us domains, real world security would improve. A lot. And the other way around, of course.

Feel free to s/Russian/Chinese/ in the above argument or whatever tickles your geopolitical fancies. The argument still stands.

Domain registries decide who owns what domain. That is their literal role. You would think that asserting this ownership cryptographically would be a no-brainer in 2026. Yet we have this discussion over and over again. There are many people whose income quite literally depend on the status quo of our global SSL PKI, which coincidentally also offers no end of possibilities for the various intelligence services around the world.

The next time someone tries to scare you with that governments or intelligence services control DNS and therefore it would be crazy to limit issuance of certificates to them, take a look where they have contracts.

1 comments

> The problem with our current SSL PKI, as so very many people have pointed out over the years, is that any CA is allowed to issue valid certificates for any domain name. There have been proposals to use X.509 extensions to remedy this, but they have seen lesser real world usage than the various certificate revocation schemes, which is very close to zero already.

Some of the browser root programs include (or have included) restrictions on what tlds a CA is allowed to sign. I think for some of the iffier CAs that nonetheless had a huge marketshare in their country of origin.

No need for the CA itself to include it in their root certificate.

It would be handy if the name restrictions actually worked though. Then you could probably get a CA to sign an intermediate CA authorized only to issue certs for your domain(s). There are some CAs that will do that already where they provide an HSM with the intermediate CA's key that will only sign certs for authorized domains, but the CA cert does not encode the constraint and this is permitted by the ca/b agreement. It just seems like it'd be nicer if it just worked.

Unfortunately the CA/B Forum has high requirements for constrained subordinate CA certificates[1], which to me sounds a lot like regulatory capture.

[1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...

It's not that high of a requirement. The sub-CA is allowed to self audit. But the original CA does have to check a percentage of certificates issued by the sub-CA.

So that's not going to be free. But it might be possible to do it if you were big enough to pay for it. I have dreams of having my private CA also signed off on by webpki so apps and browsers could use the same servers without having to include webpki in my apps.

Not that I really work on such things anymore.

I also started going down this rabbit hole when I wanted my homelab to just work in any device, and for advanced use cases Let's Encrypt isn't enough. I tried long and hard to get a sub-CA certificate, but apparently that's in the realm of «if you need to ask, you can't afford it».
Yeah, not gonna happen for a homelab. Need to be a big company so that it might be worth spending the money.