My purpose in bringing up the High Risk Certificate Request and the BR that requires that a CA maintain a list of matching criteria to scrub certificate requests with was merely to illustrate yet another criteria upon which GoDaddy and other CAs may legitimately decline to issue a certificate such as the Stripe, Inc of Kentucky one.
It's clear that acceptable practices include scrubbing by "names" of apparently any sort the CA can reasonably justify and use those to apply heightened scrutiny to issuance. I note that no where in that rule is it suggested that the "name" must be a domain label or part of a domain label. So it's not inconceivable that a CA can scrub issuances against names (including in the O= field) it find to be likely to be associated with phishing. I only named Let's Encrypt as an example of a CA that maintains a scrubbing "blacklist". In their case, it appears to require exact match to a label including TLD and TLD+1. I was kind of surprised that they didn't just take all the high value domain names as to the TLD+1 field and decline all combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm sure there's a reasonable case either way. On Fri, Apr 13, 2018 at 3:55 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek wrote: > > > Independent of EV, the BRs require that a CA maintain a High Risk > > Certificate > > > Request policy such that certificate requests are scrubbed against an > > internal > > > database or other resources of the CAs discretion. > > > > Unless you're Let's Encrypt, in which case you can opt out of this > > requirement via a blog post. > > > > -Tim > > As you know, that is not what that post says, nor does it reflect what > Let's Encrypt does. > > The BRs define the High Risk Certificate Request as: > > ``` > High Risk Certificate Request: A Request that the CA flags for additional > scrutiny by reference to internal criteria and databases maintained by the > CA, which may include names at higher risk for phishing or other fraudulent > usage, names contained in previously rejected certificate requests or > revoked Certificates, names listed on the Miller Smiles phishing list or > the Google Safe Browsing list, or names that the CA identifies using its > own risk-mitigation criteria. > ``` > > It also explicitly allows for phishing lists, such as the Google Safe > Browsing list to be used. > > The blog post in question (https://letsencrypt.org/2015/ > 10/29/phishing-and-malware.html) states that Let's Encrypt (rightfully in > my mind) believes that CAs are not the right place to try to protect users > from Phishing. They state this for a variety of reasons, including one > brought up in this thread about making CAs censors on the web. > > They go on to state that despite them thinking CAs are not the right place > to solve this problem that: > > ``` > At least for the time being, Let’s Encrypt is going to check with the > Google Safe Browsing API before issuing certificates, and refuse to issue > to sites that are flagged as phishing or malware sites. Google’s API is the > best source of phishing and malware status information that we have access > to, and attempting to do more than query this API before issuance would > almost certainly be wasteful and ineffective. > ``` > > They have also publicly stated that they maintain a blacklist of domains > they will not issue for. > > Ryan Hurst > (speaking for myself, not Google or Let's Encrypt) > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
