On Thursday, October 13, 2016 at 9:50:02 AM UTC-7, Kathleen Wilson wrote:
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date
> after October 21, 2016. If additional back-dating is discovered (by any
> means) to circumvent this control, then Mozilla will immediately and
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train .
> -- The code will use the subject key id (hash of public key) to identify the
> Affected Roots, so that the control will also apply to cross-certs of the
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued
> before October 1, 2016, have expired or have been replaced.
I appreciate the thoughtfulness and time spent on reviewing and considering the
feedback and the incident. At the risk of asking you to do even more work,
would it possible to ask that you expand a bit more on the reasoning behind
In particular, I'm hoping to expand upon the choice to allow existing certs to
continue to be accepted and to not remove the affected roots until 2019.
>From an outsider perspective, it would appear the reasoning is to minimize any
>negative impact on existing WoSign customers, which in turn minimizes any
>impact on Firefox users, by assuming that all (but a few) of the existing
>certificates were correctly issued and reamin trustworthy. Is that a fair
It seems to accomplish this, you're willing to continue to trust that WoSign
will not demonstrate any of the past behaviours it already demonstrated - such
as backdating and misissuance, but not to issue new certificates. Is that
I ask because it seems to be a very challenging position - we don't necessarily
trust that new certificates will abide by the policies, but at the same time,
we need to trust that they'll abide by the new policies and not issue any new
certificates. Is that a fair statement of the conflict?
Thinking back to Mozilla's core principles, I'm curious how you weigh the risk
to Firefox users versus the overall ecosystem risk. For example, many consumers
of NSS-based trust stores have only the logic to trust (by inclusion) or
distrust (by omission or by distrust records). This is true for applications
like OpenSSL-/GnuTLS-based applications, but also true for other root stores
and programs (for example, both Windows and Android, in their mass-deployed
versions, lack more extensive capabilities). As a consequence of this - which,
to be fair, is not a problem of Mozilla's creation - there exists the ecosystem
risk that in order to minimize any incompatibilities, these applications will
need to continue to trust WoSign and StartCom for as long as other popular
programs - such as Mozilla - do. If these applications/devices lack the
capability to distrust new certificates, as Mozilla plans to implement, then it
means they may face risk that Mozilla users may not.
While again, I want to emphasize this is not a problem of Mozilla's creation,
I'm curious how considerations such as other applications' behaviour is
weighted in such decisions. As a concrete example, if it was weighted
particularly high (that is, ecosystem good were seen to be as-valuable-or-more
than the individual good to Firefox/Mozilla users), then it might be more
desirable to have an accelerated plan to move Firefox to full distrust, rather
than minimizing Firefox impact. For example, fully distrusting these
certificates in, say, 6 months, would allow other players in the ecosystem to
take appropriate steps and block these certificates, without having to suffer
the first-mover/only-mover problem.
I understand this is somewhat unique, as notable other programs have not fully
announced what they're intending, perhaps because they're allowing Mozilla the
opportunity to lead the public discussion and investigation, but if other
programs were concerned about the trustworthiness of WoSign and the ability to
abide with a requirement to not issue new certificates, would you consider a
path that moved to a full distrust (of both new and existing) in a more
accelerated fashion, if it was not Mozilla moving alone?
dev-security-policy mailing list