I agree Eric. I apologize for those words, they’re beneath me and everyone else who strives for civil debate. It’s a terrible paragraph of text.
- Paul > On Aug 13, 2020, at 4:09 PM, Eric Mill <e...@konklone.com> wrote: > > On Thu, Aug 13, 2020 at 10:20 AM Paul Walsh via dev-security-policy > <dev-security-policy@lists.mozilla.org > <mailto: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 <mailto: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> > > <mailto: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/> <http://siterunbymonster.com/ > > <http://siterunbymonster.com/>> that you > > really are speaking with siterunbymonster.com > > <http://siterunbymonster.com/> <http://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> > > <mailto: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> > > > > > > <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> > > > > <mailto: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> > > > > <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> > > > <mailto: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> > > > <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> > > <mailto: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> > > <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> > > > -- > Eric Mill > 617-314-0966 | konklone.com <https://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
