Exactly what I thought - you’re either unable to answer the question honestly, or you simply do not care about the consequences that arise from abuse.
> On Aug 13, 2020, at 11:19 AM, Burton <j...@0.me.uk> wrote: > > I'm not going to answer the question because it's not relevant to discussion. > > On Thu, Aug 13, 2020 at 6:57 PM Paul Walsh <p...@metacert.com > <mailto:p...@metacert.com>> wrote: > Let me try this. Let’s say a report of child abuse is put forward to a > hosting provider, should they ignore it because they “are not the police”? > Should companies like Twitter and Facebook do nothing to reduce the risk of > bullying, misinformation and other bad things? It’s ok to say you think they > should do nothing - but is that in the best interest of internet security and > for society? > > Again, I’m talking about moral obligation, not the law or even standards or > best practices. Why would any company not want to reduce the risk of abuse > for illegal intent? Just because you don’t have to do something, doesn’t mean > you shouldn’t. You can walk past a child being kicked in the head by a > strange man if you want, but it’s probably not the right thing to do. You can > call the police but by then they could be dead. > > Where’s your sense of doing the right thing? > > > >> On Aug 13, 2020, at 10:42 AM, Burton <j...@0.me.uk <mailto:j...@0.me.uk>> >> wrote: >> >> 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 >> <mailto: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 <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>> 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
