CT is for logging certificates from trusted CAs. Logging certificates from untrusted CAs is out of scope, and can be harmful as untrusted certificates could be used to spam the log until it's unavailable.
Of course, the notion of "trusted" is complicated. These CAs are no longer trusted by up-to-date clients, but out-of-date clients may continue to trust them. The needs of up-to-date clients take priority over the needs of out-of-date clients.
Alice User goes to Bob's Website on the wifi at Eve's Coffeeshop. Can Eve read or inject sensitive information into Alice's browsing session?
Normally Eve's attempts fail because Alice requires a message to be signed with the private key matching the public key in a certificate for bob.example.com signed by a legitimate CA.
Unfortunately Bob bought his CA from Mal's Domains, and Mal is working with Eve for some reason (for example, Mal has been bribed, hacked, intimidated, legally pressured, etc.)
So in addition to Bob's regular on-the-books cert, Mal issues a second off-the-books cert for bob.example.com and gives it to Eve.
With CT, Alice's browser doesn't just require the cert's pubkey, it requires the server to provide a Merkle proof it was included in a CT log.
The CT log puts Eve and Mal on the horns of a dilemma: If they keep their new cert out of the CT logs, Alice's browser won't accept it. If they put it in the CT logs, Bob can read the log himself (it's public) and Bob can say "Hold it! I didn't order this!"
Bob will switch away from Mal as a TLS provider and complain "Hey everybody, Mal issued this cert I didn't order, customers should stop using him and the people who create CA lists for browsers and OS's should closely investigate whether Mal's CA activities are legitimate." Mal can't deny issuing the questionable certificate, the evidence is in public append-only CT logs for everyone to see.
CT is for logging certificates from trusted CAs. Logging certificates from untrusted CAs is out of scope, and can be harmful as untrusted certificates could be used to spam the log until it's unavailable.
Of course, the notion of "trusted" is complicated. These CAs are no longer trusted by up-to-date clients, but out-of-date clients may continue to trust them. The needs of up-to-date clients take priority over the needs of out-of-date clients.
Alice User goes to Bob's Website on the wifi at Eve's Coffeeshop. Can Eve read or inject sensitive information into Alice's browsing session?
Normally Eve's attempts fail because Alice requires a message to be signed with the private key matching the public key in a certificate for bob.example.com signed by a legitimate CA.
Unfortunately Bob bought his CA from Mal's Domains, and Mal is working with Eve for some reason (for example, Mal has been bribed, hacked, intimidated, legally pressured, etc.)
So in addition to Bob's regular on-the-books cert, Mal issues a second off-the-books cert for bob.example.com and gives it to Eve.
With CT, Alice's browser doesn't just require the cert's pubkey, it requires the server to provide a Merkle proof it was included in a CT log.
The CT log puts Eve and Mal on the horns of a dilemma: If they keep their new cert out of the CT logs, Alice's browser won't accept it. If they put it in the CT logs, Bob can read the log himself (it's public) and Bob can say "Hold it! I didn't order this!"
Bob will switch away from Mal as a TLS provider and complain "Hey everybody, Mal issued this cert I didn't order, customers should stop using him and the people who create CA lists for browsers and OS's should closely investigate whether Mal's CA activities are legitimate." Mal can't deny issuing the questionable certificate, the evidence is in public append-only CT logs for everyone to see.