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
