But isn't the point here (and a source of confusion I share with all the other posters) that DNS is the actual root of trust? Heck, forget DNSSEC even, because it's not like Let's Encrypt demands it. You say that LE verifies
>that you control the domain you are requesting a certificate for
but it mostly seems to do it the exact same way any random person browsing to an HTTP site would: it checks the DNS records. It's not like there's an out of band channel here where they actually verify business records separately or something. So what exactly is the value of the middle man in this? Why not just have public sigs in the DNS records too? When DNS is the root of trust anyway and "Certificate Authorities" are reduced to fully automated systems, what value to "Certificate Authorities" even bring anymore in this context? It seems like a hack from a time when CAs were expected to provide some out of band verification that would actually be useful. But on the web that mostly hasn't happened or has been rendered moot (witness the death of EV).
I can see how central CAs could still be useful in many other circumstances. But for anything where control of DNS directly correlates with control of the entire chain, it seems like it'd be a lot better to just decentralize into DNS.
The value of certificate authorities is to be the roots of trust, as said.
The exact same applies to using DNS as chain of trust. You have to start with a well-known root of trust because it's impossible to know all the DNS servers or registrars out there. In fact that's exactly how DNSSEC works.
It seems that the question is whether DNS and HTTPS certificates are converging to provide the same service. Perhaps, though I'm not sure, but that wouldn't change the system fundamentally.
>The value of certificate authorities is to be the roots of trust, as said.
But they aren't, DNS is. That's my question. If someone controls my domain, they can point it wherever and get all the Let's Encrypt CA signed certs they want. So how exactly is the CA being a root of trust there if the CA itself is basing trust off of domain control? In neighbor comment it seems that maybe the CA is basically acting as a hack to bypass an inability by clients to check DNS? I can see why that would have some practical value in the near term but it'd be good to do away with it as soon as possible. Apple/Google/Microsoft (and maybe Mozilla) may be in a position to do so if no one else.
You're discussing how to prove to Let's Encrypt, or anyone else, that you are the legitimate owner of a domain.
That does not mean that I know or trust Let's Encrypt. The root of trust is an entity I know and trust and which can vouch for Let's Encrypt, which can in turn (or not) vouch that you are the legitimate owner of a domain.
The same applies to DNSSEC. The root of trust being the root servers.
>that you control the domain you are requesting a certificate for
but it mostly seems to do it the exact same way any random person browsing to an HTTP site would: it checks the DNS records. It's not like there's an out of band channel here where they actually verify business records separately or something. So what exactly is the value of the middle man in this? Why not just have public sigs in the DNS records too? When DNS is the root of trust anyway and "Certificate Authorities" are reduced to fully automated systems, what value to "Certificate Authorities" even bring anymore in this context? It seems like a hack from a time when CAs were expected to provide some out of band verification that would actually be useful. But on the web that mostly hasn't happened or has been rendered moot (witness the death of EV).
I can see how central CAs could still be useful in many other circumstances. But for anything where control of DNS directly correlates with control of the entire chain, it seems like it'd be a lot better to just decentralize into DNS.