Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 9:35 AM, Ben Wilson wrote: > Looking at the threat from a defense-in-depth/orthogonal perspective, > doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does > something to combat malicious websites for the public? > It

Re: SSL Certs for Malicious Websites

I would simply like to state that my views, and the views of Let's Encrypt, are closely aligned with those already expressed here by Peter Bowen and Eric Mill. I will add, since I don't think it has been made clear enough here already, that violations of a CA's subscriber agreement can and

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

Here is a summary of this discussion so far about Symantec's request to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled. 1) The "Symantec AATL ECC Intermediate

Re: When does Technically Constrained != Technically Constrained?

On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling wrote: > The following intermediate certificate is not "technically constrained" > according to the Policy. It contains id-kp-codeSigning, but does not > "contain a directoryName permittedSubtrees constraint where each >

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 03:16:59PM +0100, Gervase Markham wrote: > > What is meant by "fraudulent use"? > > I think the bullet as a whole could mean that we reserve the right to > not include CAs who happily issue certs to "www.paypalpayments.com" to > just anyone without any checks or High Risk

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 04:35:49PM +, Ben Wilson wrote: > Looking at the threat from a defense-in-depth/orthogonal perspective, > doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does > something to combat malicious websites for the public? Because the next steps after

Re: SSL Certs for Malicious Websites

In the case of a DV certificate it's exactly what it says, validating the ownership of a domain, and nothing more. While users _may believe_ that TLS is supposed to protect them from malware, hackers, or 'untrustworthy' sites in general _it is not_. TLS exists to encrypt the connection between a

When does Technically Constrained != Technically Constrained?

The following intermediate certificate is not "technically constrained" according to the Policy. It contains id-kp-codeSigning, but does not "contain a directoryName permittedSubtrees constraint where each permittedSubtree contains the organizationName, localityName (where relevant),

Re: SSL Certs for Malicious Websites

On Wed, May 18, 2016 at 7:16 AM, Gervase Markham wrote: > I think the bullet as a whole could mean that we reserve the right to > not include CAs who happily issue certs to "www.paypalpayments.com" to > just anyone without any checks or High Risk string list or anything. > Such

Re: When does Technically Constrained != Technically Constrained?

This intermediate seems technically constrained for SSL and S/MIME certificates, which are the only type of certs under the current Mozilla policy. Having extra nameConstraints for this particular intermediate, seems to be unnecessary, for the Mozilla root program. DZ. > On 18 Μαΐ 2016,