Please don't speculate on my opinion just because I won't answer the question. That's unprofessional.
So act professional! You know it makes sense! On Thu, Aug 13, 2020 at 8:04 PM Paul Walsh <p...@metacert.com> wrote: > 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> 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> 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> 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> 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> 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 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 >>>> >>> >>> >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
