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.
Hi Kathleen, 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 this proposal? 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 >statement? 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 correct? 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 email@example.com https://lists.mozilla.org/listinfo/dev-security-policy