"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 > <mailto: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 > <http://siterunbymonster.com/> that you > really are speaking with siterunbymonster.com <http://siterunbymonster.com/>. > > On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy < > dev-security-policy@lists.mozilla.org > <mailto: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 > > <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 > > > <mailto:dev-security-policy@lists.mozilla.org> > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > <https://lists.mozilla.org/listinfo/dev-security-policy> > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > > <https://lists.mozilla.org/listinfo/dev-security-policy> > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > <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
