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
  • Concerns with Let's Encrpyt r... nathali...--- via dev-security-policy
    • Re: Concerns with Let's ... Jonathan Rudenberg via dev-security-policy
      • Re: Concerns with Le... Paul Walsh via dev-security-policy
        • Re: Concerns wit... Matthew Hardeman via dev-security-policy
          • Re: Concerns... Burton via dev-security-policy
            • Re: Con... Paul Walsh via dev-security-policy
              • Re:... Burton via dev-security-policy
                • ... Paul Walsh via dev-security-policy
                • ... Burton via dev-security-policy
                • ... Paul Walsh via dev-security-policy
                • ... Burton via dev-security-policy
              • Re:... Tobias S. Josefowitz via dev-security-policy
                • ... Paul Walsh via dev-security-policy
                • ... Ronald Crane via dev-security-policy
                • ... Kurt Roeckx via dev-security-policy
                • ... Ronald Crane via dev-security-policy
                • ... Tobias S. Josefowitz via dev-security-policy
                • ... Ronald Crane via dev-security-policy
                • ... Tobias S. Josefowitz via dev-security-policy

Reply via email to