There are many .COM registrars so I'm not sure what you're getting at. Obviously we are trusting the .COM TLD operators to have implemented appropriate ACLs in

There are many .COM registrars so I'm not sure what you're getting at. Obviously we are trusting the .COM TLD operators to have implemented appropriate ACLs in the .COM database so that registrars can't meddle with other registrars' domains. And if they haven't, well, we're back to square one: External CAs use DNS to verify domain ownership, which is silly and insecure; meanwhile the .COM zone knows who is the registrar for any given domain, and the registrars know who is the owner of a given domain. If we can't trust the .COM operators to manage their accredited registrars properly then YES we need to distrust all of .COM, because then anyone could get a cert for any .COM by way of a single shady registrar. This trust is already a prerequisite for today's CA system. I am simply suggesting putting additional limits in place so that instead of trusting the .com TLD ops AND the relevant registrar AND all of the CAs in the world, we merely need to trust the .com TLD ops and the relevant registrar. It is strictly a subset of today's trust circle. Edit to add: today we are paying and trusting CAs to verify domain ownership by way of insecure DNS lookups (and then email tokens or http challenges). This is absurd because domain ownership is already positively definitively proven in the registrars' customer databases and the TLD's registrar database Edit2 to add more: The entire SSL CA ecosystem security hinges on the single web form for modifying NS records for a given domain at a given registrar for a given TLD. If you have access to modify the NS records you have all you need to get a certificate. So: This particular web form is where we should put a button to download SSL certificates. And, we should engineer clients to verify that certificates are issued only from that particular source (registrar at a registry). And get rid of external CAs.