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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
