Google engineers have been very heavily involved in the CA/Browser Forum (https://cabforum.org), which sets issuance and trust rules for CAs. One of the things the CAB Forum is currently debating is a set of requirements mandating certificate transparency (CT) and obeying certificate authority authorization (CAA) records in DNS.
If implemented for all of these roots (and I don't see why they wouldn't, given their push on it), CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. CAA, as a complement, would create a method by which you as a domain owner could control which CAs are allowed to issue certs for your domain, removing the ability to man-in-the-middle your domain without your permission.
The first step for both of these is making them mandatory for CAs (which Google is pushing hard on); once they're out there, it's possible to write plugins that will check CAA and CT records and fail closed if something looks wrong. It's a long way from perfect, but it's definitely a step in the right direction. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these.
CT would create an open, unalterable record of
every cert published from all of these roots
and their subordinates.
That provides no substantiation for Google's push to be a Certificate Authority (CA). It arguably makes a case for Google to be a "Log Server" (which has its own troubling implications as that could then (now?) hook Google into the verification process of every certificate issued[1]). But absolutely nothing about CT needs/implies/warrants Google to become a CA.
Given Google's strong push for making those
mandatory, I'm far more worried about a lot
of the CAs already in my trust store than I
am about these.
The very authority to which you are appealing is precisely the one which is suspect.
During the TLS handshake, the TLS client receives
the SSL certificate and the certificate’s SCT.
As usual, the TLS client validates the certificate
and its signature chain. In addition, the TLS
client validates the log’s signature on the SCT ...
For CAA to work, we need fully deployed DNSSEC. Not just the roots, and some resolver, but all local clients too. Otherwise, there's still weak links in the chain.
If implemented for all of these roots (and I don't see why they wouldn't, given their push on it), CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. CAA, as a complement, would create a method by which you as a domain owner could control which CAs are allowed to issue certs for your domain, removing the ability to man-in-the-middle your domain without your permission.
The first step for both of these is making them mandatory for CAs (which Google is pushing hard on); once they're out there, it's possible to write plugins that will check CAA and CT records and fail closed if something looks wrong. It's a long way from perfect, but it's definitely a step in the right direction. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these.