Of course, the main reason Comodo gets sucked into this swamp is the price point. That isn't necessarily their fault.
As I've pointed out elsewhere, Comodo has some great ideas about fixing revocation that would go a long way towards solving the "misbehave only after issuance" problem that you correctly pointed out. -Tim > -----Original Message----- > From: Rob Stradling [mailto:rob.stradl...@comodo.com] > Sent: Thursday, December 14, 2017 6:01 AM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: Peter Gutmann <pgut...@cs.auckland.ac.nz>; Gervase Markham > <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org; Tim > Shirley <tshir...@trustwave.com> > Subject: Re: On the value of EV > > On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote: > > If you look at where the HTTPS phishing certificates come from, they > > come almost entirely from Let's Encrypt and Comodo. > > > > This is perhaps the best argument in favor of distinguishing between > > CAs that care about phishing and those that don't. > > Tim, > > We reject certificate requests for sites that are already known to engage in > phishing, and we revoke (for all the good that does) certificates for sites that > are subsequently discovered to have engaged in phishing. > > IIUC, you're saying that "CAs that care about phishing" are ~100% successful > at avoiding issuing certs to phishing sites. If so, that's great! Perhaps you > could help us to become one of the "CAs that care about phishing" by sharing > your crystal ball technology with us, so that we too can avoid issuing certs to > sites that subsequently engage in phishing? > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
