On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi <[email protected]> wrote: > > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy < > [email protected]> 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. > > If we decide to take option 2, I'm open to suggestions about the length of time we should continue to trust the root for issuance to gouv.fr domains, but I don't expect the answer to be "forever". One approach would be to require a relatively quick transition prior to the inclusion of a new Certinomis root. Another is to set a date far enough in the future that we believe it would be reasonable for Certinomis to have a new root included and transition to it, allowing gouv.fr site to continue to rely on Certinomis.
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? > > No, I have not attempted to contact these site operators, nor has the option of allowlisting specific certificates been given any consideration. I am not opposed to the idea of allowlisting specific certificates. 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? > > I share the concern that option #2 sends a confusing message. As Jonathan stated, why should we distrust a CA for all but the most important websites they secure? > > [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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
