Most low-cost SSL certificate providers really only verify that you control a domain name. For those types of certificates, rather than pay a third party to verify that I control the DNS records for the domain, why not "sign" the certificate in DNS? If I generate a keypair on a server and publish the same public key in DNS for the hostname, I'd think that would be an equivalent level of security.
I see two problems with the design, but both seem minimal:
- EA certificates and the higher-level certs that verify personal/corporate details can't be done this way. Organizations wishing to pay to get the green bar in browsers are free to continue doing so.
- A malicious network with rogue DNS servers could redirect you to both a different hostname and a different trusted SSL certificate. Perhaps DNSSEC could take care of this repudiation problem?
I'm not aware of any browsers implementing something like this, but it seems like it would be a good method to at least get a trusted, encrypted connection without displaying the dreaded "Untrusted certificate" dialog. Aside from the issues I noted above and existing commercial certification authorities fighting the idea, are there any other reasons doing this would be a bad idea?