On Thu, Aug 13, 2020 at 10:20 AM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > Calling someone else's contributions on the list "totally stupid" is to me a pretty clear violation of the code of conduct of this list. Maybe you didn't mean to do exactly that, but given that you also called them "outrageously irresponsible" and made a direct comparison to 5G/vaccination conspiracy theories, certainly the totality of your note was unnecessarily harsh. > > - 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 > -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
