On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> To continue to participate in the Mozilla CA program, I recommend that we > require Certinomis to create a new hierarchy and demonstrate their ability > to competently operate their CA by going through a new root inclusion > request. I’d like to propose two options for their existing root: > > 1. > > Remove it from our root store in an upcoming Firefox release. > 2. > > Constrain it to use for gouv.fr domains in an upcoming Firefox release. > > > While there are only a few thousand unexpired TLS certificates (the root is > not trusted for email) known to chain to this root, a few are in use by > major French government websites (e.g. ants.gouv.fr). I have suggested > option #2 to minimize disruption to those subscribers and relying parties. > > I will greatly appreciate everyone’s input on my recommendation and the > proposed options. > Thanks Wayne for ensuring the conversation progresses in a timely fashion. Your Option #2 does have precedent, both by Mozilla and by other browser vendors, so I can understand the appeal. Some of these incidents have been documented by Mozilla [1] in the context of past discussions about voluntary name constraints [2], which captured a lengthy discussion about some of the tradeoffs involved. I appreciate that your Option #2 is only proposed in the context of addressing compatibility risks. Other CA events have prompted similar analysis, with different vendors taking different approaches (e.g. [3] vs [4]/[5], [6] v [7]). Despite these initial differences, it's worth noting that even in these cases of addressing potential compatibility issues, the industry uniformly aligned on ultimately removing trust in these CAs. It is unclear whether your Option #2 is proposing such a convergence, and when, or whether you see this as an indefinite proposition. One thing to consider with the creation of allowlists, whether in the context of name constraints (e.g. India CCA, ANSSI) or in the context of specific domains and certificates (Apple and Google, respectively, in the context of WoSign/StartCom), an important factor to consider is not just the compatibility, but the risk and value of the domain(s) being protected. If the conclusion is that Certinomis' existing controls are insufficient to provide reliable security, and its operations are not robust enough to provide the assurances that the community and Mozilla users critically depend on, then it seems important to also consider the potential harm of misissued certificates for those domains In the case of India CCA, this was part of the Indian National Informatics Center (India NIC), which itself was the domain registry for these domains. Similarly, while AFNIC is the operator for the French TLDs, ANSSI was the French national computer security agency to protect government systems. In these cases, the allowlist effectively and specifically accomodated the government needs and oversight. In the case of Certinomis, it is unclear whether the French Government itself would want to delegate the control and protection of its critical systems to an organization that has suffered such repeated failures. Has there been any communication with the agencies tasked with this - most likely, ANSSI itself? For example, the same concerns that lead to contemplating "Option #1" may similarly lead the French government to replace their certificates, rather than run further risk of misissuance. Similarly, has there been any consideration to simply allowlist the limited existing certificates, with a clear sunset date, as an alternative to name constraining? My overarching concern with any solution that does not eventually coverge at #1, if not begin there, is that it creates significant confusion about to what extent "legacy compatibility" is valued compared to "security". If such compatibility, with such a small number of sites, is such a concern, then as Jonathan Rudenberg has highlighted, it's useful to consider what other, additional steps, Mozilla and other browsers may wish to take to reduce the compatibility risk. As Jonathan rightly highlighted, one of the best ways to do this is a reduction in certificate lifetimes. Are there other steps that might be similarly productive to also consider, and in doing so, provide confidence that any Option #2 would, if adopted, be temporary, both specific to Certinomis and more generally as a mitigation strategy? [1] https://wiki.mozilla.org/CA:NameConstraints [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/pF4aVsF21ww/yKDhNpEt-2gJ [3] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ [4] https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html [5] https://support.apple.com/en-us/HT204132 [6] https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html [7] https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2982792 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
