I would like to support the statements made by both Fabio and Scott to the
extent that if Mozilla is to go forward with this decision, then I fully
expect them to review their existing CAs and to revoke onto OneCRL every
one of them that has some news report of blog post linking them to
nefarious activities without evidence. The examples given by Fabio (Saudi
Telecom, Australia's Attorney General Department, etc.) seem to have as
much "evidence" (if not more) than DarkMatter out there. Will they also be
revoked? And if not, why not? In fact, why didn't Mozilla itself bring this
up before Fabio and Scott chimed in?

As I predicted, we are now in a situation where DarkMatter can correctly,
and at length, chide Mozilla for a short-sighted and illegitimate
implementation of a critical process. It doesn't please me to be unable to
find any holes in Scott's email; on the contrary, it worries me. Because we
are now in a position where Mozilla can't defend its decision making
against an entity that may in the end still turn out to be involved in
aggressive surveillance and hacking behavior, despite the current lack of
evidence.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office


On Wed, Jul 10, 2019 at 6:43 PM Scott Rea <scott....@darkmatter.ae> wrote:

> G’day Folks,
>
> DigitalTrust first learned of the Mozilla decision via Reuters. We believe
> this is emblematic of Mozilla’s approach to our application which appears
> to have been predetermined from the outset.
>
> We believe yesterday’s decision is unfair and demonstrates an anti-UAE
> bias where a 2016 media report referring to a single claimed event that
> aims to falsely implicate DarkMatter (and repeatedly echoed over a span of
> 4 years) has now outranked Mozilla’s established process of demonstrated
> technical compliance. This very same compliance has been met by
> DigitalTrust for three consecutive years with full transparency.
>
> The emerging principle here seems to be that 508 WebTrust audit controls
> are not sufficient to outweigh a single media allegation referring to work
> we as well as DarkMatter simply don’t do. In fact DarkMatter’s work is
> focused on the exact opposite of the false claim as evidenced by the
> continuous work to protect all internet users, for example through on-going
> disclosure of zero day vulnerabilities to the likes of Cisco, Sony, ABB and
> others.
>
> Mozilla’s new process, based on its own admission, is to ignore technical
> compliance and instead base its decisions on some yet to be disclosed
> subjective criterion which is applied selectively.  We think everybody in
> the Trust community should be alarmed by the fact that the new criterion
> for inclusion of a commercial CA now ignores any qualification of the CA or
> its ability to demonstrate compliant operations. We fear that in doing so
> Mozilla is abandoning its foundational principles of supporting safe and
> secure digital interactions for everyone on the internet.  This new process
> change seems conveniently timed to derail DigitalTrust’s application.
>
> By Mozilla’s own admission, DigitalTrust is being held to a new standard
> which seems to be associated with circular logic – a media bias based on a
> single claimed event that aims to falsely implicate DarkMatter is then used
> to inform Mozilla’s opinion, and the media seizes on this outcome to
> substantiate the very same bias it aimed to introduce in the first place.
> Additionally, in targeting DigitalTrust and in particularly DarkMatter’s
> founder Faisal Al Bannai, on the pretense that two companies can’t operate
> independently if they have the same owner, we fear another dangerous
> precedent has been set.
>
> What’s at stake here is not only denial of the UAE’s Roots but also
> Mozilla’s denial of the UAE’s existing issuing CAs. This means the nation’s
> entire Public Trust customer base is now denied the same digital
> protections that everyone else enjoys.
>
> We fear that Mozilla’s action to apply this subjective process selectively
> to DigitalTrust effectively amounts to incremental tariffs on the internet
> with Mozilla de-facto promoting anti-competitive behavior in what was once
> a vaunted open Trust community.  Mozilla is now effectively forcing the UAE
> to protect its citizens by relying on another nation or commercial CA –
> despite DigitalTrust meeting all of Mozilla’s previously published criteria
> – thus protecting a select number of operators and excluding or forcing
> newcomers to pay a premium without the added benefit of control.
>
> In conclusion we see only two possible paths going forward.
>
> Under the first path, we demand that Mozilla’s new standard be explicitly
> disclosed and symmetrically applied to every other existing member of the
> Mozilla Trust Program, with immediate effect. This would cover, based on
> the precedent of the DigitalTrust case, any CA deemed to be a risk to the
> Trust community, despite lacking substantive evidence. This would suggest
> that any CA that serves a national function, is working closely with
> governments to secure the internet for its citizens, or is associated to
> other practices covering cyber security capabilities (which would include a
> large group of countries and companies) would have to be removed.
>
> Under the second path, we call on Mozilla to honor its founding principles
> outlined in its Manifesto that ‘individuals’ security and privacy on the
> internet are fundamental and must not be treated as optional’.  We firmly
> believe this applies to citizens and residents of the UAE and we demand
> that Mozilla reverses its decision.
>
> In following the second path, Mozilla can right yesterday’s wrong that
> inspires little confidence in the due process applied in the case of
> DigitalTrust as it seems to favor a subjective criterion based on a falsely
> established bias at the expense of rigorous technical controls and policy
> compliance. In reversing its decision, Mozilla can fulfil its core purpose
> to protect individual security and privacy on the Internet – in this case
> for UAE citizens - by enabling the UAE Roots as trusted in their products.
> And finally, by reversing its decision, Mozilla can find a path back to a
> balanced and objective approach that will demonstrate integrity to the
> world and the Trust community.
>
> Regards,
> -Scott
>
>
> On 7/9/19, 7:31 PM, "dev-security-policy on behalf of Wayne Thayer via
> dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on
> behalf of dev-security-policy@lists.mozilla.org> wrote:
>
>     Caution: This email originated from outside DarkMatter. Do not click
> links or open attachments unless you recognize the sender and believe the
> content is safe.
>
>
> ------------------------------------------------------------------------------
>
>     I would like to thank everyone for their constructive input on this
>     difficult issue. I would also like to thank DarkMatter representatives
> for
>     participating in the open, public discussion. I feel that the
> discussion
>     has now, after more than 4 months, run its course.
>
>     The question that I originally presented [1] to this community was
> about
>     distrusting DarkMatter’s current intermediate CA certificates (6 total)
>     based on credible evidence of spying activities by the company. While a
>     decision to revoke trust in these intermediates would likely result in
> a
>     denial of DarkMatter’s root inclusion request [2], the public
> discussion
>     for that request has not yet begun. A decision not to revoke these
>     intermediates does not necessarily mean that the inclusion request
> will be
>     approved.
>
>     Some of this discussion has revolved around compliance issues, the most
>     prominent one being the serial number entropy violations discovered by
>     Corey Bonnell. While these issues would certainly be a consideration
> when
>     evaluating a root inclusion request, they are not sufficient to have
>     triggered an investigation aimed at revoking trust in the DarkMatter
>     intermediates or QuoVadis roots. Therefore, they are not relevant to
> the
>     question at hand.
>
>     Much of the discussion has been about the desire for inclusion and
> distrust
>     decisions to be made based on objective criteria that must be
> satisfied.
>     However, if we rigidly applied our existing criteria, we would deny
> most
>     inclusion requests. As I stated earlier in this thread, every distrust
>     decision has a substantial element of subjectivity. One can argue that
>     we’re discussing a different kind of subjectivity here, but it still
>     amounts to a decision being made based on a collective assessment of
> all
>     the information at hand rather than a checklist.
>
>     Some, including DarkMatter representatives [3], have declared the need
> to
>     examine and consider the benefits of having DarkMatter as a trusted CA.
>     However, last year we changed our policy to replace the weighing of
>     benefits and risks with “based on the risks of such inclusion to
> typical
>     users of our products.” [4]
>
>     Perhaps the most controversial element in this discussion has been the
>     consideration of “credible evidence”. The first component is the
> inherent
>     uncertainty over what is “credible”, especially in this day and age.
> While
>     it has been pointed out that respected news organizations are not
> beyond
>     reproach [5], having four independent articles [6][7][8][9] from
> reputable
>     sources published years apart does provide some indication that the
>     allegations are credible. These articles are also extensively sourced.
>
>     If we assume for a second that these allegations are true, then there
> is
>     still a sincere debate over what role they should play in our decision
> to
>     trust DarkMatter as a CA. The argument for considering these
> allegations is
>     akin to the saying “where there’s smoke there’s fire”, while the
> argument
>     against can be described as “innocent until proven guilty”.
>
>     DarkMatter has argued [3] that their CA business has always been
> operated
>     independently and as a separate legal entity from their security
> business.
>     Furthermore, DarkMatter states that once a rebranding effort is
> completed,
>     “the DarkMatter CA subsidiary will be completely and wholly separate
> from
>     the DarkMatter Group of companies in their entirety.” However, in the
> same
>     message, DarkMatter states that “Al Bannai is the sole beneficial
>     shareholder of the DarkMatter Group.” and leaves us to assume that Mr.
> Al
>     Bannai would remain the sole owner of the CA business. More recently,
>     DarkMatter announced that they are transitioning all aspects of the
>     business to DigitalTrust and confirmed that Al Bannai controls this
> entity.
>     This ownership structure does not assure me that these companies have
> the
>     ability to operate independently, regardless of their names and legal
>     structure.
>
>     Mozilla’s principles should be at the heart of this decision. “The
> Mozilla
>     Manifesto [10] states:
>
>     Individuals’ security and privacy on the internet are fundamental and
> must
>     not be treated as optional.”
>
>     And our Root Store policy states: “We will determine which CA
> certificates
>     are included in Mozilla's root program based on the risks of such
> inclusion
>     to typical users of our products.”
>
>     In other words, our foremost responsibility is to protect individuals
> who
>     rely on Mozilla products.  I believe this framing strongly supports a
>     decision to revoke trust in DarkMatter’s intermediate certificates.
> While
>     there are solid arguments on both sides of this decision, it is
> reasonable
>     to conclude that continuing to place trust in DarkMatter is a
> significant
>     risk to our users. I will be opening a bug requesting the distrust of
>     DarkMatter’s subordinate CAs pending Kathleen’s concurrence. I will
> also
>     recommend denial of the pending inclusion request, and any new requests
>     from DigitalTrust.
>
>     In the past, we’ve seen CAs attempt to make an end run around adverse
> trust
>     decisions - through an acquisition, a shell company, etc. We will
> treat any
>     such attempt as a violation of this decision and act accordingly.
> Mozilla
>     does welcome DigitalTrust as a “managed” subordinate CA under the
> oversight
>     of an existing trusted CA that retains control of domain validation
> and the
>     private keys.
>
>     This discussion has highlighted an opportunity to improve our review
> of new
>     externally-operated subordinate CAs [11]. This issue [12] is part of
> the
>     current policy update discussions.
>
>     Wayne
>
>     [1]
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ
>     [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
>     [3]
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/mJ0EV2eoCgAJ
>     [4]
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/58F6FgeGOz8/Zzb-r76wBQAJ
>     [5]
>
> https://www.washingtonpost.com/blogs/erik-wemple/wp/2018/11/27/bloomberg-is-still-reporting-on-challenged-story-regarding-china-hardware-hack/
>     [6]
>
> https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
>     [7]
> https://www.reuters.com/investigates/special-report/usa-spying-raven/
>     [8]
>
> https://www.nytimes.com/2019/03/21/us/politics/government-hackers-nso-darkmatter.html
>     [9] https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/
>     [10] https://www.mozilla.org/en-US/about/manifesto/
>     [11]
>
> https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits
>     [12] https://github.com/mozilla/pkipolicy/issues/169
>     _______________________________________________
>     dev-security-policy mailing list
>     dev-security-policy@lists.mozilla.org
>     https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to