[schoen]

> At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

An interesting problem in this design is how to persuade users that they've encountered something genuinely important that it would be helpful for them to tell someone else about. (Maybe browsers can store such questionable certificates offline and gossip about them to other TLS servers later.) It's not very common for people to be persuaded that errors on their computer matter and that other people will care about them... but this one does! :-)

I know HPKP has a report method which one could imagine generalizing somehow to CT inclusion failures, but, in many attack scenarios involving use of misissued certs, the victim's network connection is controlled by the attacker. In that case, the attacker will probably not want to allow the victim to report the attack to another server in real time.

[castillar76]

Interesting idea! I know the CT spec recommends that clients archive CT data received for later review, and it defines the concept of a CT 'auditor' that constantly reviews the logs from CT log servers looking for malfeasance. It would be interesting and very useful to amalgamate anonymized data from browsers into one of those auditors and crunch through it to compare to CT records.