On 11/10/16 01:04, Kathleen Wilson wrote:
> I think what you are saying is that the CA needs to re-apply for
> inclusion with new root certificates (not their old root certs).
> Correct? If yes, I am inclined towards that idea too. I've heard that
> it would cause continuity issues, but I don't get that. Seems to me
> that *if* the CA were to get their new root approved/included, that
> they could resume issuing from their new root instead of their old
> root.

The issue with continuity is this.

Let's say we decide on a 1-year distrust for CA Foo's current root, Root
A, and that they must then re-apply with a new root (Root B). The
timeline, even in the best case for CA Foo where the dis-trust lasts
only exactly one year, might look like this:

31st October 2016: Firefox stops trusting CA Foo Root A certs with
                   notBefore after 2016-10-31
1st June 2017:     CA Foo re-applies for inclusion with Root B
31st Sept 2017:    Root B included in NSS
31st October 2017: CA Foo Root B is shipped in Firefox

In order to try and make their certs work in more places, such as every
browser issued before 31st October 2016, CA Foo cross-signs Root B with
Root A, and tells sites to put the cross-cert in the SSL handshake.

However, all copies of Firefox distributed between 31st October 2016 and
31st October 2017 will not trust their new certs. They won't chain
properly up to Root A via the cross-cert, because the notBefores are too
late and the block will stop them. And they won't chain up to Root B,
because these Firefoxes know nothing about Root B. So there is a
continuity gap, and a ubiquity issue for CA Foo until all those
Firefoxes stop being used - which might be years.

Does that make sense?

This is not to say we should make one decision or the other, but it is
to point out that unless you say "you have to have new roots, but you
can generate them and we will include them straight away", you are going
to have a gap. And if you do say that, there's a problem because surely
the problem is you don't trust their infra/management/whatever right
now, so why would you let them generate new roots and fast-track them
into your product?

I guess you could ask a trusted competitor to generate them on new
hardware and hold the HSMs securely, then you include the roots in
Firefox straight away, and then only tell the competitor to release the
HSMs to CA Foo once CA Foo had completed inclusion. But that seems

> In any case, Gerv's proposal outlined a set of things that the CA
> would need to do in order to re-apply for inclusion.
> I'm inclined to agree with much of Gerv's proposal, but I'm still
> pondering this: "This distrust would remain for a minimum of 1 year.
> After that time, WoSign/StartCom may be readmitted to the Mozilla
> trust program, under the following conditions:..."
> Why do we need a minimum of 1 year? What purpose does that serve? If
> they meet all our requirements earlier, why couldn't we discuss it
> earlier than 1 year?

This is a good question; I remember writing an answer to someone who
asked this, but I can't remember where, so I'll repeat it here.

I picked the 1 year minimum for a number of reasons. The primary one
was, with WoSign-the-company and WoSign-the-infrastructure in mind, it
was clear to me that both the management and the technical infra had
lost my confidence. Restoring that was going to require changes of
personnel at many levels, a complete internal system audit, some
significant rewriting and testing of code, and then lastly an external
audit by a Mozilla-chosen auditor - with all the earlier steps being
necessary for them to have a hope of passing the last one. I felt that
if the WoSign knew that the 1-year distrust was happening anyway, there
would not be a temptation to rush this process.

My suspicions on this were borne out when, in the meeting in London,
Richard Wang (perhaps not being quite on the same page as everyone else
in the meeting) suggested that WoSign was ready to undergo the external
security audit now and prove their competence. Both I and the Qihoo
representatives politely suggested that this was not an appropriate
course of action!

1 year gives WoSign, if it ends up wishing to continue in business with
its own infrastructure, some guaranteed breathing room to take the
actions necessary to restore trust in a calm and unhurried manner, and
removes the temptation to cut corners.

Secondarily, it was compatible with the ban given to CNNIC, whose crimes
were arguably less severe.

Thirdly, while yanking a CA entirely can be done using OneCRL very
quickly, changing the code to trust and un-trust CAs by notBefore takes
time. Therefore, short bans make less sense. Hence my comment about the
inadvisability of "yo-yoing".

dev-security-policy mailing list

Reply via email to