I stand by the comments I made earlier and it's the correct terminology. A domain should have a certificate regardless of intent by the user. CAs are not the police and shouldn't act as one. CAs do have to follow policies if the certificate is used in illegal activities, misissued, etc but no CA shouldn't be refusing to issue a certificate for a domain unless for certain reasons.
We are talking about DV certificates because that is what Let's Encrypt issues. On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh <p...@metacert.com> wrote: > "Every domain should be allowed to have a certificate ***regardless of > intent***.” > > They are the most outrageously irresponsible words that I’ve heard in my > career on the web since 1996 when I was at AOL, and sadly, I’ve heard them > more than once. I just can’t get my head around it. To me, those words are > akin to someone saying that masks, Bill Gates, 5G and vaccinations are all > dangerous - totally stupid and not in the best interest of society. > > - Paul > > > > On Aug 13, 2020, at 1:37 AM, Burton <j...@0.me.uk> wrote: > > Let's Encrypt hasn't done anything wrong here. > Let's Encrypt has issued the certificate according to the BR requirements > and their own policies. > > Every domain should be allowed to have a certificate regardless of intent. > CAs must not be allowed to act as judges. > > Remember, all server certificates have to go into CT log and therefore > easily findable. That can be useful in many situations. > > On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> It’s actually really simple. >> >> You end up in a position of editorializing. If you will not provide >> service for abuse, everyone with a gripe constantly tries to redefine >> abuse. >> >> >> Additionally, this is why positive security indicators are clearly on the >> way out. In the not too distant future all sites will be https, so all >> will require certs. >> >> CAs are not meant to certify that the party you’re communicating with >> isn’t >> a monster. Just that if you are visiting siterunbymonster.com that you >> really are speaking with siterunbymonster.com. >> >> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > [snip] >> > >> > >> So the question now is what the community intends to do to retain >> trust >> > >> in a certificate issuer with such an obvious malpractise enabling >> > >> phishing sites? >> > > >> > > TLS is the wrong layer to address phishing at, and this issue has >> > already been discussed extensively on this list. This domain is already >> > blocked by Google Safe Browsing, which is the correct layer (the User >> > Agent) to deal with phishing at. I'd suggest reading through these posts >> > before continuing so that we don't waste our time rehashing old >> arguments: >> > >> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing >> > >> > >> > [PW] I’m going to ignore technology and phishing here, it’s irrelevant. >> > What we’re talking about is a company’s anti-abuse policies and how >> they’re >> > implemented and enforced. It doesn’t matter if they’re selling >> certificates >> > or apples. >> > >> > Companies have a moral obligation (often legal) to **try** to reduce the >> > risk of their technology/service being abused by people with ill >> intent. If >> > they try and fail, that’s ok. I don’t think a reasonable person can >> > disagree with that. >> > >> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been >> informed >> > that bad people are abusing their service, why wouldn’t they want to >> stop >> > that from happening? And why would anyone say that it’s ok for any >> service >> > to be abused? I don’t understand. >> > >> > - Paul >> > >> > >> > >> > > >> > > Jonathan >> > > _______________________________________________ >> > > 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 >> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
