I would like to thank everyone for your constructive input during this discussion. Since my post last week suggesting two options for distrusting the existing Certinomis root, a number of events have occurred, including the following:
* Certinomis confirmed that they have implemented pre-issuance linting [1], although it has more recently been disclosed that the linting is not active on older subCAs that Certinomis no longer intend to use for TLS [2][3]. * Francois posted a detailed response [2] to the issues list [4], and followed that with another explanation of how the response covers all of the issues that were identified [5]. * Four new precertificates containing an invalid SAN value [6] were found to have been issued on 13-May, after pre-issuance linting was in place. This was explained as being caused by a misconfiguration that allowed TLS issuance from one of the older subCAs without pre-issuance linting in place. * On 13-May, 174 precertificates with ‘unknown’ OCSP status were discovered [7]. Two more were discovered on 14-May. Certinomis currently does not have a solution to this problem [3]. * On 15-May, Andrew Ayer argued in this thread that Certinomis responds poorly to incidents. While the most recent incidents have not yet been fully understood, their existence points to the fact that Certinomis continues to demonstrate compliance issues, and it supports my previous recommendation to distrust the Certinomis root. While I encourage continued discussion of these issues, at this time we have enough information to make a decision. I proposed an option involving name constraining the existing Certinomis root rather than completely removing it from the Mozilla NSS root store. The feedback that was received was largely against this idea, and the arguments presented for not extending trust in the most important gouv.fr government site certificates - especially when they haven’t asked us to do so - are compelling. In conclusion, I recommend the following: Remove the “Certinomis - Root CA” from the Mozilla root store in an upcoming NSS release. * Treat any cross-signature of the existing root by another CA in Mozilla’s program as a policy violation that will (at a minimum) result in the immediate addition of the cross-certificate to OneCRL. Allow Certinomis to apply for inclusion in the Mozilla program with one or more newly created root(s) * Certinomis must undergo the normal Mozilla root inclusion process * Certinomis may be required to explain in detail how the issues discussed in this thread have been resolved. * A new audit report covering a period ending after the new root(s) are created will be required prior to completing the inclusion process. Mozilla may consider permitting an existing Mozilla CA Program member to cross-sign the new root under certain conditions, such as requiring Certinomis to produce a “clean” audit prior to the signing. Any such agreement must be disclosed to Mozilla, discussed on this list, and approved by Mozilla before the new Certinomis root key(s) are signed by any root included in our program. I will appreciate any feedback you have on this recommendation. I will soon file a bug requesting removal of the “Certinomis - Root CA” from NSS. If Kathleen accepts this recommendation, I predict that the root will be removed in the version of NSS that ships with Firefox 69 in September [8]. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c8 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c3 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357#c6 [4] https://wiki.mozilla.org/CA/Certinomis_Issues [5] https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/UiLZU1gDBQAJ [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1551357 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390 [8] https://wiki.mozilla.org/Release_Management/Calendar On Tue, May 7, 2019 at 4:48 PM Wayne Thayer <wtha...@mozilla.com> wrote: > Since I began this discussion, additional recent misissuances by > Certinomis have been discovered and reported. [1] [2] [3] One investigation > [1] led us to suspect that Certinomis had continued to employ BR domain > validation method 3.2.2.4.5 after it was banned [4]. A former Certinomis > employee denied this [5], and over a week passed with no official response > from Certinomis before they stated that the former employee is correct. > Unfortunately, we have also seen no engagement from Certinomis on this > mozilla.dev.security.policy list since I began the discussion, almost 3 > weeks ago. This week, the primary contact stated [6] “I am on holidays > until 14th of may, please apologize my slow answering.” > > On a positive note, on 6-May Certinomis stated in multiple bugs that > pre-issuance linting is now operational. > > I have updated the issues list [7] to reflect these changes. > > As others have stated during this discussion, I believe that the issues I > have documented demonstrate a basic inability to operate effective issuance > controls. While I acknowledge the efforts that Certinomis has made to > correct their problems, they continued issuance in spite of clear evidence > that the problems weren’t resolved. Having now implemented pre-issuance > linting, it may be reasonable to expect that most of these problems are > finally resolved. However, prior to and during this discussion, they have > also continued a pattern of unresponsiveness and demonstrated a lack of the > deep understanding of our requirements and of their own operations that we > expect of every CA. > > 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. > > > - > > Wayne > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1539531#c7 > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088#c20 > > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072 > > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1544933#c11 > > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1547072#c4 > > [7] https://wiki.mozilla.org/CA/Certinomis_Issues > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
