I think it depends on whether the issue has been fixed or not. If it has not been fixed, then I would say that all CAs need to put a hold on .tg certificate issuance as a priority. If a registry can be compromised, then potentially the integrity of all 10 blessed methods is at risk.
If it has been fixed, then I think revalidating all recent issuances (for some definition of recent) makes sense, and revoking those that cannot be confirmed as legitimate. CAA might have helped in some situations here, for example google.tg doesn't have a CAA record and if it referenced "pki.goog" then it's unlikely an attacker could have gained a valid certificate from that CA. In a lot of instances I expect it wouldn't have helped, because the attacker could just go to the approved CA and request the certificate, and the domain validation would succeed using whatever registry/domain-takeover method was used (unless the CA has extra checkpoints / blocks in place for particular high-profile domains). I note that .tg still doesn't have DNSSEC enabled: http://stats.research.icann.org/dns/tld_report/ This may or may not have helped mitigate the attack for those sites, depending on the technical details. On Saturday, 4 November 2017 19:55:05 UTC, Kathleen Wilson wrote: > This is a new scenario to me -- having a problem at a registry that > results in SSL certs being issued that otherwise would not have been > issued. So I am trying to figure out how to respond to it. For example, > should I send email to only the CAs who are showing up in CT and crt.sh > as having issued SSL certs for the *.tg TLD within the past few days? Or > should I send an email blast out to all CAs in Mozilla's program? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
