I agree this is a weedy and complex situation. Part of the reason for this existing is the lack of due diligence on CAs in cleaning up how they approach this.
As Kane noted this is only strictly applied where the legal jurisdiction of the CA overlaps. That's an intentional undercount, and even ignores certain CAs who include other legal jurisdictions explicitly in their CPS - for sanctions at that. What is also an undercount is how far back the data goes - this is primarily forward-facing. I tried to design this to be as strict as possible on obligations, and not have any per-CA overrides or extra entities added. As far as exposure goes, the headache I see isn't for the entities such as Let's Encrypt who publish free certificates. It's the CAs who have directly or indirectly taken money for these services, which is a legal nightmare to be in. So much of this is self-inflicted, and why I have been very precise in where the data all comes from, how it is sourced and collated. There are some upstream issues of bad punycode, typos, etc. Those entries aren't included or corrected, and no reports are sent upstream either. I don't expect any quick changes here, but this lets everyone see the current situation. The one thing I definitely have not done is any type of automated Certificate Problem Report on any of this - now that would be a terrible idea.The CSV, JSON and Github commit history should be enough for a CA to get an idea of what other people can see. - Wayne On Thursday, October 8, 2026 at 1:45:24 PM UTC+1 Mike Shaver wrote: > On Wed, Oct 7, 2026 at 9:16 PM Watson Ladd <[email protected]> wrote: > >> Issuance to >> a "sanctioned" entity is a much more complicated issue, with potential >> licenses, disputes over the scope of sanctions, similarly named >> entities, etc. I think avoiding putting these these statements in CPS >> etc. is the way to go. > > > Yeah, I would agree. I think it was a mistake to put sanctions-related > statements in CPS and friends without anticipating those challenges, tbqh, > and would recommend removing them or at least wording them more carefully > to clarify such elements. Wayne's tool can assist CAs who have chosen to > put that language in their policies in conforming to them, until such > changes are made. > > Mike > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/bf21fc32-a111-4cfd-a405-5204209bce96n%40mozilla.org.
