(Writing in a personal capacity) Benjamin,
I've focused only on the substantive new information added to this discussion relevant to trust. I hope the past messages have highlighted why much of the message may be fundamentally misunderstanding the purpose of a root store and the root store inclusion process, there are two salient bits from this message that are worth responding to. On Wed, Mar 6, 2019 at 9:24 AM Benjamin Gabriel via dev-security-policy < [email protected]> wrote: > Mozilla should note that a key reason why DarkMatter decided to launch a > commercial CA business is because the citizens, residents and visitors to > the United Arab Emirates currently do not have access to local providers > who can provide them with the protections taken for granted in other parts > of the world. As it relates to TLS certificates, which is the purpose of discussion for this root inclusion, could you highlight or explain why "citizens, residents, and visitors" do not have access to TLS certificates, or how those protections offered by DarkMatter are somehow different? I highlight this, because given the inherently global nature of the Internet, there is no technical need to work with local CAs, and, with a well-run root store, all CAs provide an equivalent level of protection and security, which rests in the domain authorization. This is, of course, comparable to the domain name system of gTLDs (rather than ccTLDs), which is inherently global in nature. Additional services that a CA may provide do not necessarily factor in to the decision making process, as the question to answer is whether the risk of including a given CA, which will have proverbial keys to the Internet, is outweighed by the new and unique benefit it brings to the promotion and adoption of TLS for the "typical" user. > This Mozilla inclusion public discussion has also allowed us to showcase > our timely and expedient response when issues are identified. A good > example is our lead, in how we responded in a timely manner to the concerns > raised, by certain list members, with regard to entropy non-compliance of > our serial numbers on the EJBCA platform. > This does not seem to align with the objective facts. 1) To the best of my knowledge, DarkMatter has still not provided a timely incident report, as others have pointed out [1], over 9 months after it was requested [2]. 2) DarkMatter response to the serial number issue has demonstrated that DarkMatter did not do the expected due diligence to investigate and understand the issue. As acknowledged by your colleague [3], DarkMatter only began to respond to this incident once it was carefully explained to them by members of this community why the interpretation was wrong. However, the expectations of CAs, as have been consistently applied to all CAs, is that the CA is themselves capable of performing such an analysis, and their ability or inability to do so is a significant factor in trustworthiness. 3) This incident fits within a larger pattern [4] of issues [5] in which DarkMatter has demonstrated a lack of understanding of the core expectations of Certificate Authorities. As demonstrated in the past [6], CAs that have demonstrated patterns of misunderstanding or disputing core requirements may not be in the best interests of the security of Mozilla users. Given that organizations will have the capability to intercept all Mozilla users' network traffic, by virtue of directly misissuing, or may jeopardize the security of Mozilla users, through improperly operating their CA in a way that can allow for compromise or misuse [7], it seems that there is ample precedent. Respectfully, the choice to include any new CA is a question about whether or not this new CA will provide new value and benefit to typical Mozilla users, commiserate with the risk. You have highlighted that you believe such articles are misleading, but there are a number of unresponded questions to past replies that seek to better understand. However, such a reply also seems to overlook the fact that the discussion does not begin with an assumption of "We should trust", and then seek to find reasons not to, but rather, begins with an evaluation of "Should we trust", and seeks to evaluate the benefits of that new addition versus the risks that each new CA poses. In line with the above, in which a pattern of risk has been identified through how DarkMatter has handled the incidents and independent of the nature and severity of the incident themselves, and the broader thread has highlighted a risk of the loss of faith and trust in the Mozilla Foundation's commitment to their users security, perhaps you can spend time highlighting the benefit that trust in DarkMatter will provide the typical Mozilla user, so that it can be evaluated as to whether that benefit is greater than the risk. I think it is worth noting that, rather than treating this as somehow a response to a given geographic area, CAs which provide limited value to small communities, but put at risk the broader community, have resulted in discussions [8][9] that ultimately resulted in the CAs removal [10]. Understanding the material differences in these situations may go much further in productive discussion, and hopefully demonstrate the consistency of the long-held principles being applied to the present discussion. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/vvVSHKakAgAJ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32 [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/HiNC3UeeAgAJ [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c10 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c39 [6] https://groups.google.com/d/msg/mozilla.dev.security.policy/lqZersN26VA/NVLf6YPWAAAJ [7] https://wiki.mozilla.org/CA:Symantec_Issues [8] https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/rae9kNkWAgAJ [9] https://groups.google.com/d/msg/mozilla.dev.security.policy/eOuTmwQKMSk/pyXvWHhmBQAJ [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
