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