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

Reply via email to