What you've stumbled into is the unspoken truth that CA's want to have their 
cake and eat it too.

Specifically, they market themselves and their products under the umbrella of 
security: "You want to be secure on the Internet, right? We can help you do 
that!"‎ Then, most all CA's will turn around and say: "Oh by the way, if you 
encounter a situation in which something bad happens it's not our fault because 
we couldn't possibly ‎confirm that what we say is secure is in fact secure."

Let's Encrypt is not unique as I think most CA's express this viewpoint in one 
form or another. This may be acceptable from a legal or compliance standpoint 
but not in terms of reputation. As people find themselves in bad situations 
because of a malicious site that used one of their certs, they very well might 
blame the CA.

Certainly a CA does not want the reputation of being "the preferred cert vendor 
for malicious sites everywhere" so whatever principles they try to espouse, the 
reality will be more complicated.


  Original Message  
From: wuyi via dev-security-policy
Sent: Friday, February 24, 2017 1:57 AM
To: vtlynch; dev-security-policy
Reply To: wuyi
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist

Exactly that’s the meaning of “entitle”.
Based on the interpretation, I understand that when a firefighter is on a 
vocation, even a fire breaks next to him, it’s of his choice to go hiking, fly 
kites whatever as he may only be entitled on weekdays rather than in a 
vocation. 
IMO, the point of the Let’s Encrypt’ CP 9.6.3 is to ensure that the CA has 
privilege to revoke certificate when certain issue happens as it describes. The 
deeper meaning of it is that it ensures the CA has ability to maintain online 
security anytime, but it’s enough. I am not going to debate here, I would 
rather go and teach my grandfather those green lock icons from some certain CA 
means anything but online security they states. 
Nio 
SZU


发自我的iPhone

------------------ Original ------------------
From: Vincent Lynch via dev-security-policy 
<dev-security-policy@lists.mozilla.org>
Date: Fri,Feb 24,2017 15:10
To: dev-security-policy <dev-security-policy@lists.mozilla.org>, wuyi 
<594346...@qq.com>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist



As you have quoted it, Let's Encrpyt's CPS says:

"the CA is *entitled* to revoke the certificate"

The key word is "entitled." Meaning that Let's Encrypt may revoke the
certificate if they chose, but are not required to. Therefore not revoking
the certificate is compatible with their CPS.

It's important to realize this is not an argument about what *should* be
done or what we think is right, but what *can* be done under the current
rules and regulations.

The fact is that the CAB/F BR's are so (intentionally) ambiguous about
"high risk" certificates that there is no real way meaning to that section
and no real way for a CA to violate said section.




As others have mentioned, please can we stop writing unrelated comments on
this thread. This thread is about a specific report about a DV cert being
issued to a non-existent domain. That report turned out to be false. Unless
comments are about that report, this is the wrong thread to post in.

I would also encourage anyone interested in the topic of high risk requests
and certs being issued to phishing sites to see Eric Mill's comment in this
thread. He has provided a link to past discussion on this topic, and I can
promise you that however displeasing and shocking this practice may be, it
has already been considered and debated.



On Fri, Feb 24, 2017 at 12:36 AM wuyi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> According to what I’ve known,
>
>
> “Acknowledgment and Acceptance: An acknowledgment and acceptance that the
> CA is entitled to revoke the certificate immediately if the Applicant were
> to violate the terms of the Subscriber or Terms of Use Agreement or if the
> CA discovers that the Certificate is being used to enable criminal
> activities such as phishing attacks, fraud, or the distribution of
> malware.” (Let’s Encrypt’ CP 9.6.3)
>
>
>
>
> Now that a phishing site has been detected with a valid certificate, but
> no immediate action was taken on it. I don’t think that this is what a CA,
> who states to “Support a more secure and privacy-respecting Web” is
> supposed to do.
>
>
>
>
> Quoted from Google’s Policy, “it would be no different than a firefighter
> who was not responding to fires in which people died.”
>
>
> It may be difficult to sort what types of domains are high risk, but when
> a certificate was used in this way without being revoked, it was no
> difference from the Google CP’s metaphor. As an Internet user I was
> disappointed about that, and those in the LE’ CP above can be treated as
> nonsense.
>
>
> Nio
> SZU
>
>
> On Fri, Feb 24, 2017 at 01:12:38AM +0000, Richard Wang via
> dev-security-policy wrote:
>
>
> > >I am sure this site: https://www.microsoftonline.us.com/ is a phishing
> site and a fade office 365 site that I wish LE can revoke this cert.
>
>
> >Why? It works just fine over HTTP, too.
>
>
> >- Matt
> _______________________________________________
>
>
> dev-security-policy mailing list
>
>
> dev-security-policy@lists.mozilla.org
>
>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> 发自我的iPhone
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
-- 
Vincent Lynch
_______________________________________________
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to