Right now, a CA can issue a certificate for any public key and domain they like. A rogue trusted CA can intercept all traffic.
If a certificate also included a signature by the owner of the public key signed by the CA (using their private key, signed over the CA signature), then a CA would no longer have this ability.
What am I missing?
Infrastructure and processes for key distribution and revocation. Reusing the existing PKI infrastructure used for CA trust roots won't handle it. Perhaps public keys/certs could be distributed over DNS, like for DANE (or maybe even using DANE)?
Not saying it can't be done, just to point out how it's not trivial and requires buy-in from incumbents across the ecosystem.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
I like your general idea of improving the status quo by adding decentralized/self-managed trust on top of/alongside the existing centralized PKI. Could be a stepping stone towards something more systematically resilient.
I'm not sure it would make much difference to most of the existing PKI infrastructure though. CAs wouldn't see any difference. For example, currently this is what happens:
1. Owner: generate CSR and send to CA 2. CA: validates owner identity, signs cert and returns cert to owner.
All we would then add is:
3. Owner: signs cert with own private key and uses it.
As far as I can see, the only other changes required would be to clients (so they could reject non owner signed certs), and maybe some revocation stuff.