tl;dr it's not impossible and we can delegate requests.

> If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services.

It's not impossible, and wouldn't even be that difficult, just a few extra steps for LE and the registrar, and one extra step for the domain owner. It would work like this:

Step 1) Domain Owner signs up for a blog on SomeBlogSite.com with their own domain "mycoolrecipes.com" and sets up the DNS record ("mycoolrecipes.com. IN A <sbo IP address here>")

Step 2) SBO wants to gen a cert for mycoolrecipes.com, so they request one from LE.

Step 3) LE goes to the registrar for mycoolrecipes.com and says "Hey, some random blog is trying to get a cert, is this cool? "

Step 4) Registrar sends an e-mail to DO saying, "Hey, is this cool? I know your DNS is pointed at SBO, but I wanted to make sure you actually authorize SBO to handle your security, and not just random network services. Click this link and log in to verify they get the cert."

Step 5) DO logs in to registrar, verifies SBO can have the cert.

Step 6) Registrar notifies LE they can have the cert.

Step 7) LE releases cert to SBO.

This has the effect of 1) removing almost all invisible attacks on cert issuance, because the [delegated] owner has to see and authorize the request, 2) preventing the current need for Certificate Transparency; Registrars could still feed the logs, but CAs wouldn't have to, because the registrar (and domain owner) is the final arbiter, 3) preventing the need for CAA (which doesn't necessarily work anyway and is opt-in), and 4) preventing attacks on DNS from compromising cert issuance.

You can also do this with keys and not e-mails, so that it happens automatically, but only keys authorized by the DO can gen certs. Meaning we have cryptographic proof that only SBO can gen certs for DO, and only with that one CA. Which is way more secure than the current regime. (Again: nobody should be depending on DNS, DNS sucks, and DNS records don't prove domain ownership, nor that you want anything DNS points to at any time to control your security)

> Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois.

For companies with DNS delegation, registrars can provide more fine-grained delegation features, or companies can integrate a DNS management API to delegate authorization of certs. There are at least two open source DNS management APIs (that work independently of who controls the authoritative DNS server) and can control pre-created zones based on users, groups, and access policies. Registrars can make the request for the FQDN to the main domain and the domain can pass it on as needed. So all of that already exists, it would just need one new API function to handle authorizing certificate issuance.

DNS is a hierarchy, so delegating control like this should be expected. Otherwise, use different top level domains.

And schoen is correct, I don't think the BRs are nearly enough. There are security best practices that are going ignored and would catch a lot of the mistakes perpetrated by integration and operation teams.