On Friday, October 14, 2016 at 3:01:16 AM UTC-7, Gervase Markham wrote:
> There are indeed more of these than I remember or knew about. Perhaps it
> would have been sensible to start a StartCom issues list earlier. In my
> defence, investigating one CA takes up a lot of time on its own, let
> alone two :-)

10 minutes with "site:bugzilla.mozilla.org StartCom"

Which was only possible due to the many Mozilla contributors who, when they saw 
something improper, filed bugs. I just want to make sure to thank all of the 
contributors who have done so, and hopefully continue to do so.

> On the other hand, this happened 8 years ago. I'd be interested in your
> comments, Ryan, on whether you think it's appropriate for us to have
> some sort of informal "statute of limitations". That is to say, in
> earlier messages you were worried about favouring incumbents. But if
> there is no such statute, doesn't that disadvantage incumbents? No code
> is bug-free, and so a large CA with many products is going to have
> occasional troubles over the years. If they then have a larger issue, is
> it reasonable to go trawling back 10 years through the archives and pull
> out every problem there's ever been? This is a genuine question, not a
> rhetorical one.

Right, I had the same question when investigating. We know Eddy's position on 
it ('It was in the past, get over it' - if I may so aggressively strawman). I 
suppose a core question is: What is the goal of the root program? Should there 
be a higher bar for removing CAs than adding them? Does trust increase or 
decrease over time?

That is, I can totally see the argument that frequently adding new CAs is bad, 
because new CAs may not have the organizational or operational experience to 
meet the high bar expected of CAs. We frequently see this with addition 
requests - CAs well below what the community standard might be. In this model, 
the more time passes, the more institutional knowledge and expertise the 
organization develops, the better users are protected by keeping CAs in longer 
(and allowing them to remediate).

Another view is that we want a consistent bar, and that means CAs that fall 
short of that should be culled, regardless of age of the CA. This model 
suggests that a longitudinal analysis of a CA's operation is necessary - that 
we must never forget past mistakes when evaluating current mistakes or in 
predicting future mistakes.

We can hopefully assume that CA are rare, at least for an individual CA, and so 
we may never get sufficient samples to accurately predict future behaviour. 
Analyzing a longer period of time gives us data to establish a pattern and 
trend, but also disadvantages those who go through 'growing pains' on their way 
to becoming a mature CA.

I don't have a good answer for your question in the general case, for reasons 
hopefully explained, but I think towards the question of predicting 
responsiveness to incidents, and how they'll be treated, I think the longer 
analysis of StartCom is useful for the discussion. My own gut is that the 
ecosystem is better served if we look at the whole of a CA's operation. My view 
is that the theory that experience is developed over time is one not borne out 
by practice - what we see instead is the same players from existing CAs 
shifting around to different organizations.

> All the WoSign issues I documented where the past two years. Many of the
> StartCom issues you list are 2.5 - 3.5 years old. That may not be long
> enough, but how long is?

Well, the past year it's been run by WoSign, so 2.5 - 3.5 years really reflects 
the past 1.5 to 2.5 years of independent operation, right?
dev-security-policy mailing list

Reply via email to