Breaking this part of the discussion out of the CNNIC thread.... So, to paraphrase, the security benefit to CT is on par with posting speed limits along a highway: if you're going to break the rules, don't get caught. And if you do get caught, have a good excuse--although in the case of CT there is no process for dealing with potential violators.
If we continue the whitehouse-dot-gov example, suppose such a cert shows up in the CT logs for an agency such as CNNIC and then a week later it was revoked. I don't see anyone taking action against that agency. I know a lot of energy has gone in to CT but for all that effort it seems the benefits will be quite limited. Original Message From: Matt Palmer Sent: Monday, April 13, 2015 7:20 PM To: dev-security-policy@lists.mozilla.org Subject: Re: Requirements for CNNIC re-application On Mon, Apr 13, 2015 at 06:15:52PM -0500, Peter Kurrasch wrote: > Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov > and let's further suppose that CNNIC includes this cert in the CT data > since they have agreed to do that. What happens next? > > Where I'm going with this is that I'm trying to figure out if agreeing to > support CT is a hollow promise. It seems like it might deter bad behavior > on the part of a cert issuer but it's effectiveness in that regard is > limited if nobody is checking the CT logs. (By way of comparison, > consider the deterrence impact of using name constraints.) Yes, if nobody is watching the CT logs, there is no *direct* benefit from the single act of publishing all issued certificates. That said, the simple fact that someone *could* be watching what is going on will tend to affect the behaviour of a CA, as it does on any activity involving humans. There is also the benefit that, since the logs are public in perpetuity (or a reasonable approximation thereof), past bad behaviour can be detected by reviewing the historical log data, rather than having to notice it at the time (which is the primary limitation in SSL census data, as useful as that is). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
