Hi Ben, I appreciate the clarity on the decision, but I do believe that the rationale and justification of it are inconsistent - internally to the message itself, with the public discussion, and with Mozilla's stated values, goals, and past public statements. I hope to highlight these, in the event that these were oversights in the evaluation process and worthy of reconsideration.
# Inconsistent internally Within the message, you note that the primary purpose is > We use an open, public, and transparent procedure, and we evaluate the risks to users’ security and privacy and later state: > While the risks presented by a root and an intermediate may be very similar, they are not identical. For example, a root certificate can issue other CA certificates, which introduces the risk that a CA certificate will be mis-issued. While the intermediate CA certificates proposed here cannot be used to issue CA certificates, and can only be used to issue DV server certificates. Unfortunately, this suggestion of "less risk" is both technically flawed, and inconsistent with the explanation of the rationale. To focus exclusively on the latter, the message later states: > Because GoDaddy is putting its own root at risk, such reviews have gone beyond the minimum requirements of Mozilla and the CA/Browser Forum's Baseline Requirements This suggests that the conclusion is based on the assumption that, should Certainly have issues, GoDaddy would be appropriate to distrust. As discussed in previous messages, this clearly demonstrates the significantly greater risk posed by the existence of an intermediate, and shows that the ability to issue sub-CAs is entirely orthogonal to the risk remediation process, namely, sanction against GoDaddy. GoDaddy represents one of the largest CAs in Mozilla's program, and it seems unlikely that Mozilla is willing to take action except in the most egregious of scenarios, due to the end-user impact. If this is the statement, then it seems Certainly poses high risk to users, because it can "take out" GoDaddy. Alternatively, if this is not the statement, then it shows the inconsistency in the conclusion in that GoDaddy is under very little functional risk, and thus has less incentive to perform adequate review - as highlighted by Andrew Ayer's review, my review, and Certainly's own disclosed incidents thus far. Notably, while Certainly has noted it's using Boulder, it's worth highlighting that both Certainly and GoDaddy failed to discover issues with that implementation until reported by another CA [1]. This should raise questions about the degree of thoroughness and correctness of the review performed - of code, practice, and policy - and highlight the questionable nature of relying on GoDaddy's assertions. # Inconsistent with the public discussion Without repeating your excellent summary of the discussion thus far, it shows that there is limited support in the community for continuing forward. While understandably, the role of Mozilla is to weigh many different viewpoints, and not just count by number and volume (length), it should raise some degree of concern that the emphasis of risk that exists here seems unaddressed. Much of this seems to be dismissed under the basis that GoDaddy has performed an analysis sufficient for Mozilla to ignore its own extant policies and procedures for managing CA risk, which also seems inconsistent with the degree of public discussion and transparency. For example, although GoDaddy has shared their process, there's been no substantive response to the concerns raised by Andrew Ayer that discusses procedurally how this was overlooked. Although we have the response from Wayne Thayer regarding the intent, it highlights the possibility that both GoDaddy and Certainly are operating on certain undocumented assumptions about the interpretation of language and/or requirements that would normally be part of a public discussion during review. This, equally, should raise questions about the degree of thoroughness and correctness of the review performed. # Inconsistent with Mozilla's stated values, goals, and past statements The nature of risk presented here certainly raises questions with respect to Principles 4 and 8 [2]. I think it's questionable to suggest that GoDaddy's internal review satisfies those. From examining the spreadsheet [3], it's also clear that GoDaddy's primary review was conducted not with the same Mozilla principles in mind, but rather, whether there was consistency and/or conflict with GoDaddy's (Starfield's) CP/CPS. This an important step for cross-signing, but it does not address the same goals, nor ensure the same perspectives. The additional documents [4] supplied are very clearly forms of self-review, and lack both transparency and accountability that demonstrate a commitment to these principles. With respect to past statements, it's difficult to reconcile the glowing remarks about the value of audits, and the diligence provided by third-parties (e.g. GoDaddy), with Mozilla's statement of concerns with respect to proposals such as the eIDAS Regulation [5], or its justification for its root store [6]. For instance, in the concerns regarding the EU Trust List, it's highlighted that there are concerns with transparency, audits, and risk management. There is no transparency into the ongoing GoDaddy supervision, only in the conclusion, which denies users appropriate transparency into the discussions and interpretations, as highlighted above. While Mozilla highlighted concerns with the irregularity of the audits in [5], past concerns raised by Mozilla [7] have highlighted there is far more to supervising CAs and minimizing risk than audits alone. However, your statement in favor of positive dispensation for Certainly seems to rest largely, if not entirely, on an assumption that audits are alone sufficient. And in terms of risk management, this thread has shown a number of ways in which Mozilla is failing to fully consider its risk management. These risk management concerns are echoed in [6] about the value of the root store, but this reply seems to separate out the selection of roots from those of intermediates, as if intermediates aren't an intrinsic part of both the value of, and risk to, Mozilla's policies and practices highlighted in that post. Equally, when one considers the super-CA policy, [8], it suggests that if one wants to start a super-CA, the process is rather to add the super-CA as a root first, before signing subordinates, such that newly-added subordinates can use the expedited process and bypass the review currently required if there is an existing parent/subordinate relationship. # Conclusion Ultimately, Mozilla's decisions for its programs are Mozilla's, and there is no question that there is incredible value in the transparency of this discussion, and value in the opportunity to participate in it. However, the conclusion seems to argue that audits and basicConstraints are sufficient to mitigate risk to end users, such that it's not necessary for Mozilla to perform a careful, detailed, and diligent review. It also seems to discount the numerous concerns raised by participants about the process. I appreciate the discussion with respect to the wiki, but note that it's been even longer that concerns have been raised around such cross-signing events (e.g. [9], [10]), to which Mozilla did not substantively respond. Originally proposed as part of Policy 2.8, it now seems to have been adopted in full independent of that, and it leaves it ambiguous whether current proposals [11] are advocating for a Mozilla-led review, or whether they're instead weakening the intent of both policy and language to being led by CAs. My biggest concern, however, remains that it's difficult to see the distinction Mozilla is making here, with respect to delegating and deferring to GoDaddy, and how that squares with concerns it has raised delegating and deferring to other organizations, whether super-CA operators ([8]) or the European Trust Lists ([5], [7]). Mozilla is, functionally, outsourcing the oversight and compliance, and it's unclear the value that Mozilla, or users, derive from this process, other than expediting the inclusion of CAs. Can Mozilla articulate why it cannot substitute "EU Supervisory Bodies" in for "GoDaddy" in the rationale to continue, and thus automatically adopt the European Trust Lists, provided it also has the ability to remove? It's difficult to see, based on the stated rationale, why it could not, and that's concerning. As I said, I have no objections if the view is that such subordinate CAs should be moved to the front of the queue for prioritization, provided that the same processes occur and without any predisposition towards including the CA. The rigorous vetting [12] that Mozilla has endorsed [13] does not appear to be performed here, or appears to be performative rather than substantive, and that remains a concern. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1752452 [2] https://www.mozilla.org/en-US/about/manifesto/ [3] https://bugzilla.mozilla.org/attachment.cgi?id=9266000 [4] https://bugzilla.mozilla.org/attachment.cgi?id=9266001 [5] https://blog.mozilla.org/netpolicy/files/2020/09/Mozilla-Attachment-to-the-European-Commission-Review-of-eIDAS.pdf [6] https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ [7] https://www.ccadb.org/documents/TSP_Technical_Best_Practices_eIDAS.pdf [8] https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs [9] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/-L7Q_bdABQAJ [10] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/mS5rard2BQAJ [11] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/r9ZeggoH9KA/m/NZwE3TuYAwAJ [12] https://www.eff.org/document/eidas-letter-2022 [13] https://blog.mozilla.org/en/security/mozilla-eff-cybersecurity-experts-publish-letter-on-dangers-of-article-452-eidas-regulation/ -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEJiPWdJOcZX1g4-hGDR_OJTfTZH%3DqTaS-TFQGHRbhyRw%40mail.gmail.com.
