Re: DarkMatter Concerns

[Ronald Crane via dev-security-policy]

NYT 12/23/2019 on the ToTok spying app and DarkMatter:

--
WASHINGTON — It is billed as an easy and secure way to chat by video or 
text message with friends and family, even in a country that has 
restricted popular messaging services like WhatsApp and Skype.


But the service, ToTok, is actually a spying tool, according to American 
officials familiar with a classified intelligence assessment and a New 
York Times investigation into the app and its developers. It is used by 
the government of the United Arab Emirates to try to track every 
conversation, movement, relationship, appointment, sound and image of 
those who install it on their phones


A technical analysis and interviews with computer security experts 
showed that the firm behind ToTok, Breej Holding, is most likely a front 
company affiliated with DarkMatter, an Abu Dhabi-based cyberintelligence 
and hacking firm where Emirati intelligence officials, former National 
Security Agency employees and former Israeli military intelligence 
operatives work. DarkMatter is under F.B.I. investigation, according to 
former employees and law enforcement officials, for possible 
cybercrimes. The American intelligence assessment and the technical 
analysis also linked ToTok to Pax AI, an Abu Dhabi-based data mining 
firm that appears to be tied to DarkMatter.

--

https://www.nytimes.com/2019/12/22/us/politics/totok-app-uae.html

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

Benjamin,

On behalf of Mozilla I'd like to acknowledge that your request has been
received and is under review.

- Wayne

On Tue, Jul 16, 2019 at 12:14 PM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Message Body (6 of 6)  APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS
>
> 1) Violation of Anti-Trust Laws:
>
> The Module Owner’s discretionary decision, when taken into context with
> the comments of other Mozilla Peers employed by other Browsers and/or
> competing Certificate Authorities, are intended to result in the types of
> unfair competition that are prohibited under the United States Sherman Act,
> the United States Federal Trade Commission Act, the Canadian Competition
> Act, the European Union Anti-Trust Policies, and the United Arab Emirates
> Competition Laws.
>
> a) Notwithstanding to the assertions for a decision “made on a collective
> assessment of all the information at hand”, the Module Owner, and Mozilla
> staff, have blatantly ignored, or failed to acknowledge and consider, the
> impact of anti-competitive comments made by Mr. Ryan Sleevi, a Google
> employee, with regard to the Applicants’ Root Inclusion request.
>
> > “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."
> [1]
>
> The above statement is quite startling in that it is being made by a
> representative of a dominant market power as an argument against the
> inclusion of a new economic participant’s entry into the global CA market
> place. In light of the fact that representative has tried to justify a
> technical non-compliance to support revocation of the Applicants’ Root
> Inclusion (note that significantly higher number of users were at risk due
> to the same serial entropy violations of his own employer Google) [2], and
> considering that this representative was a key player in the demonstration
> of dominant Browser market power against a significant CA global business
> [3], the Applicants have a reasonable basis to believe that the distrust
> discussion are more likely to be motivated by economic considerations that
> preserve incumbent parties market domination and monopolization.
>
> b) Additionally, the Module Owner, and Mozilla staff, have blatantly
> ignored, or failed to acknowledge and consider, the Applicants’ response to
> the Google Representative in their decision-making process. The General
> Counsel of DarkMatter asserted unambiguously in the public discussion as
> follows:
>
> We are of the view that CA monopolies are inherently bad for the internet
> in that they unfairly exploit market power. The result is a fundamental
> right to Internet security and privacy being deliberately priced out of
> reach for a significant population of the world.  We ask you, what can be
> more of an anti-competitive monopoly than a "well run store" (read
> Google/Mozilla) that does not take into consideration that sovereign
> nations have the fundamental right to provide digital services to their own
> citizens, utilizing their own national root, without being held hostage by
> a provider situated in another nation.” [4]
>
> The above discussions are highly relevant to the decision-making process,
> considering that the Module Owner is aware of the significant economic
> investment the Applicants have made in progressing the Root inclusion
> requests over the past two years.  In fact, the Applicants have received
> further communications from other relevant Browser Stores indicating that
> their respective decision to permit the Applicants to participate in the
> global CA business ecosystem will be based and influenced by the Mozilla
> Module Owner’s highly subjective discretionary decision. The entire global
> internet traffic is controlled by four (4) Browser Root Stores (Mozilla,
> Microsoft, Google and Apple). As Reuters pointed out in its July 4 story,
> three (3) of those Browser Stores will likely adopt and enforce this
> decision by Mozilla. In light of this, the Module Owner would be, or should
> be, aware of the significant economic harm of a decision based on less than
> verifiable “credible evidence”.
>
> c) Notwithstanding the above highly relevant elements of the public
> discussion, the Module Owner has now made a significant decision (on less
> than verifiable “credible evidence”) which we believe is intended to
> unfairly affect commerce in the global CA ecosystem through the use of the
> coercive influence he wields on the Applicants as a result of his
> discretionary decision making power. While rejecting the right of the
> Applicants to participate directly within the Mozilla Root Store, and by
> extension setting the stage for an outright denial of the Applicants’
> inclusions in any other browser store, the Module Owner has 

Finance analogies for root stores (was: Re: DarkMatter Concerns)

[Gijs Kruitbosch via dev-security-policy]

(I'm splitting the topic because at this point, continuing to discuss 
the analogy doesn't have a direct bearing on the inclusion or otherwise 
of DM)


Replies inline.

On 16/07/2019 23:23, Matthew Hardeman wrote:

I submit that I disagree somewhat with Gijs' suggestion that Mozilla acts
in the nature of a third-party guarantor here.  I further submit that the
more direct analogue is that the community of Mozilla users present
and future is the set of depositing members of the Mozilla Trust Credit
Union, a bank of trust/credit which is lended out to CAs from the pool of
trust + good will of those users -- that pool being under the direction and
management of the Mozilla organization, who, I believe, are literally
acting in the nature of a lender, loaning out the pooled assets (in this
case the sum of the trust extended to Mozilla) to qualified trust-borrowers
(CAs).  Mozilla is explicitly in the position of making decisions regarding
where to invest that pooled trust.


But as I already said, unlike financial institutions the trust store cannot:

- moderate the amount of trust/money
- tailor whatever the equivalent of repayments or interest would be to 
the profile of risk of a particular debtor (CA)

- demand a security from the debtor (CA)
- demand a guarantor who is liable if the debtor (CA) "defaults".

Instead, it is bound to treat every admitted debtor (CA) exactly the 
same, and a yes/no is the only decision it can make. That's... not 
really any power over the debtor at all, besides denying them access to 
the users ("pool of trust") *for the future only*. That is, at any point 
the trust store can stop providing further trust (credit). But there's 
almost nothing it can do about trust (credit) that's already been 
provided (certainly, in Mozilla's case, about TLS transactions in the 
past involving certs issued by the debtor/CA).



Indeed, if Mozilla is a mere guarantor in this process, who precisely is
the lender?


The lenders are the users, the CAs are debtors. Same as your example, 
really, except you're putting the trust store in a position where you 
claim it can control the debtors (ie as a credit union of users' trust), 
and I'm pointing out that such control does not exist in the same way as 
it does for lenders in the financial system. Instead the community's 
position wrt individual CAs once trust is broken is much more like 
someone who has to clean up after the debtor disappears (by 
investigating, discussing, then drawing conclusions, then 
distrusting-for-the-future and making sure both end users and site 
operators aren't unduly inconvenienced by the distrust of the 
"defaulting" CA). That's effectively the position of a guarantor - who 
can also refuse to act as a guarantor when a loan is setup, ie has a 
yes/no choice, but otherwise can't influence the agreement between 
lender and borrower itself.



I also disagree with the contention that Mozilla has "effectively no
recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
on the borrowed trust through providing services to certificate subscribers
only in compliance with program and industry guidelines and with proper
validations.)  Mozilla's recourse is essentially absolute: you can revoke
the trust you've extended, preventing further damage.


As you say, we can "prevent **further** damage". But there is no 
recourse for damage that has already happened. The potential for damage 
cannot be limited pre-emptively, nor is it possible to create incentives 
for the debtors to repay (ie no way to have a security) and there is no 
way to be compensated for damage caused once that's happened. Instead 
the trust store (here, Mozilla and the community in mdsp) get to clean 
up - and will refuse to sign up as guarantor for the same entity unless 
things change drastically, because we're not *that* stupid... And sure, 
that prevents future damage, but it does nothing to remedy damage in the 
past, which is not normally how things work for financial credit.


~ Gijs
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

I would like to point out that in the recent appeal PDF posted on bugzilla
showed darkmatter.ae in the footer on page 2 and onwards. This further
makes me believe that there is not much separation of the entities.

- Cynthia

On Wed, 17 Jul 2019, 01:29 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> I have to rebut the idea that revoking trust is an adequate -- let alone
> an "essentially absolute" -- recourse for a CA's abuse of its authority.
>
> The fact is that an abusive CA can cause unwanted (and potentially
> harmful) code and data to be injected into -- and personal data to be
> exfiltrated from -- nearly any user's device on the entire global internet.
>
> Once data is exfiltrated, its rightful owner has lost control of it
> forever. Revoking trust in the abusive CA that caused this loss does not
> amend it. Once a device is penetrated, it can be very difficult to
> disinfect, even assuming that the user knows that it has been
> penetrated. Such a device might function as a spy upon and/or an editor
> of its victim's data (and the data of persons with whom the victim
> communicates) indefinitely. An infected device is not in any way "fixed"
> by revoking trust in the abusive CA that caused it to become infected.
> Furthermore, an infected device can infect other devices, both locally
> and globally.
>
> The consequences to victims of breaches caused by an abusive CA can be
> extreme, potentially including prosecution, imprisonment, and worse. And
> revoking trust does nothing to amend these consequences.
>
> This is all but to say that enormous responsibility rests upon CAs, and
> even more so upon trust-store custodians, who effectively are supposed
> to protect every user on the global internet from bad actors. We must
> not lose sight of these facts while we argue about process, profit, and
> whatnot else.
>
> -R
>
> On 7/16/2019 2:23 PM, Matthew Hardeman via dev-security-policy wrote:
> > I also disagree with the contention that Mozilla has "effectively no
> > recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
> > on the borrowed trust through providing services to certificate
> subscribers
> > only in compliance with program and industry guidelines and with proper
> > validations.)  Mozilla's recourse is essentially absolute: you can revoke
> > the trust you've extended, preventing further damage.
>
> ___
> 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

Re: DarkMatter Concerns

[Ronald Crane via dev-security-policy]

I have to rebut the idea that revoking trust is an adequate -- let alone 
an "essentially absolute" -- recourse for a CA's abuse of its authority.


The fact is that an abusive CA can cause unwanted (and potentially 
harmful) code and data to be injected into -- and personal data to be 
exfiltrated from -- nearly any user's device on the entire global internet.


Once data is exfiltrated, its rightful owner has lost control of it 
forever. Revoking trust in the abusive CA that caused this loss does not 
amend it. Once a device is penetrated, it can be very difficult to 
disinfect, even assuming that the user knows that it has been 
penetrated. Such a device might function as a spy upon and/or an editor 
of its victim's data (and the data of persons with whom the victim 
communicates) indefinitely. An infected device is not in any way "fixed" 
by revoking trust in the abusive CA that caused it to become infected. 
Furthermore, an infected device can infect other devices, both locally 
and globally.


The consequences to victims of breaches caused by an abusive CA can be 
extreme, potentially including prosecution, imprisonment, and worse. And 
revoking trust does nothing to amend these consequences.


This is all but to say that enormous responsibility rests upon CAs, and 
even more so upon trust-store custodians, who effectively are supposed 
to protect every user on the global internet from bad actors. We must 
not lose sight of these facts while we argue about process, profit, and 
whatnot else.


-R

On 7/16/2019 2:23 PM, Matthew Hardeman via dev-security-policy wrote:

I also disagree with the contention that Mozilla has "effectively no
recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
on the borrowed trust through providing services to certificate subscribers
only in compliance with program and industry guidelines and with proper
validations.)  Mozilla's recourse is essentially absolute: you can revoke
the trust you've extended, preventing further damage.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

In fairness, I think Mozilla essentially stipulated that this reason was
given little or no weight in the decision.

Specifically Wayne Thayer noted at [1]:

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.


I certainly am not trying to divine something that's not there, but "not
relevant to the question at hand" fairly strongly suggests "was not a
factor in the decision".

[1]:
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/TseYqDzaDAAJ


On Tue, Jul 16, 2019 at 4:12 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think it's interesting how one of the main technical arguments for
> denying DarkMatter's root inclusion request -- the misissuance of
> certificates with 63-bit identifiers instead of 64-bit identifiers, also
> affected Google, Apple and Godaddy, and to a much greater extent:
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

Hi Kathleen and community,

I understand that you've made a decision w/r/t the DarkMatter CA matters
and am not writing to challenge or attempt influence on those.

I'm responding here only in so far as that you were "intrigued" by my
comments analogizing Mozilla Root Trust store decisioning to the kinds of
risk management exercised in assumption of financial risks such as in
consumer lending.  I'm writing to further expound on my positions in that
regard.

I submit that I disagree somewhat with Gijs' suggestion that Mozilla acts
in the nature of a third-party guarantor here.  I further submit that the
more direct analogue is that the community of Mozilla users present
and future is the set of depositing members of the Mozilla Trust Credit
Union, a bank of trust/credit which is lended out to CAs from the pool of
trust + good will of those users -- that pool being under the direction and
management of the Mozilla organization, who, I believe, are literally
acting in the nature of a lender, loaning out the pooled assets (in this
case the sum of the trust extended to Mozilla) to qualified trust-borrowers
(CAs).  Mozilla is explicitly in the position of making decisions regarding
where to invest that pooled trust.

Indeed, if Mozilla is a mere guarantor in this process, who precisely is
the lender?

I also disagree with the contention that Mozilla has "effectively no
recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
on the borrowed trust through providing services to certificate subscribers
only in compliance with program and industry guidelines and with proper
validations.)  Mozilla's recourse is essentially absolute: you can revoke
the trust you've extended, preventing further damage.  Just as a lender in
consumer finance has the ability to service and manage borrowers in their
current portfolio (for example, via periodic credit monitoring of current
borrowers), tools for the management and monitoring of program participants
exist: Certificate Transparency log monitoring as well as a fairly active
community of users who are actively digging for problems.

I agree that it's quite possible that the Mozilla Root program should be
far more selective.  Perhaps DarkMatter does not meet the bar.  If so,
though, I think there are a whole lot of other participants (including many
current participants) who also do not meet the bar, if one is to be
objective in these decisions.

In support of objectivity in these matters, I again raise the scenario:
Imagine you personally have to appear before a judge in some court for some
reason regarding rationale in program membership.  Do we want a future in
which this might be the testimony: "Your honor, CAs A, B, and C despite
having minor compliance issues directly aligned to program guidelines and
which were quickly remediated, those CAs met the bar for inclusion.
However, CAs D, E, and F despite meeting compliance burdens aligned to
program guidelines without exception, failed to meet the bar for inclusion
because of real or perceived shortcomings not directly aligned to program
guidelines."?

Whether by Mozilla's doing or not, inclusion in the Mozilla Root trust
store is essentially a prerequisite to access to other trust stores, access
to stores in various other OS distributions, access to default stores in
IoT devices being manufactured, etc.

These past couple of years have shown a very particular direction and focus
for the WebPKI.  (Broadly, from what I've seen, toward a domain-validated
only future with what is likely to evolve as a single static leaf
certificate profile.  Perhaps with caveats for signed exchange certs, etc.)

If that's truly where it's headed and if that future has a charitable CA
supported by the community, there does not really seem to be a place for
commercial CAs moving forward, with respect to the WebPKI.  Perhaps it
makes sense for the program to begin aligning policy to a "hard divorce" of
the public WebPKI from all other use cases?  This would likely dramatically
reduce incentives for commercial participants with intentions good or bad
from joining and maintaining membership in the program.  If that's where
it's headed anyway, it may be that a great deal of work [on the part of all
involved parties] can be avoided by being explicit on that intent sooner
rather than later.  Were you to do that -- and combine that with taking
steps that technologically make it infeasible to have a single TLS endpoint
usefully act as part of the WebPKI and a private hierarchy simultaneously,
I believe you could essentially eliminate much of the commercial and
government interest in program membership.  We would hopefully end up with
no more than a handful of equivalent but fully independent (managerially
and technologically) CAs in the image of Let's Encrypt and no reason for
any other CAs to be in the program.

On Tue, Jul 16, 2019 at 11:19 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

I think it's interesting how one of the main technical arguments for
denying DarkMatter's root inclusion request -- the misissuance of
certificates with 63-bit identifiers instead of 64-bit identifiers, also
affected Google, Apple and Godaddy, and to a much greater extent:

https://www.thesslstore.com/blog/mass-revocation-millions-of-certificates-revoked-by-apple-google-godaddy/

Google, Apple and GoDaddy didn't face any repercussions due to this,
obviously. Although, to quote from the above article:

"The point, obviously, isn’t to vilify Google – just to, once again, point
out the subjectivity of a lot of these decisions."

I'm sure there's a lot that I'm still missing, but from my perspective I
think it's pretty appalling how Mozilla has sunk low enough for DarkMatter
to have a legitimate claim of bias and unfair practice, and I hope
DarkMatter get the fair treatment they deserve, actually.

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

On Tue, Jul 16, 2019, 10:38 PM Benjamin Gabriel <
benjamin.gabr...@darkmatter.ae> wrote:

> Message Body (6 of 6)  APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS
>
> 1) Violation of Anti-Trust Laws:
>
> The Module Owner’s discretionary decision, when taken into context with
> the comments of other Mozilla Peers employed by other Browsers and/or
> competing Certificate Authorities, are intended to result in the types of
> unfair competition that are prohibited under the United States Sherman Act,
> the United States Federal Trade Commission Act, the Canadian Competition
> Act, the European Union Anti-Trust Policies, and the United Arab Emirates
> Competition Laws.
>
> a) Notwithstanding to the assertions for a decision “made on a collective
> assessment of all the information at hand”, the Module Owner, and Mozilla
> staff, have blatantly ignored, or failed to acknowledge and consider, the
> impact of anti-competitive comments made by Mr. Ryan Sleevi, a Google
> employee, with regard to the Applicants’ Root Inclusion request.
>
> > “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."
> [1]
>
> The above statement is quite startling in that it is being made by a
> representative of a dominant market power as an argument against the
> inclusion of a new economic participant’s entry into the global CA market
> place. In light of the fact that representative has tried to justify a
> technical non-compliance to support revocation of the Applicants’ Root
> Inclusion (note that significantly higher number of users were at risk due
> to the same serial entropy violations of his own employer Google) [2], and
> considering that this representative was a key player in the demonstration
> of dominant Browser market power against a significant CA global business
> [3], the Applicants have a reasonable basis to believe that the distrust
> discussion are more likely to be motivated by economic considerations that
> preserve incumbent parties market domination and monopolization.
>
> b) Additionally, the Module Owner, and Mozilla staff, have blatantly
> ignored, or failed to acknowledge and consider, the Applicants’ response to
> the Google Representative in their decision-making process. The General
> Counsel of DarkMatter asserted unambiguously in the public discussion as
> follows:
>
> We are of the view that CA monopolies are inherently bad for the internet
> in that they unfairly exploit market power. The result is a fundamental
> right to Internet security and privacy being deliberately priced out of
> reach for a significant population of the world.  We ask you, what can be
> more of an anti-competitive monopoly than a "well run store" (read
> Google/Mozilla) that does not take into consideration that sovereign
> nations have the fundamental right to provide digital services to their own
> citizens, utilizing their own national root, without being held hostage by
> a provider situated in another nation.” [4]
>
> The above discussions are highly relevant to the decision-making process,
> considering that the Module Owner is aware of the significant economic
> investment the Applicants have made in progressing the Root inclusion
> requests over the past two years.  In fact, the Applicants have received
> further communications from other relevant Browser Stores indicating that
> their respective decision to permit the Applicants to participate in the
> global CA business ecosystem will be based and influenced by the Mozilla
> Module Owner’s highly subjective discretionary decision. The entire global
> internet traffic is controlled by four (4) Browser Root Stores (Mozilla,
> Microsoft, Google and Apple). As Reuters pointed out in its July 4 story,
> three (3) of those Browser Stores will likely adopt and enforce this
> 

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (6 of 6)  APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

1) Violation of Anti-Trust Laws:

The Module Owner’s discretionary decision, when taken into context with the 
comments of other Mozilla Peers employed by other Browsers and/or competing 
Certificate Authorities, are intended to result in the types of unfair 
competition that are prohibited under the United States Sherman Act, the United 
States Federal Trade Commission Act, the Canadian Competition Act, the European 
Union Anti-Trust Policies, and the United Arab Emirates Competition Laws.

a) Notwithstanding to the assertions for a decision “made on a collective 
assessment of all the information at hand”, the Module Owner, and Mozilla 
staff, have blatantly ignored, or failed to acknowledge and consider, the 
impact of anti-competitive comments made by Mr. Ryan Sleevi, a Google employee, 
with regard to the Applicants’ Root Inclusion request.

> “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."  [1]

The above statement is quite startling in that it is being made by a 
representative of a dominant market power as an argument against the inclusion 
of a new economic participant’s entry into the global CA market place. In light 
of the fact that representative has tried to justify a technical non-compliance 
to support revocation of the Applicants’ Root Inclusion (note that 
significantly higher number of users were at risk due to the same serial 
entropy violations of his own employer Google) [2], and considering that this 
representative was a key player in the demonstration of dominant Browser market 
power against a significant CA global business [3], the Applicants have a 
reasonable basis to believe that the distrust discussion are more likely to be 
motivated by economic considerations that preserve incumbent parties market 
domination and monopolization.

b) Additionally, the Module Owner, and Mozilla staff, have blatantly ignored, 
or failed to acknowledge and consider, the Applicants’ response to the Google 
Representative in their decision-making process. The General Counsel of 
DarkMatter asserted unambiguously in the public discussion as follows:

We are of the view that CA monopolies are inherently bad for the internet in 
that they unfairly exploit market power. The result is a fundamental right to 
Internet security and privacy being deliberately priced out of reach for a 
significant population of the world.  We ask you, what can be more of an 
anti-competitive monopoly than a "well run store" (read Google/Mozilla) that 
does not take into consideration that sovereign nations have the fundamental 
right to provide digital services to their own citizens, utilizing their own 
national root, without being held hostage by a provider situated in another 
nation.” [4]

The above discussions are highly relevant to the decision-making process, 
considering that the Module Owner is aware of the significant economic 
investment the Applicants have made in progressing the Root inclusion requests 
over the past two years.  In fact, the Applicants have received further 
communications from other relevant Browser Stores indicating that their 
respective decision to permit the Applicants to participate in the global CA 
business ecosystem will be based and influenced by the Mozilla Module Owner’s 
highly subjective discretionary decision. The entire global internet traffic is 
controlled by four (4) Browser Root Stores (Mozilla, Microsoft, Google and 
Apple). As Reuters pointed out in its July 4 story, three (3) of those Browser 
Stores will likely adopt and enforce this decision by Mozilla. In light of 
this, the Module Owner would be, or should be, aware of the significant 
economic harm of a decision based on less than verifiable “credible evidence”.

c) Notwithstanding the above highly relevant elements of the public discussion, 
the Module Owner has now made a significant decision (on less than verifiable 
“credible evidence”) which we believe is intended to unfairly affect commerce 
in the global CA ecosystem through the use of the coercive influence he wields 
on the Applicants as a result of his discretionary decision making power. While 
rejecting the right of the Applicants to participate directly within the 
Mozilla Root Store, and by extension setting the stage for an outright denial 
of the Applicants’ inclusions in any other browser store, the Module Owner has 
decided as follows:

> 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. [5]

We are of the view that a fair-minded and objective observer would reasonably 
conclude that the above statement indicates that 

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (5 of 6) APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

1) Erroneous Legal Conclusions:

The Module Owner’s discretionary decision was guided by an erroneous legal 
conclusion, when he determined that the legal ownership structure of the 
Applicants was insufficient to allow them to operate independently.

a) Digital Trust is an affiliate of DarkMatter and has never been owned by it 
as a subsidiary since its incorporation in April 2016. Both companies are 
subsidiaries of their parent company, Dark Matter Investments. The Applicants 
have provided the necessary legal documents to Mozilla, and have further 
disclosed all ultimate beneficial shareholders in a transparent manner.

>  DarkMatter has argued 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. [1]

It is a fundamental principle of law that corporations have a statutory 
personality distinct from their shareholders. If taken at face value, the 
Module Owner’s erroneous assertion would imply that even the Mozilla Foundation 
and the Mozilla Corporation do not have the ability to operate independently, 
regardless of their names and legal structure.

It should be noted that a number of CAs, e.g. Google and Sectigo, have 
complicated ownership structures and this is not cited in their ability to 
operate independently. We note that to-date that the Module Owner has not made 
this type of claim against any other Mozilla Root Store participant.

Unless the above reasoning is held to be an Erroneous Legal Conclusion made by 
the Module Owner this would be, in our view, another new standard that will be 
discriminatorily applied only to the Applicants, solely on the basis of 
incorporation and residence in the United Arab Emirates.

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/TseYqDzaDAAJ


Benjamin Gabriel | General Counsel & SVP Legal
Tel: +971 2 417 1417 | Mob: +971 55 260 7410
benjamin.gabr...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.








___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (4 of 6) APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

1) Discriminatory Practices;

The Module Owner conducted his decision making process, and allowed the 
distrust discussion to proceed, in a manner contrary to the Mozilla Foundation 
commitment to an “Internet that includes all the peoples of the earth – where a 
person demographic characteristics do not determine their online access, 
opportunities, or quality of experience”.

a) The Applicants notified Mozilla of their Root Inclusion request in December 
of 2017. All TLS certificates (both EV and OV) were logged to CT.  The 
Applicants completed Webtrust certification for CA, for BRs, and for EV in 
October 2017, and submitted the United Arab Emirates Global Roots as well as 
the Applicants’ own Commercial Roots to Mozilla for inclusion.  In October 
2018, the Applicants completed their second year of the required WebTrust 
Audits for CA, BRs, and EV and provided the same to Mozilla for inclusion with 
their root submission. Mozilla completed a successful Policy/Process review of 
and technical review of the UAE Global Roots and the Applicants’ Commercial 
Roots in January of 2019.  Notwithstanding the above, nowhere in his decision, 
nor in the call for distrust, did the Module Owner provide any weight on the 
Applicants exemplary conduct in the CA community as reflected in their WebTrust 
audits over the period of time leading up to the distrust discussion.

In February of 2019, citing the disputed Reuters articles, the Module Owner, 
and Mozilla staff began the distrust of the UAE Global Roots, including the 
Applicants’ Commercial Roots, and implicitly put into question the right of the 
United Arab Emirates to operate its existing public trust subordinate CAs 
through a commercial party located in the United Arab Emirates.

b) The distrust discussion marked a significant departure from the existing 
Mozilla process, in that the Module Owner had now abandoned the reliance on 
technical compliance and any qualification of the CA or its ability to 
demonstrate compliant operations.

> Some, including DarkMatter representatives, 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.” [1]

The new standard which the Module Owner has now discriminatorily applied solely 
to the UAE Global Roots and the Applicants’ Commercial Roots appears to be on 
the hypothetical and unfounded basis of what the Applicants may allegedly do in 
the future.

All of the facts lead would lead an objective person to conclude that the 
Module Owner has established a dangerous precedent that he wishes to 
discriminatorily apply only to the Applicants, solely on the basis of 
incorporation and residence in the United Arab Emirates.

c) Notwithstanding the Module Owner’s comments about safeguarding the typical 
users of Mozilla products, and in regards to the false and unsubstantiated 
allegation that the Applicants have engaged in spying activities (which the 
Applicants have repeatedly indicated they do not do); other participants have 
highlighted that a number of other companies, who currently provide offensive 
security and surveillance related services have been enrolled in the Mozilla 
Root Program for a number of years. [2]

Notwithstanding the Module Owner’s assertion (in his decision) that “our 
foremost responsibility is to protect individuals who rely on Mozilla 
products”, to-date the Module Owner has not contemplated or triggered a 
distrust discussion against any of these parties.

If, in fact, this decision is truly motivated by the issue of “trust” and the 
protection of individuals (rather than the creation of additional barriers that 
preserve incumbent parties continued market domination and monopolization), we 
call on the Mozilla Foundation to apply the same standard that the Module Owner 
wishes to apply to the Applicants, and immediately start the process of 
distrust discussion for all CAs in the Mozilla Root Store who are either 
affiliated, directly, or indirectly, involved or even alleged to be in the 
business of offensive security and surveillance.

d) Furthermore, In accordance with the Mozilla “commitment to an internet that 
elevates critical thinking, reasoned arguments, shared knowledge, and 
verifiable facts”, we are of the view that the Module Owner failed in his 
fiduciary responsibility to moderate the distrust discussions, and reject 
public assertions that magnified divisive stereotypes about the United Arab 
Emirates and the Applicants.

The Module Owner would have, or should have known, that by remaining silent in 
the face of discriminatory and divisive comments about the United Arab Emirates 
and the Applicants, while at the same time continually highlighting the alleged 
and disputed Reuters’ 

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (3 of 6) APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

1) Abuse of Discretionary Power:

The Module Owner’s failure to consider relevant factors that should have been 
given significant, or equal weight, and deliberate mischaracterizations of 
facts intended to inflate the perceived risks of the Root Inclusion, resulted 
in an abuse of discretionary power.

a) The Module Owner, and Mozilla staff, have repeatedly indicated that the 
decision to distrust the Root Inclusion has been predicated on “credible 
evidence” as reported in the misleading Reuters articles (including those 
articles where Mozilla staff are quoted as news-makers), and on the totality of 
the information to be provided.

> “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 are discussing a different kind of subjectivity here, 
> but it still
> amounts to a decision being made on a collective assessment of all the 
> information
> at hand rather than a checklist.” [1]

The Applicants have repeatedly challenged the misleading Reuters articles as 
being based on a singular false and defamatory allegation. The CEO of 
DarkMatter formally, and publicly, communicated to the Module Owner by letter 
dated 26 February, 2019 refuting the misleading Reuters articles. [2]The 
CEO of DarkMatter has also gone on the record with various media refuting the 
baseless and defamatory allegations. [3]

Notwithstanding to the assertions for a decision “made on a collective 
assessment of all the information at hand”, the Module Owner, and Mozilla 
staff, have blatantly ignored, or failed to acknowledge and consider, any of 
the information provided by the Applicants to-date. On the other hand, the 
Module Owner has been less than impartial in his approach, consistently (in our 
view) minimizing the Applicants’ information, or public comments supporting the 
Applicants, while highlighting only those false, and disputed articles that 
push a hidden agenda against the United Arab Emirates and the Applicants. [4]

b) Since the Module Owner has singularly defined the purpose of the Root 
Inclusion discussions as a necessary requirement for the protection of the 
security and privacy of individuals, the Applicants provided concrete evidence 
demonstrating that their work since the very inception of the company, is 
fundamentally aligned with the goals of the Mozilla Manifesto. The Applicants 
further made a standing offer, for the Mozilla organization and other media 
parties to visit the United Arab Emirates to see directly for themselves the 
work being conducted by the Applicants.

More specifically, the Applicants have provided several recent examples of 
their pro-bono activities to the Module Owner with information regarding how 
critical security responsible disclosures are made by the Applicants and their 
affiliated companies, and which directly align with Mozilla’s principles to 
ensure that the internet, and other digital products, are safe for all users 
worldwide. E.g.:

-  Pgpool – PgPoolAdmin Responsible Disclosure [5]
-  Cisco - IP Phone Responsible Disclosure [6] [7]
-  Sony - Smart TV Responsible Disclosure [8]
-  FoxitSoftware - Foxit Reader Responsible Disclosure [9]
-  Samsung - S Family Responsible Disclosure [10]
-  LibreNMS Responsible Disclosure [11] [12] [13]
-  ABB - HMI Responsible Disclosure [14] [15] [16]

Notwithstanding the above, the Module Owner has either blatantly ignored, or 
failed to acknowledge and consider, any of the above information provided, or 
the invitations accorded, by the Applicants to-date, in making his decision.

c) In addition to attributing a false innuendo of “MitM Certificates” to the 
Applicants’ intention, the Module Owner has deliberately continued to 
mischaracterize the facts in a manner that is intended to overinflate the 
perceived risks of the Root Inclusion to the public at large.

> “The question that I originally presented to this community was about 
> distrusting
> DarkMatter’s current intermediate CA Certificates (6 total) based on credible 
> evidence
> of spying activities by the company.” [17]

The Module Owner is well aware that the original 3 intermediate CA Certificates 
(one for EV, one for OV, and one for Client Certificates) that were crated for 
public trust issuance within the UAE national PKI were name constrained and had 
already been revoked by QuoVadis/Digicert. [18]  A decision this significant 
should be based on accurate facts, and not on the sort of mischaracterization 
that overinflates the risk.

Considering that a number of community participants, including Ryan Sleevi, a 
Mozilla CA Module participant employed by Google, 

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (2 of 6) APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

2) Procedural Fairness/Bias:

The Module Owner’s decision making activities, and the supporting actions of 
other Mozilla staff, were not procedurally fair, transparent, absent of bias, 
nor made in good-faith.

a) The Applicants are headquartered in the United Arab Emirates, and have 
wholly-owned subsidiaries domiciled in Canada and the European Union.  The 
Applicants conduct all of their business strictly in accordance with the laws 
of the jurisdictions in which they operate and continue to do so.  Over the 
past three and half (3.5) years, the Applicants have successfully completed two 
(2) Web Trust public audits verifying that the Applicants CA business is 
operating in accordance with the technical standards stipulated within Mozilla 
Root Store Policy and the latest version of the CA/Browser Forum Requirements 
for the Issuance and Management of Publicly-Trusted Certificates. Furthermore, 
the Applicants have been ISO9001 and ISO27001 certified in their quality and 
information systems management as an independent verification of the management 
controls and governance in place for the operations of the business itself.

b) To-date the Applicants have not been cited for any non-compliance with the 
laws of the jurisdictions in which they operate, and there has never been any 
credible evidence of their malfeasance in any form or shape whatsoever.

c) Notwithstanding the above, by directly asserting and attributing a false 
innuendo of “MitM Certificates” to the Applicants’ intention, the Module Owner 
deliberately framed the public discussion about the merits of the Root 
Inclusion requests in a significantly detrimental manner from the outset.

> “In the past Mozilla has taken action against CAs found to have issued MitM 
> certificates.
> We are not aware of direct evidence of misused certificates in this case. 
> However,
> the evidence does strongly suggest that misuse is likely to occur, if it has 
> not already.” [1]

The Module Owner would have, or should have known, that framing the public 
discussion in such an inflammatory statement would “intentionally manipulate 
fact and reality” and deliberately distort the Root Inclusion discussion in a 
manner that misinforms the public about the Applicants Root Inclusion and their 
activities. The Module Owner chose to imply the negative innuendos about “MitM 
Certificates” even though there was no credible evidence available to him as to 
such malfeasance by the Applicants in the more than three (3) years within 
which as the Module Owner he would have been aware of the Applicants work and 
Root Inclusion request.

d) Concerted efforts by Mozilla staff to publicly pre-judge the issue, by 
soliciting and providing follow-up interviews to the media, were solely 
intended to undermine the efforts of the Applicants in disputing the misleading 
articles used as the basis for biasing the Root Inclusion public discussions.

> “We don’t currently have technical evidence of misuse (by DarkMatter) but the
> reporting is strong evidence that misuse is likely to occur in the future if 
> it hasn’t
> already,” said Selena Deckelmann, a senior director of engineering for 
> Mozilla. [2]

The Module Owner, and Mozilla staff, would have, or should have, known that by 
deliberately fanning the controversy (as news-makers rather than impartial 
adjudicators), they would harm the prospects of a fair process for the 
Applicants’ Root Inclusion. We are of the view that Mozilla staff did a great 
disservice to the idea of "trust" - when they persisted in a concerted effort 
with Reuters - to accelerate the false narrative about the Applicants, solely 
because they were a commercial CA business head-quartered in the United Arab 
Emirates.

This undue interference by the Module Owner, and Mozilla staff, demonstrated an 
abdication of impartiality, extreme prejudicial bias in the decision making 
process, and a hidden organizational animus, that is fatal to the idea of “due 
process” and “fundamental fairness” being accorded to the Applicants by Mozilla 
in this Root Inclusion.

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/YiybcXciBQAJ
[2] 
https://www.reuters.com/article/us-usa-spying-darkmatter/firefox-maker-fears-darkmatter-misuse-of-browser-for-hacking-idUSKCN1QL28T


Benjamin Gabriel | General Counsel & SVP Legal
Tel: +971 2 417 1417 | Mob: +971 55 260 7410
benjamin.gabr...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Message Body (1 of 6) APPEAL TO MOZILLA FOUNDATION BOARD OF DIRECTORS

Mozilla Foundation Board of Directors
Attention: Mitchell Baker, Executive Chairwoman

Mozilla Corporation
Attention: Chris Beard, CEO
Attention: Denelle Dixon-Thayer, General Counsel

July 16, 2019

Mozilla CA Certificate Policy Module: Appeal of the Module Owner Decision Dated 
July 9, 2019

Dear Sirs/Mesdames

In accordance with the Mozilla organization’s dispute resolution mechanism [1], 
I am writing to the Mozilla Foundation Board of Directors and the Mozilla 
Corporation, to formally dispute the decision of Mr. Wayne Thayer (“Module 
Owner”), the current owner of the Mozilla CA Certificate Policy module 
(“Mozilla CA Module”), dated July 9, 2019 (and concurred to by Ms. Kathleen 
Wilson on July 16, 2019), with regard to the Mozilla Root Store inclusion 
request for both the United Arab Emirates Global Roots and the Digital Trust 
Commercial Roots (“Root Inclusion”) originally made by Dark Matter LLC 
(“DarkMatter”) and currently being progressed by its affiliate Digital Trust 
LLC (“Digital Trust”, and together with DarkMatter, the “Applicants”).

In the conduct of his discretionary decision, the Module Owner recommended (1) 
a rejection of the Applicant’s Root Inclusions, (2) a prohibition of any new 
additional Root Inclusion requests from Digital Trust, and (3) opened a bug 
request for an additional distrust of existing intermediate CA certificates 
created for public trust within the UAE national PKI. [2]

The Module Owner’s discretionary decision is disputed, and an appeal to the 
Mozilla Foundation Board of Directors is lodged, on the grounds of (1) 
Undisclosed Conflict of Interest, (2) Procedural Fairness/Bias, (3) Abuse of 
Discretionary Power, (4) Discriminatory Practices, (5) Erroneous Legal 
Conclusions, and (6) Violation of Global Anti-Trust Laws, as more fully 
detailed below:

(1) Conflict of Interest:

The Module Owner failed to recognize, or blatantly ignored, undisclosed 
Conflict of Interests posed by certain participants (including Mozilla Staff) 
who represent for-profit corporations with a significant (including, but not 
limited, to global market dominance and monopolization power) economic interest 
in the outcome of the Applicant’s Root Inclusion, and the distorting impact of 
such Conflict of Interests on the Module Owner’s discretionary decision.

a) The Mozilla Corporation is a wholly-owned for-profit subsidiary of the 
Mozilla Foundation.  The for-profit Mozilla Corporation provides internet based 
browser software and other related services. Access to the entire global 
internet traffic is controlled by four (4) Browser Root Stores (Mozilla 
Corporation, Google, Microsoft and Apple).  Two of these commercial Browser 
Root Stores are the most significant search engine providers on the internet, 
and therefore have a substantial economic interest in the global Certificate 
Authority business (including in the United Arab Emirates).  Approximately 93% 
to 94% of Mozilla Corporation’s revenues are derived from such search engine 
providers.  [3]

b) The Module Owner is employed by the for-profit Mozilla Corporation as a 
Certificate Authority Program manager. Key Mozilla staff who are involved in 
framing the negative media feedback about the Root Inclusion are also employed 
by the for-profit Mozilla Corporation. [4]  Key CA/Policy participants in the 
Mozilla CA Module are also employed by other commercial Certificate 
Authorities/or Browser Stores which have a significant economic stake in the 
Root Inclusion decision [5].

c) In light of the above, the Module Owner had a responsibility to ensure that 
any Conflict of Interests by any participants in the Root Inclusion discussions 
are clarified for the record so that undisclosed interests (including economic 
market domination and monopolization of the global Certificate Authority 
business ecosystem) which may distort the Module Owner’s decision making 
process are publicly disclosed for interested media, the general public, and 
global trade/competition regulators.

d) The Applicants have repeatedly brought their concerns with Conflict of 
Interests to the attention of the Module Owner.

> “While we welcome the public discussion as a vital component in the 
> maintenance of trust and
> transparency in Mozilla’s Root Store, we wish to bring to your attention, and 
> to other esteemed
> CABForum members, DarkMatter’s reasonable apprehension of bias and conflict 
> of interest in how
> the Mozilla organization has framed and conducted the discussion at hand.  
> Notwithstanding the stated
> goal of transparency in the public discussion, recent public comments by 
> Mozilla employees
> (including your opening statement in the discussion), indicate a hidden 
> organizational animus that is fatal
> to the idea of “due process” and “fundamental fairness” being accorded to any 
> CA applicant to
> the Mozilla Root Store. [6]

The Applicants explicitly 

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

A formal appeal has been filed with the Mozilla Foundation Board of Directors.  
In the spirit of transparency, we will be posting the contents of the Appeal to 
this forum in six (6) separate messages.

Benjamin Gabriel




Benjamin Gabriel | General Counsel & SVP Legal
Tel: +971 2 417 1417 | Mob: +971 55 260 7410
benjamin.gabr...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

-Original Message-
From: dev-security-policy  On 
Behalf Of Kathleen Wilson via dev-security-policy
Sent: Tuesday, July 16, 2019 8:20 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DarkMatter Concerns

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.

--

All,

Thanks again to all of you who have been providing thoughtful and constructive 
input into this discussion. As I previously indicated [1], this has been a 
difficult decision to make. I have been carefully reading and contemplating the 
input that you all have been providing in this forum.

I concur with Wayne’s recommendation [2] to add DarkMatter’s existing 
intermediate certificates to OneCRL 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1564544), and decline 
DarkMatter’s root inclusion request 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1427262). I will update those 
bugs to reflect my decision to distrust the intermediate certs and to decline 
the root inclusion request.

I also concur with Wayne that DarkMatter (a.k.a DigitalTrust) is welcome to be 
a “managed” subordinate CA under the oversight of an existing trusted CA that 
retains control of domain validation and the private keys.

Below are some additional comments I would like to share.

I was intrigued by Matthew’s FICO score analogy [3] demonstrating that bias 
should be removed from the decision making process. I agree with Gijs’ 
suggestion [4] that a more applicable analogy is being a guarantor on a large 
loan. As Gijs’ said: you should never “be a guarantor for anybody unless you're 
very, very sure of that person, because you have effectively no recourse if the 
debtor leaves you holding the bag.” If I had thought of myself (or Mozilla) as 
a guarantor of the CNNIC CA, then all of the concerns that people had raised 
about CNNIC during their root inclusion request would have enabled me to say 
that I was not confident that CNNIC would continue to fulfill their commitments 
as a CA in Mozilla’s program. That could have prevented the difficulties that 
arose when the CNNIC root was used to mis-issue TLS certificates that were 
subsequently used for MiTM.

Some of you have pointed out that Mozilla needs to provide more oversight and 
scrutiny of subordinate CAs, and I fully agree with you.
With over 3,000 subordinate CA certificates chaining to root certificates in 
Mozilla’s program, we need automation to extend checks and balances to all of 
them. I have been working towards this via the Common CA Database (CCADB) [5]. 
The good news is that most of the subordinate CAs in Mozilla’s program are 
“managed” subordinate CAs, which means that the root CA retains control of the 
private keys and domain validation. As Wayne mentioned, we are also working on 
improving our policy and process to provide better oversight of the other, 
“externally-operated”, subordinate CAs[6,7].

Thanks,
Kathleen

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/TseYqDzaDAAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/HiAMJkBNDQAJ
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/XXp1KIBoDQAJ
[5] https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/
[6]
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits
[7] 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

Re: DarkMatter Concerns

[Kathleen Wilson via dev-security-policy]

All,

Thanks again to all of you who have been providing thoughtful and 
constructive input into this discussion. As I previously indicated [1], 
this has been a difficult decision to make. I have been carefully 
reading and contemplating the input that you all have been providing in 
this forum.


I concur with Wayne’s recommendation [2] to add DarkMatter’s existing 
intermediate certificates to OneCRL 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1564544), and decline 
DarkMatter’s root inclusion request 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1427262). I will update 
those bugs to reflect my decision to distrust the intermediate certs and 
to decline the root inclusion request.


I also concur with Wayne that DarkMatter (a.k.a DigitalTrust) is welcome 
to be a “managed” subordinate CA under the oversight of an existing 
trusted CA that retains control of domain validation and the private keys.


Below are some additional comments I would like to share.

I was intrigued by Matthew’s FICO score analogy [3] demonstrating that 
bias should be removed from the decision making process. I agree with 
Gijs’ suggestion [4] that a more applicable analogy is being a guarantor 
on a large loan. As Gijs’ said: you should never “be a guarantor for 
anybody unless you're very, very sure of that person, because you have 
effectively no recourse if the debtor leaves you holding the bag.” If I 
had thought of myself (or Mozilla) as a guarantor of the CNNIC CA, then 
all of the concerns that people had raised about CNNIC during their root 
inclusion request would have enabled me to say that I was not confident 
that CNNIC would continue to fulfill their commitments as a CA in 
Mozilla’s program. That could have prevented the difficulties that arose 
when the CNNIC root was used to mis-issue TLS certificates that were 
subsequently used for MiTM.


Some of you have pointed out that Mozilla needs to provide more 
oversight and scrutiny of subordinate CAs, and I fully agree with you. 
With over 3,000 subordinate CA certificates chaining to root 
certificates in Mozilla’s program, we need automation to extend checks 
and balances to all of them. I have been working towards this via the 
Common CA Database (CCADB) [5]. The good news is that most of the 
subordinate CAs in Mozilla’s program are “managed” subordinate CAs, 
which means that the root CA retains control of the private keys and 
domain validation. As Wayne mentioned, we are also working on improving 
our policy and process to provide better oversight of the other, 
“externally-operated”, subordinate CAs[6,7].


Thanks,
Kathleen

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/TseYqDzaDAAJ
[3] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/HiAMJkBNDQAJ
[4] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/XXp1KIBoDQAJ

[5] https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/
[6] 
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits

[7] 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

Re: DarkMatter Concerns

[Gijs Kruitbosch via dev-security-policy]

On 11/07/2019 03:38, Matthew Hardeman wrote:

I used
the parallel to racism in finance because it's exceedingly well documented
that strong objective systems of risk management and decisioning led to
better overall financial outcomes AND significantly opened the door to
credit (aka trust) to otherwise improperly maligned and underserved
communities.


(for the avoidance of doubt: writing in a personal capacity - although I 
work for Mozilla I have nothing to do with this decision.)


Financial credit really isn't "aka trust".

The "strong objective system of risk management and decisioning" 
includes the ability to risk manage (e.g. in determining the amount of 
credit, the interest rate, including a guarantor, including a security, 
requiring certain types of insurance so the creditor doesn't lose out if 
the debtor dies, ...), and there's no way for a trust store to "risk 
manage" a CA in any of those ways. Mozilla can't limit issuance to a 
certain number of certificates, or a certain set of domains, or set 
financial penalties for misissuance, or ...


Additionally, the repayments to credit once an agreement is struck 
provide complete information about current performance of the debtor, 
which there isn't in the CA world. And should repayments stop, the 
lender normally has some means of recuperating losses (whether that's 
through the object which secured the loan, through the guarantor, or the 
court/bailiff system), and the only people affected are the lender and 
the debtor (and guarantor, if any). None of that is true for a trust 
store, either, where the people affected by a "default" are the relying 
parties.


If we're going to make a comparison to finance, this is more akin to 
Mozilla being asked to sign up as guarantor for every CA, in a huge loan 
that's being extended by all the users of their trust store. Any 
financial adviser worth their salt will tell you never to be a guarantor 
for anybody unless you're very, very sure of that person, because you 
have effectively no recourse if the debtor leaves you holding the bag.


~ Gijs
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[westmail24--- via dev-security-policy]

As an ordinary user from.Russia, I am very glad that DarkMatter is rejected in 
this thread. If for example there are complaints about some kind of plastic 
surgeon, then it is better to refuse the operation than to immediately start 
trying on yourself having believed his documents and risking to get a crooked 
face...

Sincerely, Andrew.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Wed, Jul 10, 2019 at 11:43 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
>

I broadly concur with these points.

In other significant risk management disciplines and domains in which a
plurality of diverse applicants seek trust, objectivity and strong
data-backed alignment of specific risk factors associated to specific bad
outcomes are prized above practically all else.  An obvious example is
consumer credit lending and particularly large loans like mortgages.

As an analogy, consider that at least in a broad directional sense, the
change in Mozilla's decisioning and underlying reasoning is akin to moving
from a mechanism where one particular FICO score means one particular
outcome regardless of the color of your skin or sexuality and toward a
mechanism in which despite having matching FICO scores two applicants and
their applications share dissimilar fates: one of them is declined not for
falling outside of objective risk management criteria but because they
"seem shady" or "fit the description of someone who did something bad" or
"just aren't a good match for our offering".  In finance, such decisioning
wouldn't survive the most cursory and forgiving review.  That "fact"
pattern wouldn't overcome a claim of racism even if the lender and the
applicant whose loan was declined were of the same race.

Please let me be quite specific in that I am not suggesting that there is
racial or national animus expressed in this decision by Mozilla.  I used
the parallel to racism in finance because it's exceedingly well documented
that strong objective systems of risk management and decisioning led to
better overall financial outcomes AND significantly opened the door to
credit (aka trust) to otherwise improperly maligned and underserved
communities.

To my mind, this decision is regression from a more formal standard and
better compliance monitoring than has ever been available (CT, etc.) to a
subjective morass with handwringing and feelings and bias.

I can not see how one reconciles taking pride in their risk management and
compliance acumen while making such a regression.  That kind of dissonance
would eat at my soul.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

Dear Ryan,

In outlining the two paths that I presented at the end of my previous
email, I made sure to illustrate the choice between them as one that comes
repeatedly -- a conscious choice that every time produces a small,
incremental improvement, often through a tiresome and onerous process.
Indeed I was trying to support slow, grinding iterations towards the better
-- and that's not at all something that sounds to me like sticking out for
only the perfect solution. And indeed I supported the subjective and
deliberative path as often necessary and wise when time is of the essence.
I find it very surprising that you seem to believe that I was arguing for
perfection -- quite the opposite, in fact.

I do still believe that when we fall back to relying on mainstream news
articles, with no obvious fallback in procedure, then it's reasonable for
people like me to chime in and wonder about a potential lack of rigor.
Every potential participant in this thread comes with their own
misconceptions and lack of information, and I'm no exception, but I still
find that my original source of concern holds. My impression at least is
that it's produced a worthwhile and valuable discussion for everyone (in no
small part thanks to your own time and effort). And of course, I don't mean
to admonish anyone here with the points of discussion that I've raised, and
I would certainly like to think that nobody feels admonished by anyone else
so far in this thread.

I am very glad that others are working slowly on the long term effort for
better policy. I think these issues are fundamental to the Internet's
safety and hope that I'll be able to help out more one day in whatever way
I can volunteer.

Thank you,

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


On Wed, Jul 10, 2019 at 9:59 PM Ryan Sleevi  wrote:

>
>
> On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi 
> wrote:
>
>> Many times in this discussion, we have all been offered a choice between
>> two paths. The first path would be to examine difficult problems and
>> shortcomings together and attempting to present incremental--often
>> onerous--improvements. The second path would be to just say that someone
>> should trust us based on years of subjective experience. In many, many
>> cases, the latter really is a wise thing to say and a correct thing to say
>> (and I truly mean this); it offers a path through which judicious decisions
>> are often made. Furthermore, it is often a necessary path to take when time
>> is of the essence. But it is seldom the rigorous path to take, seldom the
>> path that serves future engineers and practitioners in the field, and
>> seldom the path that gives institutions the foundation and the standing
>> that they will need in the decades to come.
>>
>
> Hi Nadim,
>
> There's a phrase to capture the essence of what you propose doing. It is
> that the perfect is the enemy of the good. Wikipedia even helpfully
> contains a useful quote in the context of Robert Watson-Watt.
>
> It is important that, while these flaws are recognized and being worked
> on, there is still a duty of care and community responsibility. There's
> clearly a school of thinking, which you appear to be advocating, that the
> best solution when something is less than perfect is to not do it at all,
> since doing nothing is the only 'fair' choice. Perhaps that's not your
> intent, but I want to highlight, you've repeatedly admonished the folks who
> have spent years into understanding and improving the ecosystem that
> they're not doing enough, or that it isn't rigorous enough.
>
> By way of analogy, which is admittedly a poor way to argue, it would be
> akin to someone arguing that out-of-band writes should not be fixed,
> because fixing OOB writes is not rigorous, and instead it should be
> rewritten in Rust. While it's certainly true that rewritting in Rust is
> likely to improve things, that's a bit of what we in the industry term a
> "long term" effort. In the mean time, as pragmatic professionals who care
> about security, long-term participants on this list are approaching both
> pragmatic and long-term solutions.
>
> There's not much I can say about the claimed lack of rigor. It appears
> that you were not familiar with long-standing policies or discussions, the
> means of approaching both the short-term risks and the long-term, the
> efforts to ensure consistency and reliability, and the acknowledged
> near-term gaps that necessitate a pragmatic approach. It's a bit like
> arguing that, since you have an OOB Write, the best path to take is to
> either do nothing to fix it, and in fact continue writing more code in
> unsafe languages, or do nothing until you replace it all. Neither, of
> course, are paths of rigor, and neither are paths that serve future
> engineers and practitioners in the field, nor do they give foundation and
> standing to the trust and safety of users.
>
> A different parallel to take would be that ignoring these 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

Dear Ryan,

Thanks very much for this very insightful email. There really is a lot that
I and others don't know about how these decisions are made.

The silver lining here is that we agree on where some of the gaps are in
this process, and that Mozilla, Google and others are working on filling in
these gaps, as you say. I would argue that the existence of so many
conflicts of interests, intricacies and complexities between the multiple
stakeholders in such decisions make it more urgent to fill in these gaps
quickly and completely.

If the existing documentation are insufficient in order to provide a full
set of distinguishers on the intricacies of this process, then it stands to
reason that they should be improved. If a certain terminology is too broad,
it stands to reason that it can be made less broad. If layman's terms are
deployed for non-layman concepts, it stands to reason that this should be
modified and its underlying concept elucidated. If incompetent auditors
cannot be differentiated from competent auditors, it stands to reason that
this can be addressed. If areas exist where conflicts of interests are
likely, it stands to reason that policies can be expanded to avoid these
conflicts of interests from occurring.

So long as we can continue to point to specific problems and shortcomings,
which you do masterfully and to great public service in your email, it will
always stand to reason that we can improve our policies such that the gaps
are filled. And again, it's wonderful that Mozilla, Google etc. are working
on this.

Many times in this discussion, we have all been offered a choice between
two paths. The first path would be to examine difficult problems and
shortcomings together and attempting to present incremental--often
onerous--improvements. The second path would be to just say that someone
should trust us based on years of subjective experience. In many, many
cases, the latter really is a wise thing to say and a correct thing to say
(and I truly mean this); it offers a path through which judicious decisions
are often made. Furthermore, it is often a necessary path to take when time
is of the essence. But it is seldom the rigorous path to take, seldom the
path that serves future engineers and practitioners in the field, and
seldom the path that gives institutions the foundation and the standing
that they will need in the decades to come.

I sincerely appreciate the formidable passion with which you argue for your
positions, and am glad that someone like you holds the responsibility that
you do.

Thank you,

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


On Wed, Jul 10, 2019 at 8:42 PM Ryan Sleevi  wrote:

>
>
> On Wed, Jul 10, 2019 at 2:15 PM Nadim Kobeissi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Indeed I would much rather focus on the rest of the elements in the
>> Mozilla
>> Root Store Policy (
>>
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
>> )
>> which are less vapidly authoritarian than the single clause you quote, and
>> which focus more on a set of audits, confirmations and procedures that
>> give
>> everyone a fair chance at proving the honesty of their role as a
>> certificate authority. For example, I find policy points 2.2 (Validation
>> Practices), 3.1.1 (Audit Criteria) and 3.1.4 (Public Audit Information) to
>> be much more of a fertile ground for future discussion.
>>
>
> I appreciate that attempt to focus. However, it does again fundamentally
> misunderstand things in ways that are critical in demonstrating why this
> discussion is not productive or fruitful, and your suggestions are quite
> misguided.
>
> For example, judging by your replies, it seems you may not understand
> audits, what they are, or how they work.
>
> During an audit, someone who agrees to a voluntary set of professional
> standards, such as a Chartered Public Accountant, agrees to perform an
> audit using a specific set of Principles and Criteria. The Principles are
> very broad - for example, the three principles are "CA Business Practices
> Disclosure", "Service Integrity", and "CA Environmental Controls". These
> don't tell you very much at all, so then there are individual Criteria.
>
> However, the Criteria are very broad: for example: "The CA maintains
> controls to provide reasonable assurance that its Certification Practice
> Statement (CPS) management processes are effective."
>
> Now, you may not realize, but "reasonable assurance" and "effective" are
> not layman's terms, but refer to specific procedures that vary by country
> and professional standards (e.g. AICPA standards like the AT series or CPA
> Canada standards like CSAE)
>
> During the process of an audit, the auditors role is primarily to look at
> things and say "Yeah, that sounds right". It is not, for example,
> adversarial and look for counterfactuals. It does not, for example, include
> specific steps the auditor 

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi 
wrote:

> Many times in this discussion, we have all been offered a choice between
> two paths. The first path would be to examine difficult problems and
> shortcomings together and attempting to present incremental--often
> onerous--improvements. The second path would be to just say that someone
> should trust us based on years of subjective experience. In many, many
> cases, the latter really is a wise thing to say and a correct thing to say
> (and I truly mean this); it offers a path through which judicious decisions
> are often made. Furthermore, it is often a necessary path to take when time
> is of the essence. But it is seldom the rigorous path to take, seldom the
> path that serves future engineers and practitioners in the field, and
> seldom the path that gives institutions the foundation and the standing
> that they will need in the decades to come.
>

Hi Nadim,

There's a phrase to capture the essence of what you propose doing. It is
that the perfect is the enemy of the good. Wikipedia even helpfully
contains a useful quote in the context of Robert Watson-Watt.

It is important that, while these flaws are recognized and being worked on,
there is still a duty of care and community responsibility. There's clearly
a school of thinking, which you appear to be advocating, that the best
solution when something is less than perfect is to not do it at all, since
doing nothing is the only 'fair' choice. Perhaps that's not your intent,
but I want to highlight, you've repeatedly admonished the folks who have
spent years into understanding and improving the ecosystem that they're not
doing enough, or that it isn't rigorous enough.

By way of analogy, which is admittedly a poor way to argue, it would be
akin to someone arguing that out-of-band writes should not be fixed,
because fixing OOB writes is not rigorous, and instead it should be
rewritten in Rust. While it's certainly true that rewritting in Rust is
likely to improve things, that's a bit of what we in the industry term a
"long term" effort. In the mean time, as pragmatic professionals who care
about security, long-term participants on this list are approaching both
pragmatic and long-term solutions.

There's not much I can say about the claimed lack of rigor. It appears that
you were not familiar with long-standing policies or discussions, the means
of approaching both the short-term risks and the long-term, the efforts to
ensure consistency and reliability, and the acknowledged near-term gaps
that necessitate a pragmatic approach. It's a bit like arguing that, since
you have an OOB Write, the best path to take is to either do nothing to fix
it, and in fact continue writing more code in unsafe languages, or do
nothing until you replace it all. Neither, of course, are paths of rigor,
and neither are paths that serve future engineers and practitioners in the
field, nor do they give foundation and standing to the trust and safety of
users.

A different parallel to take would be that ignoring these well-known,
well-documented limits to understanding would be a bit like ignoring the
well-known, well-documented limits of JavaScript cryptography, and
attempting to write a chat application in Javascript and promoting it for
human rights or dissident safety. While it's certainly a path one could
take, it's hardly a responsible one, just like it would be irresponsible to
ignore both the limits of audits and the fundamental role in subjective,
but thoughtful, evaluation of the risks comparative to the benefits.

[1] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 10, 2019 at 2:15 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Indeed I would much rather focus on the rest of the elements in the Mozilla
> Root Store Policy (
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> )
> which are less vapidly authoritarian than the single clause you quote, and
> which focus more on a set of audits, confirmations and procedures that give
> everyone a fair chance at proving the honesty of their role as a
> certificate authority. For example, I find policy points 2.2 (Validation
> Practices), 3.1.1 (Audit Criteria) and 3.1.4 (Public Audit Information) to
> be much more of a fertile ground for future discussion.
>

I appreciate that attempt to focus. However, it does again fundamentally
misunderstand things in ways that are critical in demonstrating why this
discussion is not productive or fruitful, and your suggestions are quite
misguided.

For example, judging by your replies, it seems you may not understand
audits, what they are, or how they work.

During an audit, someone who agrees to a voluntary set of professional
standards, such as a Chartered Public Accountant, agrees to perform an
audit using a specific set of Principles and Criteria. The Principles are
very broad - for example, the three principles are "CA Business Practices
Disclosure", "Service Integrity", and "CA Environmental Controls". These
don't tell you very much at all, so then there are individual Criteria.

However, the Criteria are very broad: for example: "The CA maintains
controls to provide reasonable assurance that its Certification Practice
Statement (CPS) management processes are effective."

Now, you may not realize, but "reasonable assurance" and "effective" are
not layman's terms, but refer to specific procedures that vary by country
and professional standards (e.g. AICPA standards like the AT series or CPA
Canada standards like CSAE)

During the process of an audit, the auditors role is primarily to look at
things and say "Yeah, that sounds right". It is not, for example,
adversarial and look for counterfactuals. It does not, for example, include
specific steps the auditor must perform; those steps are merely
illustrative. A CA may actually significantly fail in its management
processes, but the auditor might determine that, even despite those
failures, the assurance provided was still "reasonable" so as to be
effective.

The process starts with the auditor assuming they're doing nothing, and the
CA showing positive evidence that supports each thing. Negative evidence
can and is overlooked, if there are other positive controls to be used.
Mozilla, in collaboration with Google and others, has been working for
years to address this gap, but I believe it's reasonable to say that the
existence of an audit is by no means a positive sign for a CA; it merely
serves as a filtering function for those too bad to operate, and even then,
only barely.

You might expect that the auditor have skill and familiarity with PKI.
However, that's a very subjective measurement itself. The WebTrust
licensing body may or may not perform an examination as to the skills of
the auditor. Like some participants here, the auditor might feel they're
skilled in PKI and have a well-formed opinion, based solely on reading
m.d.s.p. and thinking they understand stuff. It's a very wild-west.

It's important to note that, at the end of this process, in which the
auditor has been shown all this evidence, they make a subjective
determination about whether or not they think it was "reasonable". Auditors
are not required to reach the same conclusion, and indeed, professional
standards discourage auditors from "checking eachother's work". Unskilled
auditors, of which there are many, are indistinguishable from skilled
auditors. In all cases, their fiduciary relationship is with the CA, and
thus they are bound by confidentiality and professionally prohibited from
disclosing knowledge of adverse events, such as the CA "misleading" the
public, provided that the CA made sure to exclude such things from their
scope of the engagement.

I mention all of this, because it seems you have a mistaken belief that PKI
rests on objective criteria. It has not, nor has it ever. It has simply
been "someone" (in this case, chosen by the CA) to offer their opinion on
whether it's likely that the CA will end up doing what they said they would
do. It does not measure that what the CA says they'll do is what people
trusting the CA may expect. It does not permit the auditor to disclose
deception. And, at the end of the day, it's merely the auditors
"professional judgement", and with a whole host of disclaimers so that
they're not personally responsible, should someone rely on that judgement.

Perhaps, if you've read this far, you've come to realize that the thing
you're taking unnecessary and unfounded umbrage over, which is the
'subjectivity' based on 'reasonable 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

Dear Ryan,

Thank you very much for pointing out that in the examples listed by Fabio,
none of them actually control the private key. I did not know this and
assumed that the opposite would be the case for at least some of the
entities listed.

I am indeed a new participant and I have an infinitesimal amount of
experience in this specific topic compared to you, who does this for a
living indeed as a guardian for one of the most important entities on the
Internet. But I did make effort a few months ago, at the outset of this
discussion, to understand how the CA process works, and I do not believe
that citing the clause "Mozilla MAY, at its sole discretion, decide to
disable (partially or fully) or remove a certificate at any time and for
any reason" is a particularly insightful way in which to veer the
discussion back towards policy, except if the intent is to outline that the
policy does technically allow Mozilla to do whatever it wants, policy be
damned.

Indeed I would much rather focus on the rest of the elements in the Mozilla
Root Store Policy (
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
which are less vapidly authoritarian than the single clause you quote, and
which focus more on a set of audits, confirmations and procedures that give
everyone a fair chance at proving the honesty of their role as a
certificate authority. For example, I find policy points 2.2 (Validation
Practices), 3.1.1 (Audit Criteria) and 3.1.4 (Public Audit Information) to
be much more of a fertile ground for future discussion.

Finally, I don't think anyone here has expressed interest in those "pay to
play" schemes, as you call them. Rather, my argument is that the continued
dismissal of auditing practices and transparent procedures, especially by
substituting them with newspaper reports that offer no evidence, is not a
good path to take for Mozilla. This is especially true when this dismissal
is largely cushioned with such elements as "you didn't see that Mozilla has
as clause that lets it do anything for any reason", "after 30 years of
experience, we decided that trust is subjective" and that it's
"unfortunate" to ask for due process as the main gatekeeper for what is
perhaps the most critical deliberative process for the safety of the world
wide web.

With my sincere appreciation for your continued engagement,

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


On Wed, Jul 10, 2019 at 7:33 PM Ryan Sleevi  wrote:

>
>
> On Wed, Jul 10, 2019 at 1:07 PM Nadim Kobeissi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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?
>>
>
> Hi Nadim,
>
> I realize you're a new participant in this Forum, and thus are not very
> familiar with PKI or how it works. As I responded, Fabio's remarks
> misunderstand both Mozilla Policy and how CAs work and operate, as well as
> audits and controls. I realize this may be confusing for new participants,
> and I hope my drawing attention to your confusion can help you learn more.
>
> Similarly, as a new participant, you probably aren't familiar with how
> root programs work, based on your replies. For example, Mozilla's policy
> has always contained a very explicit provision:
> Mozilla MAY, at its sole discretion, decide to disable (partially or
> fully) or remove a certificate at any time and for any reason.
>
> I realize you may be unhappy with that language, based on your replies,
> but it's important to recognize that Mozilla is tasked with, among other
> things, the safety and security of its users. However, as noted, it may
> remove them for any reason, even those without security requirements.
> Mozilla understandably strives to balance this in its mission, but I think
> it's important to recognize that it's a very clear policy which every CA
> trusted or applying to be trusted must acknowledge and agree with.
>
> It's also unfortunate that you seem to be looking for objective controls
> here. In the 30 years of PKI discussions, one of the key themes in both the
> legal and technical analysis is that trust is, functionally, a subjective
> thing. Audits are one mechanism to try to improve certainty, but they are
> not a substitute. The choice of audit schemes currently used - which rely
> on third-party audits with criteria developed by other organizations - is
> 

Re: DarkMatter Concerns

[Michael Casadevall via dev-security-policy]

I appreciate the ground work Fabio put into this thus far, and want to
see further discussion on it.

I think the safest way to quantity and frame the discussion is asking if
a CA (or subCA) has a vested interest in surveillance, other business
interest, or government ties which would put a CA to be more likely to
abuse the trust, or has a history of business practices related to
surveillance or practices against the public interest in regards to WebPKI.

I recognize the points Scott brought up, but trust is always a
subjective thing. As previously pointed out, Mozilla has always retained
the ability to choose what to include or disallow based on community
input, and this entire thread shows there is a lot of community input here.

The problem with auditing in general is its only going to catch
information that is logged and archived in a corporation. It's an
assurance step but in and of itself is not enough to establish trust; it
not uncommon for misissues and other issues to be noted by the community
from information in the wild
Michael

On 7/10/19 3:59 AM, fabio.pietrosanti--- via dev-security-policy wrote:
> I understand the Nadim points, there's a lot of subjective biased "popular 
> judgement".
> 
> While from a security standpoint perspective "better safe than sorry" is a 
> good statement, from a rights and fairness perspective that's a very bad.
> 
> So further conversation is needed.
> 
> Following DarkMatter removal i would love to bring to the attention of 
> Mozilla the removal of a list of Companies that does as a main business other 
> stuff, but also does offensive security and surveillance with public 
> "credible evidences" .
> 
> I've analysed Intermediate CA list where DarkMatter is here 
> https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts .
> 
> In this list is possible to find the following company operating against 
> "people's safety" and there's "credible evidences" they are doing so:
> 
> 
> * Saudi Telecom Company
> 
> This company is publicly known to ask to surveil and intercept people as per 
> "credible evidences" on:
> https://moxie.org/blog/saudi-surveillance/
> https://citizenlab.ca/2014/06/backdoor-hacking-teams-tradecraft-android-implant/
> 
> 
> * German Rohde & Schwarz
> 
> This company do produce, install and support surveillance systems for 
> intelligence agencies in Regimes such as Turkmenistan:
> https://www.rferl.org/a/german-tech-firm-s-turkmen-ties-trigger-surveillance-concerns/29759911.html
> 
> They sell solutions to intelligence agencies such as IMSI Catchers and 
> massive internet surveillance tools:
> https://www.rohde-schwarz.com/en/solutions/aerospace-defense-security/overview/aerospace-defense-overview_229832.html
> 
> 
> * US "Computer Sciences Corporation"
> 
> The CSC is a US Intelligence and Defense Contractors that does CNE (Computer 
> Network Exploitation) like the WikiLeaks ICWatch show out
> 
> Read the profile of a former employee of CSC, doing CNE like Snowden was 
> doing:
> https://icwatch.wikileaks.org/docs/rLynnette-Jackson932c7871cb1e83f3%3Fsp=0ComputerSciencesCorporationCyberSecurityAnalystSystemsEngineerRemoteSystemAdministrator2008-09-01icwatch_indeed
> 
> Additionally from their wikipedia they acknowledge working for US Intel:
> https://en.wikipedia.org/wiki/Computer_Sciences_Corporation
> 
> CSC provided services to the United States Department of Defense,[23] law 
> enforcement and intelligence agencies (FBI,[24] CIA, Homeland Security[23]), 
> aeronautics and aerospace agencies (NASA). In 2012, U.S. federal contracts 
> accounted for 36% of CSC total revenue.[25]
> 
> 
> * Australia's Attorney-General's Department
> 
> The Australia's Attorney-General's Department is a government agencies that 
> wants to permit the Australian Security Intelligence Organisation (ASIO) to 
> hack IT systems belonging to non-involved, non-targeted parties.
> 
> It operate against people safety and there's credible evidence of their 
> behaviour in supporting ASIO to hack people, so they are very likely to abuse 
> their intermediate CA:
> http://www.h-online.com/security/news/item/Australian-secret-services-to-get-licence-to-hack-1784139.html
> 
> 
> * US "National Geospatial-Intelligence Agency" https://www.nga.mil
> 
> The NGA is a US Military Intelligence Agency, equivalent to NSA, but 
> operating on space GEOINT and SIGINT in serving intelligence and defense US 
> agencies.
> 
> NGA is the Space partner of NSA:
> https://www.nsa.gov/news-features/press-room/Article/1635467/joint-document-highlights-nga-and-nsa-collaboration/
> 
> I think that no-one would object to shutdown an NSA operated Intermediate CA, 
> i am wondering if Mozilla would consider this removal.
> 
> 
> Said that, given the approach that has been following with DarkMatter about 
> "credible evidence" and "people safety" principles, i would strongly argue 
> that Mozilla should take action against the subject previously documented.
> 
> I will open a 

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 10, 2019 at 1:07 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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?
>

Hi Nadim,

I realize you're a new participant in this Forum, and thus are not very
familiar with PKI or how it works. As I responded, Fabio's remarks
misunderstand both Mozilla Policy and how CAs work and operate, as well as
audits and controls. I realize this may be confusing for new participants,
and I hope my drawing attention to your confusion can help you learn more.

Similarly, as a new participant, you probably aren't familiar with how root
programs work, based on your replies. For example, Mozilla's policy has
always contained a very explicit provision:
Mozilla MAY, at its sole discretion, decide to disable (partially or fully)
or remove a certificate at any time and for any reason.

I realize you may be unhappy with that language, based on your replies, but
it's important to recognize that Mozilla is tasked with, among other
things, the safety and security of its users. However, as noted, it may
remove them for any reason, even those without security requirements.
Mozilla understandably strives to balance this in its mission, but I think
it's important to recognize that it's a very clear policy which every CA
trusted or applying to be trusted must acknowledge and agree with.

It's also unfortunate that you seem to be looking for objective controls
here. In the 30 years of PKI discussions, one of the key themes in both the
legal and technical analysis is that trust is, functionally, a subjective
thing. Audits are one mechanism to try to improve certainty, but they are
not a substitute. The choice of audit schemes currently used - which rely
on third-party audits with criteria developed by other organizations - is
similarly lacking in suitability, if that's the position to take.
Alternative schemes, which have been or are practiced by other root
programs, includes charging CAs that wish to apply, and using that to fund
efforts for the development and analysis of organizations. However, that
sort of "pay for play" scheme, as some perceive it, runs the risk of
further encouraging those with deep pockets to pursue bad behaviour.

If you're looking to understand a bit more about the basics of PKI, which
seems a good opportunity given the challenges you're struggling with on the
discussion, perhaps you'd like to examine how the Mozilla Policy developed
[1]. You can note the issues [2] at the time with audits. Indeed, some of
the earlier messages on this thread include good primers that potential
participants should be familiar with, in order to ensure their
contributions are most useful and informed.

[1] http://hecker.org/mozilla/ca-certificate-metapolicy
[2] http://hecker.org/mozilla/cert-policy-submitted
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 10, 2019 at 12:29 PM fabio.pietrosanti--- via
dev-security-policy  wrote:

> Said that, given the approach that has been following with DarkMatter
> about "credible evidence" and "people safety" principles, i would strongly
> argue that Mozilla should take action against the subject previously
> documented.
>
> I will open a thread on those newsgroup for each of those company to
> understand what's the due process and how it will compare to this.
>

It sounds like you've not done the research to actually analyze which of
the listed organizations are similar in substance. For example, which of
these organizations is in control of the private key and/or the CP/CPS and
issuance control.

This is a very basic and essential understanding to have, if proposing such
a discussion. For each of the organizations listed, my queries show that
they are not controlled or operated by such organizations, merely branded
as such.

It is noteworthy, because this was similarly the case for DarkMatter;
QuoVadis controlled the private key, issuance, and core activities.
Transfer of control happened late 2017, which became publicly known
February 2018, although not formally disclosed as such for a non-trivial
amount of time after. The policies are in the process of being updated,
which will incidentally ensure such actions do not happen again.

However, without understanding the relevant audits or CP/CPS, this is not a
productive line of argument. If I've overlooked something with respect to
the specific audits mentioned, and you weren't just pulling names out of
certificates, please highlight the relevant audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

Hi Scott,
Below is my personal view on it, I acknowledge that it is highly subjective.

For one, people and companies in the UAE could get certs from non-UAE CAs.
I live in Sweden, yet I have certs from Norwegian, British, and American
CAs.

Another issue I have is that I think there is a difference between a
government such as the US, UK, etc and the UAE due to the UAE not being an
electoral democracy and doesn't really have much transparency from what I
know.

As I have said before, if Mozilla and the community considers it a risk, it
may not be worth it.
It would be different in a more isolated industry, but in the "CA
Industry", one CA's mistake will be felt by the entire world.

Now, my personal view is that we shouldn't really have CAs that are
connected with non-democratic governments (such as China Financial
Certification Authority) at all.

- Cynthia

On Wed, Jul 10, 2019 at 6:43 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

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  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

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

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

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

Dear Nex,

I doubt that anyone seriously believes that "reporters are lying out of their 
teeth." It is far more likely that the reporters are working within the realm 
of reason and covering things as they see them. So far all the actors in this 
appear to be behaving in ways that make sense given their perspectives on the 
issue, which are wildly different.

I am pointing to the fact that the journalistic reporting on this matter has so 
far operated under a fundamentally different dimension of rigor than the one I 
would assume is necessary for making this sort of decision with regards to the 
Mozilla CA process. For example, Reuters can allow itself to publish an article 
that kicks off with the claim that Mozilla blocked the United Arab Emirates 
government (not DarkMatter!), from becoming an "Internet security guardian" or 
"Internet security gatekeeper", and that Mozilla claimed to have "credible 
evidence" for doing this. In the Reuters world, this isn't egregious because it 
still covers the gist of what's going on and communicates it abstractly to a 
mainstream global audience. It's not "lying" as much as it is lacking in rigor.

Similarly, the Intercept bills itself as an "adversarial journalism" outfit and 
has had a serious anti-surveillance and activist bent from day one. That's not 
at all a bad thing, and their work is important. But it's still the case that 
it doesn't meet the standard of objectivity and evidence that I would 
personally prefer to see mandated in such decisions.  

My contention is that, similarly as I wouldn't base my decision on which 
dentist to go to for a root canal on an article in People magazine, Mozilla 
shouldn't base these decisions on reporting from the New York Times or the 
Intercept. People magazine's profile of a brilliant dentist is likely a fair 
one all things considered, but it's still not how informed decisions should be 
made. Another example: I wouldn't expect the mayor of a village to decide to 
ban video games from being sold based on him reading in the town newspaper that 
they cause violence and addiction. Maybe they do, maybe they don't -- it's just 
that such decisions shouldn't be made based on that kind of source material.

I agree that not all of the sources on the DarkMatter story were anonymous and 
I was incorrect in implying that this was the case. But I still believe that it 
is in everyone's interest to, moving forward, improve our objective procedures 
such that they are applicable, relevant and sufficient, and to place more value 
on evidence. I personally hope that evidence shows up that proves every single 
one of the claims against DarkMatter true, just so that we can actually finally 
know for sure and leave this behind us once and for all!

I want to reiterate that I am not trying to defend DarkMatter here. My interest 
lies in trying to warn about a potential for decay in objective and correct 
procedure, especially when it comes to something this important. My contentions 
are likely to be unpopular with all sides: they don't excuse DarkMatter, they 
criticize a legitimately brilliant vanguard of Internet freedom (Mozilla), etc. 
etc. -- I'm sorry for having to make you all put up with this; I just genuinely 
think it's important to not dismiss these concerns and to keep them in mind for 
next time.

On Wednesday, July 10, 2019 at 9:45:07 AM UTC+2, Nex wrote:
> I think that dismissing as baseless investigations from 9 different
> reporters, on 3 different newspapers (add one more, FP, if consider
> this[1]) is misleading. Additionally, it is just false to say all the
> articles only relied on anonymous sources (of which they have many, by
> the way), but there are clearly sources on record as well, such as
> Simone Margaritelli and Jonathan Cole for The Intercept, and Lori Stroud
> for Reuters.
> 
> While obviously there is no scientific metric for this, I do think the
> number of sources (anonymous and not) and the variety of reporters and
> of newspapers (with their respective editors and verification processes)
> do qualify the reporting as "credible" and "extensively sourced".
> 
> Additionally, details provided by sources on record directly matched
> attacks documented by technical researchers. For example, Lori Stroud
> talking details over the targeting of Donaghy, which was also proven in
> Citizen Lab's "Stealth Falcon" report. Lastly, Reuters reporters make
> repeated mentions of documents they had been able to review supporting
> the claims of their sources. Unless you have good reasons to believe
> reporters are just lying out of their teeth, I don't see how all of this
> can't be considered credible.
> 
> [1]
> https://foreignpolicy.com/2017/12/21/deep-pockets-deep-cover-the-uae-is-paying-ex-cia-officers-to-build-a-spy-empire-in-the-gulf/
> 
> On 7/9/19 6:09 PM, Nadim Kobeissi via dev-security-policy wrote:
> > Dear Wayne,
> > 
> > I fully respect Mozilla's mission and I fully believe that everyone here is
> > 

Re: DarkMatter Concerns

[Fabio Pietrosanti via dev-security-policy]

I understand the Nadim points, there's a lot of subjective biased "popular 
judgement".

While from a security standpoint perspective "better safe than sorry" is a good 
statement, from a rights and fairness perspective that's a very bad.

So further conversation is needed.

Following DarkMatter removal i would love to bring to the attention of Mozilla 
the removal of a list of Companies that does as a main business other stuff, 
but for which there's "public credible evidences" that does also some kind of 
offensive security that goes "against people's safety" (as defined by Mozilla 
principles).

I've analysed Intermediate CA list where DarkMatter is here 
https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts .

In this list is possible to find the following company operating against 
"people's safety" and there's "credible evidences" they are doing so:


* Saudi Telecom Company

This company is publicly known to ask to surveil and intercept people as per 
"credible evidences" on:
https://moxie.org/blog/saudi-surveillance/
https://citizenlab.ca/2014/06/backdoor-hacking-teams-tradecraft-android-implant/


* German Rohde & Schwarz

This company do produce, install and support surveillance systems for 
intelligence agencies in Regimes such as Turkmenistan:
https://www.rferl.org/a/german-tech-firm-s-turkmen-ties-trigger-surveillance-concerns/29759911.html

They sell solutions to intelligence agencies such as IMSI Catchers and massive 
internet surveillance tools:
https://www.rohde-schwarz.com/en/solutions/aerospace-defense-security/overview/aerospace-defense-overview_229832.html


* US "Computer Sciences Corporation"

The CSC is a US Intelligence and Defense Contractors that does CNE (Computer 
Network Exploitation) like the WikiLeaks ICWatch show out
Read the profile of a former employee of CSC, doing CNE like Snowden was doing:

https://icwatch.wikileaks.org/docs/rLynnette-Jackson932c7871cb1e83f3%3Fsp=0ComputerSciencesCorporationCyberSecurityAnalystSystemsEngineerRemoteSystemAdministrator2008-09-01icwatch_indeed

Additionally from their wikipedia they acknowledge working for US Intel:

https://en.wikipedia.org/wiki/Computer_Sciences_Corporation

CSC provided services to the United States Department of Defense,[23] law 
enforcement and intelligence agencies (FBI,[24] CIA, Homeland Security[23]), 
aeronautics and aerospace agencies (NASA). In 2012, U.S. federal contracts 
accounted for 36% of CSC total revenue.[25]


* Australia's Attorney-General's Department

The Australia's Attorney-General's Department is a government agencies that 
wants to permit the Australian Security Intelligence Organisation (ASIO) to 
hack IT systems belonging to non-involved, non-targeted parties.

It operate against people safety and there's credible evidence of their 
behaviour in supporting ASIO to hack people, so they are very likely to abuse 
their intermediate CA:
http://www.h-online.com/security/news/item/Australian-secret-services-to-get-licence-to-hack-1784139.html


* US "National Geospatial-Intelligence Agency" https://www.nga.mil

The NGA is a US Military Intelligence Agency, equivalent to NSA, but operating 
on space GEOINT and SIGINT in serving intelligence and defense US agencies.

NGA is the Space partner of NSA:

https://www.nsa.gov/news-features/press-room/Article/1635467/joint-document-highlights-nga-and-nsa-collaboration/

I think that no-one would object to shutdown an NSA operated Intermediate CA, i 
am wondering if Mozilla would consider this removal.


Said that, given the approach that has been followed with DarkMatter about 
"credible evidence" and "people safety" principles, i would strongly argue that 
Mozilla should take action against the subject previously documented.

I will open a thread on those newsgroup for each of those company to understand 
what's the due process and how it will compare to this.

Fabio Pietrosanti (naif)

Il giorno venerdì 22 marzo 2019 17:49:17 UTC+1, Nadim Kobeissi ha scritto:
> What a strange situation.
> 
> On the one hand, denying DarkMatter's CA bid because of these press
> articles would set the precedent of refusing to accept the engagement and
> apparent good faith of a member of the industry, based only on hearsay and
> with no evidence.
> 
> On the other hand, deciding to move forward with a good-faith, transparent
> and evidence-based approach actually risks creating a long-term undermining
> of public confidence in the CA inclusion process.
> 
> It really seems to me that both decisions would cause damage to the CA
> inclusion process. The former would make it seem discriminatory (and to
> some even somewhat xenophobic, although I don't necessarily agree with
> that) while the latter would cast a serious cloud of uncertainty above the
> safety of the CA root store in general that I have no idea how anyone could
> or will eventually dispel.
> 
> As a third party observer I genuinely don't know what could be considered a
> good move by Mozilla 

Re: DarkMatter Concerns

[fabio.pietrosanti--- via dev-security-policy]

I understand the Nadim points, there's a lot of subjective biased "popular 
judgement".

While from a security standpoint perspective "better safe than sorry" is a good 
statement, from a rights and fairness perspective that's a very bad.

So further conversation is needed.

Following DarkMatter removal i would love to bring to the attention of Mozilla 
the removal of a list of Companies that does as a main business other stuff, 
but also does offensive security and surveillance with public "credible 
evidences" .

I've analysed Intermediate CA list where DarkMatter is here 
https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts .

In this list is possible to find the following company operating against 
"people's safety" and there's "credible evidences" they are doing so:


* Saudi Telecom Company

This company is publicly known to ask to surveil and intercept people as per 
"credible evidences" on:
https://moxie.org/blog/saudi-surveillance/
https://citizenlab.ca/2014/06/backdoor-hacking-teams-tradecraft-android-implant/


* German Rohde & Schwarz

This company do produce, install and support surveillance systems for 
intelligence agencies in Regimes such as Turkmenistan:
https://www.rferl.org/a/german-tech-firm-s-turkmen-ties-trigger-surveillance-concerns/29759911.html

They sell solutions to intelligence agencies such as IMSI Catchers and massive 
internet surveillance tools:
https://www.rohde-schwarz.com/en/solutions/aerospace-defense-security/overview/aerospace-defense-overview_229832.html


* US "Computer Sciences Corporation"

The CSC is a US Intelligence and Defense Contractors that does CNE (Computer 
Network Exploitation) like the WikiLeaks ICWatch show out

Read the profile of a former employee of CSC, doing CNE like Snowden was doing:
https://icwatch.wikileaks.org/docs/rLynnette-Jackson932c7871cb1e83f3%3Fsp=0ComputerSciencesCorporationCyberSecurityAnalystSystemsEngineerRemoteSystemAdministrator2008-09-01icwatch_indeed

Additionally from their wikipedia they acknowledge working for US Intel:
https://en.wikipedia.org/wiki/Computer_Sciences_Corporation

CSC provided services to the United States Department of Defense,[23] law 
enforcement and intelligence agencies (FBI,[24] CIA, Homeland Security[23]), 
aeronautics and aerospace agencies (NASA). In 2012, U.S. federal contracts 
accounted for 36% of CSC total revenue.[25]


* Australia's Attorney-General's Department

The Australia's Attorney-General's Department is a government agencies that 
wants to permit the Australian Security Intelligence Organisation (ASIO) to 
hack IT systems belonging to non-involved, non-targeted parties.

It operate against people safety and there's credible evidence of their 
behaviour in supporting ASIO to hack people, so they are very likely to abuse 
their intermediate CA:
http://www.h-online.com/security/news/item/Australian-secret-services-to-get-licence-to-hack-1784139.html


* US "National Geospatial-Intelligence Agency" https://www.nga.mil

The NGA is a US Military Intelligence Agency, equivalent to NSA, but operating 
on space GEOINT and SIGINT in serving intelligence and defense US agencies.

NGA is the Space partner of NSA:
https://www.nsa.gov/news-features/press-room/Article/1635467/joint-document-highlights-nga-and-nsa-collaboration/

I think that no-one would object to shutdown an NSA operated Intermediate CA, i 
am wondering if Mozilla would consider this removal.


Said that, given the approach that has been following with DarkMatter about 
"credible evidence" and "people safety" principles, i would strongly argue that 
Mozilla should take action against the subject previously documented.

I will open a thread on those newsgroup for each of those company to understand 
what's the due process and how it will compare to this.

Fabio Pietrosanti (naif)

Il giorno martedì 9 luglio 2019 18:19:36 UTC+2, Nadim Kobeissi ha scritto:
> Dear Wayne,
> 
> I fully respect Mozilla's mission and I fully believe that everyone here is
> acting in good faith.
> 
> That said, I must, in my capacity as a private individual, decry what I
> perceive as a dangerous shortsightedness and lack of intellectual rigor
> underlying your decision. I do this as someone with a keen interest in
> Internet freedom issues and not as someone who is in any way partisan in
> this debate: I don't care for DarkMatter as a company in any way whatsoever
> and have no relationship with anyone there.
> 
> I sense enough urgency in my concerns to pause my work schedule today and
> respond to this email. I will do my best to illustrate why I sense danger
> in your decision. Essentially there are three specific points I take issue
> with:
> 
> -
> 1: Waving aside demands for objective criteria.
> -
> You say that "if we rigidly applied our existing criteria, we would deny
> most inclusion requests." Far from being an excuse to put more weight (or
> in this case, perhaps almost all weight) on 

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

Even if we stipulated that all those accounts were fully accurate, all
those reports are about a separate business that happens to be owned by the
same owner.

Furthermore, in as far as none of those directly speak to their ability to
own or manage a publicly trusted CA, I would regard those issues as
immaterial.  Perhaps they also indiscriminately kill puppies?  That would
be awful.  Still, I do not see how that would be disqualifying.

On Wed, Jul 10, 2019 at 2:45 AM Nex via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think that dismissing as baseless investigations from 9 different
> reporters, on 3 different newspapers (add one more, FP, if consider
> this[1]) is misleading. Additionally, it is just false to say all the
> articles only relied on anonymous sources (of which they have many, by
> the way), but there are clearly sources on record as well, such as
> Simone Margaritelli and Jonathan Cole for The Intercept, and Lori Stroud
> for Reuters.
>
> While obviously there is no scientific metric for this, I do think the
> number of sources (anonymous and not) and the variety of reporters and
> of newspapers (with their respective editors and verification processes)
> do qualify the reporting as "credible" and "extensively sourced".
>
> Additionally, details provided by sources on record directly matched
> attacks documented by technical researchers. For example, Lori Stroud
> talking details over the targeting of Donaghy, which was also proven in
> Citizen Lab's "Stealth Falcon" report. Lastly, Reuters reporters make
> repeated mentions of documents they had been able to review supporting
> the claims of their sources. Unless you have good reasons to believe
> reporters are just lying out of their teeth, I don't see how all of this
> can't be considered credible.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nex via dev-security-policy]

I think that dismissing as baseless investigations from 9 different
reporters, on 3 different newspapers (add one more, FP, if consider
this[1]) is misleading. Additionally, it is just false to say all the
articles only relied on anonymous sources (of which they have many, by
the way), but there are clearly sources on record as well, such as
Simone Margaritelli and Jonathan Cole for The Intercept, and Lori Stroud
for Reuters.

While obviously there is no scientific metric for this, I do think the
number of sources (anonymous and not) and the variety of reporters and
of newspapers (with their respective editors and verification processes)
do qualify the reporting as "credible" and "extensively sourced".

Additionally, details provided by sources on record directly matched
attacks documented by technical researchers. For example, Lori Stroud
talking details over the targeting of Donaghy, which was also proven in
Citizen Lab's "Stealth Falcon" report. Lastly, Reuters reporters make
repeated mentions of documents they had been able to review supporting
the claims of their sources. Unless you have good reasons to believe
reporters are just lying out of their teeth, I don't see how all of this
can't be considered credible.

[1]
https://foreignpolicy.com/2017/12/21/deep-pockets-deep-cover-the-uae-is-paying-ex-cia-officers-to-build-a-spy-empire-in-the-gulf/

On 7/9/19 6:09 PM, Nadim Kobeissi via dev-security-policy wrote:
> Dear Wayne,
> 
> I fully respect Mozilla's mission and I fully believe that everyone here is
> acting in good faith.
> 
> That said, I must, in my capacity as a private individual, decry what I
> perceive as a dangerous shortsightedness and lack of intellectual rigor
> underlying your decision. I do this as someone with a keen interest in
> Internet freedom issues and not as someone who is in any way partisan in
> this debate: I don't care for DarkMatter as a company in any way whatsoever
> and have no relationship with anyone there.
> 
> I sense enough urgency in my concerns to pause my work schedule today and
> respond to this email. I will do my best to illustrate why I sense danger
> in your decision. Essentially there are three specific points I take issue
> with:
> 
> -
> 1: Waving aside demands for objective criteria.
> -
> You say that "if we rigidly applied our existing criteria, we would deny
> most inclusion requests." Far from being an excuse to put more weight (or
> in this case, perhaps almost all weight) on subjective decision making,
> this should be a rallying cry for Mozilla to investigate why it is that an
> objective and democratic decision-making process is failing, and what can
> be done to make it work better. Waving aside objective procedures as
> "checklists" dismisses a core procedural element of how such critical
> decisions should be made in the future and is explicitly undemocratic and
> therefore dangerous.
> 
> -
> 2: Calling allegations "credible" and "extensively sourced" with almost no
> basis whatsoever.
> -
> You cite four articles: two are from the Intercept, one is from Reuters and
> one is from the New York Times. You claim that the fact that they are years
> apart bolsters their credibility; why is this the case? In fact, these
> articles all parrot almost exactly the same story, with some minor
> additions, updates and modifications. They all almost read like the same
> article, despite their temporal distribution. Furthermore, the notion that
> the articles are "extensively sourced" is simply incorrect: all of the
> articles are based on anonymous sources and none of them provide a shred of
> evidence, which is why we are in this debate to begin with (or so I've been
> thinking).
> 
> It should also be noted that both The Intercept and the New York Times have
> published misleading and incorrect information many times in their history.
> The Intercept in particular has a very spotty credibility record.
> 
> It is also is not difficult to theorize how a politically trendy topic
> (cyberattacks) against the world's most easy-to-villainize company (an
> Arabic offensive cybersecurity company operating within a true monarchic
> state) would be appealing to American journalists. This sort of thing isn't
> new, and American "digital rights" groups have previously linked malicious
> cyberattacks to Middle Eastern countries without providing something that
> is even close to the same standard of evidence that they almost always
> provide when naming American or European actors.
> 
> Is is indeed unfortunate that this issue was dealt with in a single
> paragraph: I would have expected it to be the brunt of the email given its
> importance, and it is impossible to qualify that reporting as "credible"
> and "extensively sourced" so summarily.
> 
> -
> 3: Culminating in an argument that simply boils down to "the people's
> safety", a trope that is often overused and that leads to 

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Sun, Jun 23, 2019 at 11:52 AM Cynthia Revström via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> My view is a bit different, we have lots of CAs already, I think it is more
> important to be extra secure rather than to take unnecessary risks.
>

A position like this is not unreasonable, but it would open up other
questions.  Taken to its logical conclusion, if we have lots of CAs and
believe security risks arise from new additions, why would we ever add a
new one again?  Or at least, what becomes the criteria for getting past
that risk and to adding a new one?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[mono.riot--- via dev-security-policy]

On Tuesday, July 9, 2019 at 11:46:05 PM UTC+2, Matthew Hardeman wrote:
> ownership: Francisco Partners.  It is difficult for me to see the
> difference, objectively speaking.

agree, but I think Francisco partners was ... rubbing the wrong way, too; and I 
think that issue was let go way too easily. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Tue, Jul 9, 2019 at 4:34 PM mono.riot--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think it's less about a single person than about an alleged firewalling
> of entities that end up being not firewalled at all, but all owned by the
> same person in the end.
>

That kind of corporate hierarchy exists for numerous legitimate reasons --
mostly tax & liability segregation.  Nothing about that, in itself, is
illegitimate.  And the separation offered do, properly implemented, mean
that the team at the other divisions has no sway over the CA, save for by
convincing the ownership to dictate policy.

There is even precedent for a major CA (what was Comodo CA) and a TLS
interception device manufacturer (BlueCoat) to share significant beneficial
ownership: Francisco Partners.  It is difficult for me to see the
difference, objectively speaking.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[mono.riot--- via dev-security-policy]

On Tuesday, July 9, 2019 at 11:23:11 PM UTC+2, Matthew Hardeman wrote:

> Truly horrid organizations and/or individuals passively own all kinds of 
> assets.  A strong management team that can be trusted to keep commitments to 
> sound the alarm if the organization goes off track is one way to address that.

I think it's less about a single person than about an alleged firewalling of 
entities that end up being not firewalled at all, but all owned by the same 
person in the end. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Tuesday, July 9, 2019 at 10:31:27 AM UTC-5, Wayne Thayer wrote:

> 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.

I seek to better understand this aspect.  Are we to infer that "Mr. Al Bannai" 
is banned from the program?  Is there a list of named individuals who are 
banned?  Will there be?

Truly horrid organizations and/or individuals passively own all kinds of 
assets.  A strong management team that can be trusted to keep commitments to 
sound the alarm if the organization goes off track is one way to address that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

I wanted to supplement my previous email with an observation on how this
decision is already being covered by the same news outlet that are being
cited in the case against DarkMatter.

Reuters wrote this article:
https://www.reuters.com/article/us-usa-cyber-mozilla/mozilla-blocks-uae-bid-to-become-an-internet-security-guardian-after-hacking-reports-idUSKCN1U42CA



The article makes the following claims:

- Mozilla blocked the United Arab Emirates government (not DarkMatter!),
from becoming an "Internet security guardian" or "Internet security
gatekeeper", as a result of the Reuters report on DarkMatter. I have no
idea what that means.
- Mozilla blocked the United Arab Emirates from becoming a "globally
recognized Internet security watchdog". Again, I am not sure what that
means or how that represents DarkMatter's attempts to justify its CA status.
- Mozilla cited the existence of "credible evidence" to Reuters, despite us
establishing in this thread that no evidence whatsoever has been presented
so far and that we're still waiting for it.

This is a sad and frustrating irony. These sources are being cited as
sufficient for a decision to be made with regards to DarkMatter, and then
they proceed to cover *the decision itself* in a way that is sensationalist
and that starts blurring lines from the very first paragraph.

That said, I recognize that this was a difficult decision.

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


On Tue, Jul 9, 2019 at 6:19 PM Nadim Kobeissi 
wrote:

> Dear Wayne,
>
> I fully respect Mozilla's mission and I fully believe that everyone here is
> acting in good faith.
>
> That said, I must, in my capacity as a private individual, decry what I
> perceive as a dangerous shortsightedness and lack of intellectual rigor
> underlying your decision. I do this as someone with a keen interest in
> Internet freedom issues and not as someone who is in any way partisan in
> this debate: I don't care for DarkMatter as a company in any way whatsoever
> and have no relationship with anyone there.
>
> I sense enough urgency in my concerns to pause my work schedule today and
> respond to this email. I will do my best to illustrate why I sense danger
> in your decision. Essentially there are three specific points I take issue
> with:
>
> -
> 1: Waving aside demands for objective criteria.
> -
> You say that "if we rigidly applied our existing criteria, we would deny
> most inclusion requests." Far from being an excuse to put more weight (or
> in this case, perhaps almost all weight) on subjective decision making,
> this should be a rallying cry for Mozilla to investigate why it is that an
> objective and democratic decision-making process is failing, and what can
> be done to make it work better. Waving aside objective procedures as
> "checklists" dismisses a core procedural element of how such critical
> decisions should be made in the future and is explicitly undemocratic and
> therefore dangerous.
>
> -
> 2: Calling allegations "credible" and "extensively sourced" with almost no
> basis whatsoever.
> -
> You cite four articles: two are from the Intercept, one is from Reuters and
> one is from the New York Times. You claim that the fact that they are years
> apart bolsters their credibility; why is this the case? In fact, these
> articles all parrot almost exactly the same story, with some minor
> additions, updates and modifications. They all almost read like the same
> article, despite their temporal distribution. Furthermore, the notion that
> the articles are "extensively sourced" is simply incorrect: all of the
> articles are based on anonymous sources and none of them provide a shred of
> evidence, which is why we are in this debate to begin with (or so I've been
> thinking).
>
> It should also be noted that both The Intercept and the New York Times have
> published misleading and incorrect information many times in their history.
> The Intercept in particular has a very spotty credibility record.
>
> It is also is not difficult to theorize how a politically trendy topic
> (cyberattacks) against the world's most easy-to-villainize company (an
> Arabic offensive cybersecurity company operating within a true monarchic
> state) would be appealing to American journalists. This sort of thing isn't
> new, and American "digital rights" groups have previously linked malicious
> cyberattacks to Middle Eastern countries without providing something that
> is even close to the same standard of evidence that they almost always
> provide when naming American or European actors.
>
> Is is indeed unfortunate that this issue was dealt with in a single
> paragraph: I would have expected it to be the brunt of the email given its
> 

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

The bug requesting that the existing subordinate CAs be added to OneCRL is
https://bugzilla.mozilla.org/show_bug.cgi?id=1564544

On Tue, Jul 9, 2019 at 8:31 AM Wayne Thayer  wrote:

> 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 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

Dear Wayne,

I fully respect Mozilla's mission and I fully believe that everyone here is
acting in good faith.

That said, I must, in my capacity as a private individual, decry what I
perceive as a dangerous shortsightedness and lack of intellectual rigor
underlying your decision. I do this as someone with a keen interest in
Internet freedom issues and not as someone who is in any way partisan in
this debate: I don't care for DarkMatter as a company in any way whatsoever
and have no relationship with anyone there.

I sense enough urgency in my concerns to pause my work schedule today and
respond to this email. I will do my best to illustrate why I sense danger
in your decision. Essentially there are three specific points I take issue
with:

-
1: Waving aside demands for objective criteria.
-
You say that "if we rigidly applied our existing criteria, we would deny
most inclusion requests." Far from being an excuse to put more weight (or
in this case, perhaps almost all weight) on subjective decision making,
this should be a rallying cry for Mozilla to investigate why it is that an
objective and democratic decision-making process is failing, and what can
be done to make it work better. Waving aside objective procedures as
"checklists" dismisses a core procedural element of how such critical
decisions should be made in the future and is explicitly undemocratic and
therefore dangerous.

-
2: Calling allegations "credible" and "extensively sourced" with almost no
basis whatsoever.
-
You cite four articles: two are from the Intercept, one is from Reuters and
one is from the New York Times. You claim that the fact that they are years
apart bolsters their credibility; why is this the case? In fact, these
articles all parrot almost exactly the same story, with some minor
additions, updates and modifications. They all almost read like the same
article, despite their temporal distribution. Furthermore, the notion that
the articles are "extensively sourced" is simply incorrect: all of the
articles are based on anonymous sources and none of them provide a shred of
evidence, which is why we are in this debate to begin with (or so I've been
thinking).

It should also be noted that both The Intercept and the New York Times have
published misleading and incorrect information many times in their history.
The Intercept in particular has a very spotty credibility record.

It is also is not difficult to theorize how a politically trendy topic
(cyberattacks) against the world's most easy-to-villainize company (an
Arabic offensive cybersecurity company operating within a true monarchic
state) would be appealing to American journalists. This sort of thing isn't
new, and American "digital rights" groups have previously linked malicious
cyberattacks to Middle Eastern countries without providing something that
is even close to the same standard of evidence that they almost always
provide when naming American or European actors.

Is is indeed unfortunate that this issue was dealt with in a single
paragraph: I would have expected it to be the brunt of the email given its
importance, and it is impossible to qualify that reporting as "credible"
and "extensively sourced" so summarily.

-
3: Culminating in an argument that simply boils down to "the people's
safety", a trope that is often overused and that leads to undemocratic
behavior.
-

We don't know if DarkMatter is an evil spying empire that doesn't care
about the rights and dignity of private citizens or not. We don't know if
they're setting up shell companies to mislead Mozilla's CA vetting
procedures or not. In fact, it's been months where no new information has
arisen and I would like to repeat that I do not _at all_ discount the
possibility that all of the allegations may turn out to be completely true.

But instead of making effort towards resolving this uncertainty, or, in
case that's not possible, create procedures to deal with it, we see it
being wielded in order to increase the subjectivity of the decision making
that gatekeeps some of the most fundamental issues of Internet security and
to legitimize shoddy thinking.

Individually, your apparent decision against DarkMatter doesn't bother me.
It is the decision making process itself however that risks setting a
dangerous precedent that is already taking shape in other parts of the tech
community, where major decisions are predicated on gut feeling and notions
of safety that are almost by design impossible to elucidate, and where
much-needed objectivity, vetting and reasoned behavior is relegated to
one-shot paragraphs that barely come with an apology.

In conclusion: perhaps it is exactly because DarkMatter are so incredibly
easy to demonize that we are so temporarily blind to an infinitely more
dangerous and terrifying lapse of judgement: one that may come from much
closer to home. I don't mind if DarkMatter loses out here, but 

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

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

Re: DarkMatter Concerns

[Cynthia Revström via dev-security-policy]

My view is a bit different, we have lots of CAs already, I think it is more
important to be extra secure rather than to take unnecessary risks.
While I do understand that Dark Matter's focus is on the UAE, I also have
to say, as far as I am aware, there are multiple CAs that will issue certs
to people in the UAE.
That would be my view if I knew nothing else about DarkMatter, but due to
the stuff piling up against them I have to say this, why take the risk?
At some point we have to go and think about other parts than purely
technical capability, and there seems to be evidence that Dark Matter has
done sketchy stuff in the past.
This all makes it hard for me to personally justify why the DM should be
included.
While I don't like making it hard for new competitors to enter, the CA
market is quite special where everyone has to behave properly otherwise the
system doesn't work.

And even if this is just concerns and nothing actually happened, why should
they be included? A CA has to be trusted, if people who work with this
don't trust them, I don't see why they should be included.

- Cynthia

On Sun, Jun 23, 2019 at 6:44 PM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That article doesn’t seem to say anything new about Dark Matter that
> hasn’t been reported before, doesn’t present evidence and doesn’t cite
> sources. Furthermore the article appears to allege that Dark Matter
> “discussed” potentially targeting The Intercept, not that it “tried to hack
> several of their employees”. To wit, from the article:
>
> "It is not clear if an attack against The Intercept was ever carried out."
>
> I understand the concerns regarding Dark Matter but uncertainty shouldn’t
> lead to this level of low quality arguments. I still hope that stronger
> evidence against Dark Matter will come forward so that this can be settled
> once and for all.
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
>
> > On Jun 21, 2019, at 7:43 PM, coop...@gmail.com wrote:
> >
> > This thread hasn't been updated in a while so I'm not sure what the
> status is of dark matter being accepted but I thought this was a relevant
> update. The, US based reporting agency The Intercept recently issued a
> report claiming that Dark Matter has tried to hack several of their
> employees.
> https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/
> >
> > I'm sure that Dark Matter will claim this is "fake news" as they have
> previously, but I'm not inclined to believe that The Intercept would
> publish a story of this magnitude without fact checking and unless they
> were 100% sure of it. At this point I feel that there is a preponderance of
> evidence that Dark Matter are bad faith actors and would significantly
> diminish the trustworthiness of the CA system if they were to be included.
>
> ___
> 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

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

That article doesn’t seem to say anything new about Dark Matter that hasn’t 
been reported before, doesn’t present evidence and doesn’t cite sources. 
Furthermore the article appears to allege that Dark Matter “discussed” 
potentially targeting The Intercept, not that it “tried to hack several of 
their employees”. To wit, from the article:

"It is not clear if an attack against The Intercept was ever carried out."

I understand the concerns regarding Dark Matter but uncertainty shouldn’t lead 
to this level of low quality arguments. I still hope that stronger evidence 
against Dark Matter will come forward so that this can be settled once and for 
all.

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

> On Jun 21, 2019, at 7:43 PM, coop...@gmail.com wrote:
> 
> This thread hasn't been updated in a while so I'm not sure what the status is 
> of dark matter being accepted but I thought this was a relevant update. The, 
> US based reporting agency The Intercept recently issued a report claiming 
> that Dark Matter has tried to hack several of their employees. 
> https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/
> 
> I'm sure that Dark Matter will claim this is "fake news" as they have 
> previously, but I'm not inclined to believe that The Intercept would publish 
> a story of this magnitude without fact checking and unless they were 100% 
> sure of it. At this point I feel that there is a preponderance of evidence 
> that Dark Matter are bad faith actors and would significantly diminish the 
> trustworthiness of the CA system if they were to be included.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[cooperq--- via dev-security-policy]

This thread hasn't been updated in a while so I'm not sure what the status is 
of dark matter being accepted but I thought this was a relevant update. The, US 
based reporting agency The Intercept recently issued a report claiming that 
Dark Matter has tried to hack several of their employees. 
https://theintercept.com/2019/06/12/darkmatter-uae-hack-intercept/

I'm sure that Dark Matter will claim this is "fake news" as they have 
previously, but I'm not inclined to believe that The Intercept would publish a 
story of this magnitude without fact checking and unless they were 100% sure of 
it. At this point I feel that there is a preponderance of evidence that Dark 
Matter are bad faith actors and would significantly diminish the 
trustworthiness of the CA system if they were to be included.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

Thank you for sharing this information Scott.

On Wed, May 15, 2019 at 2:49 AM Scott Rea  wrote:

>
> Please advise if additional information relating to this change is
> required.
>
>
As pointed out in earlier discussions about DarkMatter's QuoVadis-signed
intermediates [1], and the policy 2.7 proposal that aims resolve this issue
[2], it's not clear if section 8 of Mozilla policy applies to subordinate
CA certificates, or only roots. Given the lack of clarity and enforcement
to-date, I do not believe that the section 8.1 requirement for "...a public
discussion regarding their admittance to the root program, which Mozilla
must resolve with a positive conclusion in order for the affected
certificate(s) to remain in the root program" should be applied to this
change at this time. The information you provided will, of course, be
considered as part of the ongoing distrust discussion that will continue in
this thread.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/xGGGaI1_uo0/e2e6RAEBBgAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/bWc70D8Kk6I/fafb9lXqCwAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Folks,
 
As previously discussed on this thread, the DarkMatter Trust Services practice 
(including DarkMatter CAs) has been operated in a separate entity to the DM 
Group, that entity is Digital Trust – Sole Proprietorship L.L.C. 
(“DigitalTrust”) which was established in the United Arab Emirates in 2016.  
DigitalTrust is an affiliate of the DM Group.  It was setup by the parent 
company to exclusively provide the Trust related business and has never been 
owned by DarkMatter LLC as a subsidiary since its incorporation. Up till now 
however, DarkMatter LLC has been involved in facilitating aspects of the Trust 
business, because we had some challenges with the trademarking of the 
independent entity’s original name etc. and it became more efficient to utilize 
the DM entity so as to not delay hiring and contracts etc. for the roll out of 
UAE NPKI services. We have now finalized that issue and will be transitioning 
all aspects of what has been known to the public as DM Trust Services 
(including DarkMatter CAs etc.) to the independent company DigitalTrust. All 
contracts for the CA Business are in the process of being novated over to 
DigitalTrust.
 
DigitalTrust is headed by myself, and I am the key individual responsible for 
management of the CA Business within Digital Trust. The shareholder of Digital 
Trust is DM Investments, and the beneficial owner of DM Investments is Mr. 
Faisal Al Bannai.  Although Legal Ownership of the CA Business is changing (per 
Section 8.1 of the Mozilla Root Policy), the Operational Personnel (Section 
8.2) and Secure Location (Section 8.3) for infrastructure are not changing – it 
is still my team who are the operators and only folks with control of Key 
material. My team consists of professionals from many nations:  Director of 
Networks & Security Infrastructure is from USA; Director of Registration 
Authority and Technical Support is from Sweden; Sr PKI Architect is from 
Portugal; Sr Manager of CA Platform is from USA; other key personnel are from 
Ecuador, India, Philippines, and Belarus. These folks have all re-located here 
to the UAE to be a part of the DigitalTrust CA services.
 
From a program management perspective, the Policy Authority Board for 
DigitalTrust remains the same as it was previously – this consists of 
representation from four key areas of our business services: 1. PKI & 
Technology Expert, 2. Legal Expert, 3. Policy & Risk/Governance Expert, 4. 
Security Expert.
 
DigitalTrust is a private entity that has been engaged by the UAE Government to 
build, operate and maintain – on the Governments behalf – the necessary 
components of a National PKI. The Telecommunications Regulatory Authority (TRA) 
is the relevant authority within the UAE Government for regulatory oversight 
and leadership of the UAE National PKI program, but DigitalTrust has been 
engaged with the following responsibilities:
-  Operation of the NPKI technical infrastructure
-  Advisory services for governance activities
-  Representing the NPKI in Industry Working groups and relevant Trust 
Communities
-  Fulfill compliance and regulatory responsibilities for the NPKI 
operations
 
DigitalTrust will now become the point of contact for the UAE Global Root 
submissions.
 
DigitalTrust would also like withdraw the DarkMatter Root submissions 
previously provided and will replace these with new DigitalTrust Roots that we 
will use as the basis of trust for our commercial business going forward.
 
These actions will be reflected in the data contained in the CCADB.
 
Please advise if additional information relating to this change is required.
 
If anyone has any questions regarding this matter, please do not hesitate to 
contact me.


Regards,
-- 
Scott Rea


On 3/19/19, 10:25 AM, "dev-security-policy on behalf of Scott Rea via 
dev-security-policy"  wrote:

G’day Folks,

It was a pleasure meeting many of the Mozilla community face to face at the 
CAB Forum meeting at Apple HQ last week. There are many others of you however, 
whose interface to the community is right here on this list, and so I wanted to 
share my perspective and feedback here on the recent dialogue so that the 
openness and transparency of the community is preserved.

Over the past few weeks, there’s been much debate and shared points of view 
around DarkMatter’s multi-year process to have our CA Roots included in 
Mozilla’s Root Store. Who could have predicted that along the way, the 
community would have such wide-spread impact from the serialNumber entropy 
issue? I do think the BRs are a little ambiguously worded in this regards, and 
this is what certainly tripped us up, but upon learning what was intended by 
the standard, DarkMatter has completed its revocation of every still valid 
affected TLS certificate (~175), and we actioned that immediately, completing 
the process over about 72 hrs (timing over the week-end in the UAE was not 
optimal for us 

Re: DarkMatter Concerns

[galen.b.stephenson--- via dev-security-policy]

Greetings,

I'm basing my opinion on EFF's article (RE: 
https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else).
  I submit that EFF makes valid points and I agree with their assessment.  
DarkMatter appears to be a threat actor and should not be given any position of 
trust regarding certificate authority.

thanks
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[rich.salz--- via dev-security-policy]

 
> The New York Times article that you reference does not add anything new to 
> the misleading allegations previously published in the Reuters article.  It 
> simply repeats ad-nauseum a false, and categorically denied, narrative about 
> DarkMatter, under the guise of an investigative reporting on the alleged 
> surveillance practices of governmental authorities of foreign countries.

Have you written a letter to the editor listing corrections?  IF so, could you 
post a copy here?  IF not, why not?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

I'm not sure on the weighting of the two sides that you point out, but I do
broadly agree that it is about striking some balance between those two ends.

That said, if all outcomes are equally bad, I think I favor the bad outcome
that doesn't open the door to accusations of a discriminatory approach/bias.

On Fri, Mar 22, 2019 at 11:49 AM Nadim Kobeissi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> What a strange situation.
>
> On the one hand, denying DarkMatter's CA bid because of these press
> articles would set the precedent of refusing to accept the engagement and
> apparent good faith of a member of the industry, based only on hearsay and
> with no evidence.
>
> On the other hand, deciding to move forward with a good-faith, transparent
> and evidence-based approach actually risks creating a long-term undermining
> of public confidence in the CA inclusion process.
>
> It really seems to me that both decisions would cause damage to the CA
> inclusion process. The former would make it seem discriminatory (and to
> some even somewhat xenophobic, although I don't necessarily agree with
> that) while the latter would cast a serious cloud of uncertainty above the
> safety of the CA root store in general that I have no idea how anyone could
> or will eventually dispel.
>
> As a third party observer I genuinely don't know what could be considered a
> good move by Mozilla at this point. I want Mozilla to both offer good faith
> and a transparent process to anyone who promises to respect its mission,
> but I also want it to maintain the credibility and trust that it has built
> for its CA store. For it to seem impossible for Mozilla to do both at the
> same time seems deeply unfortunate and a seriously problematic setting for
> the future of this process overall.
>
> I really wish that solid evidence of the claims being made against
> DarkMatter is published (if it exists). That would be a great way for
> Mozilla to make a unilaterally defensible position.
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from Galaxy
>
> On Fri, Mar 22, 2019, 4:19 PM Benjamin Gabriel <
> benjamin.gabr...@darkmatter.ae> wrote:
>
> >
> >
> > Benjamin Gabriel | General Counsel & SVP Legal
> > Tel: +971 2 417 1417 | Mob: +971 55 260 7410
> > benjamin.gabr...@darkmatter.ae
> >
> > The information transmitted, including attachments, is intended only for
> > the person(s) or entity to which it is addressed and may contain
> > confidential and/or privileged material. Any review, retransmission,
> > dissemination or other use of, or taking of any action in reliance upon
> > this information by persons or entities other than the intended recipient
> > is prohibited. If you received this in error, please contact the sender
> and
> > destroy any copies of this information.
> >
> > On 2/24/19 11:08 AM, Nex wrote:
> >
> > > The New York Times just published another investigative report that
> > mentions
> > > DarkMatter at length, with additional testimonies going on the
> > > record:
> >
> > Dear Nex,
> >
> > The New York Times article that you reference does not add anything new
> to
> > the misleading allegations previously published in the Reuters article.
> It
> > simply repeats ad-nauseum a false, and categorically denied, narrative
> > about DarkMatter, under the guise of an investigative reporting on the
> > alleged surveillance practices of governmental authorities of foreign
> > countries.
> >
> > DarkMatter is strictly a commercial company which exists to provide
> > cyber-security and digital transformation services to our customers in
> the
> > United Arab Emirates, and the larger GCC and MENA regions.
> >
> > We have already noted that these misleading allegations about DarkMatter
> > were originally planted by defamatory and false sources - in two (2)
> > articles published on the internet - and are now repeatedly recycled by
> > irresponsible journalists looking for a sensationalist angle on
> > socio-political regional issues.  And we have consistently, and
> > categorically, denied and refuted all of the allegations about
> DarkMatter,
> > including on this forum. [1][2]
> >
> > The fact that New York Times has chosen to recycle these refuted false
> > narratives about DarkMatter, without reaching out to inquire on the real
> > DarkMatter story, is unfortunate.  At times like this - it is important
> to
> > note that not all news reporting is based on factual or true events, and
> is
> > sometimes based on undisclosed bias or in some instances on outright
> > fraudulent reporting.[3][4][5][6][7][8]
> >
> > We continue to push for responsible journalism that is based on truth and
> > verifiable facts.
> >
> > Regards,
> > Benjamin Gabriel
> > General Counsel, DarkMatter Group
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/QAj8vTobCAAJ
> > [2]
> >
> 

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

What a strange situation.

On the one hand, denying DarkMatter's CA bid because of these press
articles would set the precedent of refusing to accept the engagement and
apparent good faith of a member of the industry, based only on hearsay and
with no evidence.

On the other hand, deciding to move forward with a good-faith, transparent
and evidence-based approach actually risks creating a long-term undermining
of public confidence in the CA inclusion process.

It really seems to me that both decisions would cause damage to the CA
inclusion process. The former would make it seem discriminatory (and to
some even somewhat xenophobic, although I don't necessarily agree with
that) while the latter would cast a serious cloud of uncertainty above the
safety of the CA root store in general that I have no idea how anyone could
or will eventually dispel.

As a third party observer I genuinely don't know what could be considered a
good move by Mozilla at this point. I want Mozilla to both offer good faith
and a transparent process to anyone who promises to respect its mission,
but I also want it to maintain the credibility and trust that it has built
for its CA store. For it to seem impossible for Mozilla to do both at the
same time seems deeply unfortunate and a seriously problematic setting for
the future of this process overall.

I really wish that solid evidence of the claims being made against
DarkMatter is published (if it exists). That would be a great way for
Mozilla to make a unilaterally defensible position.

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

On Fri, Mar 22, 2019, 4:19 PM Benjamin Gabriel <
benjamin.gabr...@darkmatter.ae> wrote:

>
>
> Benjamin Gabriel | General Counsel & SVP Legal
> Tel: +971 2 417 1417 | Mob: +971 55 260 7410
> benjamin.gabr...@darkmatter.ae
>
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender and
> destroy any copies of this information.
>
> On 2/24/19 11:08 AM, Nex wrote:
>
> > The New York Times just published another investigative report that
> mentions
> > DarkMatter at length, with additional testimonies going on the
> > record:
>
> Dear Nex,
>
> The New York Times article that you reference does not add anything new to
> the misleading allegations previously published in the Reuters article.  It
> simply repeats ad-nauseum a false, and categorically denied, narrative
> about DarkMatter, under the guise of an investigative reporting on the
> alleged surveillance practices of governmental authorities of foreign
> countries.
>
> DarkMatter is strictly a commercial company which exists to provide
> cyber-security and digital transformation services to our customers in the
> United Arab Emirates, and the larger GCC and MENA regions.
>
> We have already noted that these misleading allegations about DarkMatter
> were originally planted by defamatory and false sources - in two (2)
> articles published on the internet - and are now repeatedly recycled by
> irresponsible journalists looking for a sensationalist angle on
> socio-political regional issues.  And we have consistently, and
> categorically, denied and refuted all of the allegations about DarkMatter,
> including on this forum. [1][2]
>
> The fact that New York Times has chosen to recycle these refuted false
> narratives about DarkMatter, without reaching out to inquire on the real
> DarkMatter story, is unfortunate.  At times like this - it is important to
> note that not all news reporting is based on factual or true events, and is
> sometimes based on undisclosed bias or in some instances on outright
> fraudulent reporting.[3][4][5][6][7][8]
>
> We continue to push for responsible journalism that is based on truth and
> verifiable facts.
>
> Regards,
> Benjamin Gabriel
> General Counsel, DarkMatter Group
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/QAj8vTobCAAJ
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/VZf8xR-hAgAJ
> [3] https://theintercept.com/2016/02/02/a-note-to-readers/
> [4]
> https://www.nytimes.com/2016/02/03/business/media/the-intercept-says-reporter-falsified-quotations.html
> [5]
> https://www.theguardian.com/media/2016/feb/02/the-intercept-fires-reporter-juan-thompson
> [6]
> https://www.nytimes.com/2013/05/05/public-editor/repairing-the-credibility-cracks-after-jayson-blair.html
> [7]
> https://www.nytimes.com/2003/05/11/us/correcting-the-record-times-reporter-who-resigned-leaves-long-trail-of-deception.html
> [8] https://en.wikipedia.org/wiki/The_New_York_Times_controversies
>
>
>
>
>
>
>
>
>
>

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

On Fri, Mar 22, 2019 at 9:19 AM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> On 2/24/19 11:08 AM, Nex wrote:
>
> > The New York Times just published another investigative report that
> mentions
> > DarkMatter at length, with additional testimonies going on the
> > record:
>
> Dear Nex,
>
> The New York Times article that you reference does not add anything new to
> the misleading allegations previously published in the Reuters article.  It
> simply repeats ad-nauseum a false, and categorically denied, narrative
> about DarkMatter, under the guise of an investigative reporting on the
> alleged surveillance practices of governmental authorities of foreign
> countries.
>
> DarkMatter is strictly a commercial company which exists to provide
> cyber-security and digital transformation services to our customers in the
> United Arab Emirates, and the larger GCC and MENA regions.
>
> We have already noted that these misleading allegations about DarkMatter
> were originally planted by defamatory and false sources - in two (2)
> articles published on the internet - and are now repeatedly recycled by
> irresponsible journalists looking for a sensationalist angle on
> socio-political regional issues.  And we have consistently, and
> categorically, denied and refuted all of the allegations about DarkMatter,
> including on this forum. [1][2]
>
> The fact that New York Times has chosen to recycle these refuted false
> narratives about DarkMatter, without reaching out to inquire on the real
> DarkMatter story, is unfortunate.  At times like this - it is important to
> note that not all news reporting is based on factual or true events, and is
> sometimes based on undisclosed bias or in some instances on outright
> fraudulent reporting.[3][4][5][6][7][8]
>
> We continue to push for responsible journalism that is based on truth and
> verifiable facts.
>
>
One could also argue that these examples [3][4][5] show The Intercept
holding themselves accountable for false reporting, thus adding credibility
to their story on DarkMatter [9] that was published months later.

[9]
https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/

Regards,
> Benjamin Gabriel
> General Counsel, DarkMatter Group
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/QAj8vTobCAAJ
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/VZf8xR-hAgAJ
> [3] https://theintercept.com/2016/02/02/a-note-to-readers/
> [4]
> https://www.nytimes.com/2016/02/03/business/media/the-intercept-says-reporter-falsified-quotations.html
> [5]
> https://www.theguardian.com/media/2016/feb/02/the-intercept-fires-reporter-juan-thompson
> [6]
> https://www.nytimes.com/2013/05/05/public-editor/repairing-the-credibility-cracks-after-jayson-blair.html
> [7]
> https://www.nytimes.com/2003/05/11/us/correcting-the-record-times-reporter-who-resigned-leaves-long-trail-of-deception.html
> [8] https://en.wikipedia.org/wiki/The_New_York_Times_controversies
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Benjamin Gabriel | General Counsel & SVP Legal
Tel: +971 2 417 1417 | Mob: +971 55 260 7410
benjamin.gabr...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

On 2/24/19 11:08 AM, Nex wrote:

> The New York Times just published another investigative report that
> mentions DarkMatter at length, with additional testimonies going on
> the
> record:

Dear Nex,

The New York Times article that you reference does not add anything new to the 
misleading allegations previously published in the Reuters article.  It simply 
repeats ad-nauseum a false, and categorically denied, narrative about 
DarkMatter, under the guise of an investigative reporting on the alleged 
surveillance practices of governmental authorities of foreign countries.

DarkMatter is strictly a commercial company which exists to provide 
cyber-security and digital transformation services to our customers in the 
United Arab Emirates, and the larger GCC and MENA regions.

We have already noted that these misleading allegations about DarkMatter were 
originally planted by defamatory and false sources - in two (2) articles 
published on the internet - and are now repeatedly recycled by irresponsible 
journalists looking for a sensationalist angle on socio-political regional 
issues.  And we have consistently, and categorically, denied and refuted all of 
the allegations about DarkMatter, including on this forum. [1][2]

The fact that New York Times has chosen to recycle these refuted false 
narratives about DarkMatter, without reaching out to inquire on the real 
DarkMatter story, is unfortunate.  At times like this - it is important to note 
that not all news reporting is based on factual or true events, and is 
sometimes based on undisclosed bias or in some instances on outright fraudulent 
reporting.[3][4][5][6][7][8]

We continue to push for responsible journalism that is based on truth and 
verifiable facts.

Regards,
Benjamin Gabriel
General Counsel, DarkMatter Group

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/QAj8vTobCAAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/VZf8xR-hAgAJ
[3] https://theintercept.com/2016/02/02/a-note-to-readers/
[4] 
https://www.nytimes.com/2016/02/03/business/media/the-intercept-says-reporter-falsified-quotations.html
[5] 
https://www.theguardian.com/media/2016/feb/02/the-intercept-fires-reporter-juan-thompson
[6] 
https://www.nytimes.com/2013/05/05/public-editor/repairing-the-credibility-cracks-after-jayson-blair.html
[7] 
https://www.nytimes.com/2003/05/11/us/correcting-the-record-times-reporter-who-resigned-leaves-long-trail-of-deception.html
[8] https://en.wikipedia.org/wiki/The_New_York_Times_controversies









___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DarkMatter Concerns

[Benjamin Gabriel via dev-security-policy]

Benjamin Gabriel | General Counsel & SVP Legal
Tel: +971 2 417 1417 | Mob: +971 55 260 7410
benjamin.gabr...@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

On 2/24/19 11:08 AM, Nex wrote:

> The New York Times just published another investigative report that mentions
> DarkMatter at length, with additional testimonies going on the
> record:

Dear Nex,

The New York Times article that you reference does not add anything new to the 
misleading allegations previously published in the Reuters article.  It simply 
repeats ad-nauseum a false, and categorically denied, narrative about 
DarkMatter, under the guise of an investigative reporting on the alleged 
surveillance practices of governmental authorities of foreign countries.

DarkMatter is strictly a commercial company which exists to provide 
cyber-security and digital transformation services to our customers in the 
United Arab Emirates, and the larger GCC and MENA regions.

We have already noted that these misleading allegations about DarkMatter were 
originally planted by defamatory and false sources - in two (2) articles 
published on the internet - and are now repeatedly recycled by irresponsible 
journalists looking for a sensationalist angle on socio-political regional 
issues.  And we have consistently, and categorically, denied and refuted all of 
the allegations about DarkMatter, including on this forum. [1][2]

The fact that New York Times has chosen to recycle these refuted false 
narratives about DarkMatter, without reaching out to inquire on the real 
DarkMatter story, is unfortunate.  At times like this - it is important to note 
that not all news reporting is based on factual or true events, and is 
sometimes based on undisclosed bias or in some instances on outright fraudulent 
reporting.[3][4][5][6][7][8]

We continue to push for responsible journalism that is based on truth and 
verifiable facts.

Regards,
Benjamin Gabriel
General Counsel, DarkMatter Group

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/QAj8vTobCAAJ
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/VZf8xR-hAgAJ
[3] https://theintercept.com/2016/02/02/a-note-to-readers/
[4] 
https://www.nytimes.com/2016/02/03/business/media/the-intercept-says-reporter-falsified-quotations.html
[5] 
https://www.theguardian.com/media/2016/feb/02/the-intercept-fires-reporter-juan-thompson
[6] 
https://www.nytimes.com/2013/05/05/public-editor/repairing-the-credibility-cracks-after-jayson-blair.html
[7] 
https://www.nytimes.com/2003/05/11/us/correcting-the-record-times-reporter-who-resigned-leaves-long-trail-of-deception.html
[8] https://en.wikipedia.org/wiki/The_New_York_Times_controversies









___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nex via dev-security-policy]

On 2/24/19 11:08 AM, Nex wrote:
> On 2/23/19 11:07 AM, Scott Rea via dev-security-policy wrote:
>> G’day Wayne et al,
>>
>> In response to your post overnight (included below), I want to assure you 
>> that DarkMatter’s work is solely focused on defensive cyber security, secure 
>> communications and digital transformation. We have never, nor will we ever, 
>> operate or manage non-defensive cyber activities against any nationality.
>>
>> Furthermore, in the spirit of transparency, we have published all our public 
>> trust TLS certificates to appropriate CT log facilities (including even all 
>> our OV certificates) before this was even a requirement.  We have been 
>> entirely transparent in our operations and with our clients as we consider 
>> this a vital component of establishing and maintaining trust.
>>
>> We have used FIPS certified HSMs as our source of randomness in creating our 
>> Authority certificates, so we have opened an investigation based on Corey 
>> Bonnell’s earlier post regarding serial numbers and will produce a 
>> corresponding bug report on the findings.
>>
>> I trust this answers your concerns and we can continue the Root inclusion 
>> onboarding process.
> 
> For clarity, are you rejecting all of the following articles and blog
> posts as false and fabricated?
> 
> 1. https://www.reuters.com/investigates/special-report/usa-spying-raven/
> 2.
> https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
> 3.
> https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/

The New York Times just published another investigative report that
mentions DarkMatter at length, with additional testimonies going on the
record:

4.
https://www.nytimes.com/2019/03/21/us/politics/government-hackers-nso-darkmatter.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Folks,

It was a pleasure meeting many of the Mozilla community face to face at the CAB 
Forum meeting at Apple HQ last week. There are many others of you however, 
whose interface to the community is right here on this list, and so I wanted to 
share my perspective and feedback here on the recent dialogue so that the 
openness and transparency of the community is preserved.

Over the past few weeks, there’s been much debate and shared points of view 
around DarkMatter’s multi-year process to have our CA Roots included in 
Mozilla’s Root Store. Who could have predicted that along the way, the 
community would have such wide-spread impact from the serialNumber entropy 
issue? I do think the BRs are a little ambiguously worded in this regards, and 
this is what certainly tripped us up, but upon learning what was intended by 
the standard, DarkMatter has completed its revocation of every still valid 
affected TLS certificate (~175), and we actioned that immediately, completing 
the process over about 72 hrs (timing over the week-end in the UAE was not 
optimal for us otherwise we could have completed it sooner). We still need to 
re-issue the Issuing CAs and submitted Roots – these are dependent on the 
availability of our WebTrust Auditors, but we expect this to be finalized in 
the next week or so.

Many others in the community are also evaluating replacement of affected 
certificates e.g. see [1] [2] [3], etc. But the volumes these organizations are 
dealing with will make it difficult to meet BR revocation timelines, which is 
why I think Mozilla’s recent acknowledgement of this challenge with a proposal 
for an updated best practice for revocation is the right discussion to have. 

I think this is where the community is at its best: working together to 
identify and manage issues, learning from each other in how best to take action 
and resolving it as quickly as possible while maintaining the security and 
integrity of services for end users. After all, we ultimately share the same 
goal: transparent community-based processes that promote participation, 
accountability and trust [4].  

Resolving this issue together is a good example of this principle in action.

As I reflect on the many discussions in this community, and also with the 
40-odd companies at last week’s CA/B Forum, it is clear that there is quite an 
interest in the DarkMatter story. Unfortunately, the one that has often been 
promoted as evidence in this community – is one that is not based on truth, and 
one that has consistently been refuted by DarkMatter.  I would like to set the 
record straight once and for all, and share with all of you why DarkMatter’s 
story is not what some have claimed, but is, I believe, actually completely 
aligned with Mozilla’s own manifesto. 

DarkMatter Group was founded by Faisal Al Bannai, one of the most accomplished 
business leaders in the Middle East [5], as a commercial business entity that 
specializes in Cyber Security services, and solutions.  Al Bannai served as CEO 
and founder until recently (2018), when he handed over the leadership role of 
the company to Karim Sabbagh, formerly the CEO of the world leading satellite 
fleet operator SES [6].  Al Bannai is the sole beneficial shareholder of the 
DarkMatter Group.  The CA business that I head within the DarkMatter Group, and 
which I will provide further details below, is a completely independent 
business unit housed in a legally separate subsidiary company.

The general business of the DarkMatter Group is all centered around 
cybersecurity. DarkMatter is very active in our local constituency [7], [8], 
[9], we have even developed and launched our own mobile phone [10]. The 
Cybersecurity divisions of DarkMatter are fully engaged in and participate in 
identifying and disclosing malicious applications that attack the security and 
privacy of individuals everywhere.  Some recent examples of this are where 
DarkMatter researchers identified and informed Google of a malicious 
application available on the Google play store [11], and DarkMatter researchers 
also made a responsible disclosure to Apple of a significant attack that 
“bypasses all native macOS security measures”, (which findings were also 
presented at Hack-In-the-Box conference in Singapore [12]. This just highlights 
a couple.

For those who have questioned who is really in the driving seat of the 
DarkMatter CAs, I want to assure you that DarkMatter’s PKI business has always 
been operated independently. We are a legally separate entity – housed under a 
subsidiary of the DarkMatter Group. Only myself and my handpicked team ever 
have hands on key material, and no single individual can effect an issuance 
without the validation of a counterpart and always under multiparty and 
multifactor authentication.  We have stringent controls around who is eligible 
to hold a trusted role, and they must continue to meet operational KPIs, 
training and risk evaluation metrics to 

Re: DarkMatter Concerns

[Ronald F. Guilmette via dev-security-policy]

My apologies to the list for having unintentionally posted two
rather different versions of the same post, one long, and one
short.

I had initially tried to post using the Google Groups web interface,
but there was, apparently, a dramatic lag time in that post actually
being relayed to the list proper.  In fact, the lag time was so large
that I did not believe that my first attempt to post had worked at all.
(I believed that Googe Groups had simply sent it to a black hole
someplace.)  So I switched to Plan B, joined the mailing list proper,
and then posted a shorter version of what I had wanted to say, this
time via email.

Again, my apologies for the duplication.  I ask that everyone to believe
me when I say that I simply had no idea, until now, that messages were
being passed from Google Groups to Mozilla mailing lists via carrier
pigeon.


Regards,
rfg
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[rfg.no.like--- via dev-security-policy]

Wow!

I read this whole thread from top to bottom this afternoon/evening, and all I 
got was a splitting headache and this lousy t-shirt: https://bit.ly/2UpZxIz

But seriously folks, just a couple of simple questions.

Firstly, is this a private discussion or may any member of the Great Unwashed 
Massed wander in a share a thought or two?  (I have a couple such, but I'll 
admit up front that they may be worth what y'all are likely to pay for them.)

Second I've noted the frequent use of the word "transparency", or derivatives 
thereof, both within this thread, and also within the letter sent by the CEO of 
DarkMatter to Mozilla, a PDF of which was linked to earlier in this thread.  
(In that letter, that word, transparency, or a derivative thereof, was used no 
fewer than four times.)

I bring this up only because, after having read this whole thread from top to 
bottom, I seem to have missed any reference to any list which provides specific
information regarding the current set of natural person beneficial owners of 
DarkMatter.  Given DarkMatter's proclaimed and evident commitment to 
transparency, I feel quite sure that I must have just missed the link to that 
info, so if someone would be kind enough to re-post that, I sure would 
appreciate it.

I'll hold off sharing any other of my thoughts on this matter until I have an 
adequate opportunity to peruse that list, which I hope will include information 
on the percentage ownership for each of the relevant natural persons.

It will be quite interesting, for me at least, to see what other associations 
each of the relevant natural persons presently has, or has historically had.  
In the past, I've been able tease out some interesting information about 
corporate entities and their owners, purported or otherwise, via diligent 
research, including even at least one company that's incorporated in U.A.E.  
(Google for "HostSailor".  As it turned out, that thing was/is actually run by 
a native Egyptian who incorporated the company in U.A.E. but who quite possibly 
never even set foot in the country.  Oh yea.  And he threatened both me and 
Brian Krebs with lawsuits for saying bad things about him.  Apparently, word of 
the adoption of the U.S. First Amendment travels slowly to certain portions of 
the globe.  But I digress.)


Regards,
rfg
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ken Myers (personal capacity) via dev-security-policy]

On Thursday, March 7, 2019 at 11:14:46 AM UTC-5, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via
> dev-security-policy  wrote:
> 
> > Is the issue that a Dark Matter business unit may influence the Dark
> > Matter Trust Services (a separate unit, but part of the same company) to
> > issue certificates for malicious purposes?
> >
> > or is it a holistic corporate ethics issue (in regards to Mozilla
> > community safety) of a Mozilla-trusted service operated within a company
> > that sells offensive cyber services?
> >
> 
> This particular question is one that I'd very much like to see the program
> address officially.  I personally reject the "corporate ethics issue" as
> inappropriate to this domain, but I don't really get a vote.

I didn't see anything in the articles posted about the offensive cyber services 
using certificates from the Dark Matter CA unless it is implied that Dark 
Matter will use Dark Matter certificates to perform offensive actions a la 
Stuxnet or something like that.

If that is not implied, then it seems  it is a broader ethics issue of a trust 
service operated within a company selling offensive cyber services.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

On Thursday, March 7, 2019 at 6:35:13 PM UTC-5, Matt Palmer wrote:
> On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote:
> > Let's Encrypt does not quite provide certificates to everyone around the
> > world.  They do prevent issuance to and revoke prior certificates for those
> > on the United States various SDN (specially designated nationals) lists.
> > For example, units of the Iraqi government or those acting at their behest
> > may not receive Let's Encrypt certificates.
> > 
> > Obviously that is not an issue for the UAE or its people.  At least not
> > today.  But it always could be that it will be an issue someday.
> > 
> > What the people of the UAE don't have today is the ability to acquire
> > globally trusted certificates from a business in their own legal
> > jurisdiction who would be able to provide them with certificates even in
> > the face of exterior political force.
> 
> In the face of exterior political force, the people of the UAE couldn't get
> *globally trusted* certificates full-stop.  Off the top of my head, all of
> the widely-adopted web PKI trust stores are managed by US organisations. 
> One directive from the US government, and a trust anchor is *gone*.  Thus,
> having a trust anchor is not even a *sufficient* condition to produce the
> outcome you're advocating for, let alone a necessary one.

Maybe it is time for root programs to start thinking in moving their operations 
to more neutral countries, e.g. Switzerland.

> 
> if the UAE government, or its people, wishes to ensure their supply of
> "globally trusted" certificates, they need to start running their own PKI
> trust store.
> 
> - Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ronald F. Guilmette via dev-security-policy]

I've read what I believe to be all of the messages in this thread to
date, but it appears that I may have missed something.

The word "transparency" and/or derivatives thereof has come up several
times in this thread.  Also, that same word, or derivatives thereof,
was/were included no fewer than four times in the letter sent by the
DarkMatter CEO to Mozilla, a link to the PDF of which was provided
earlier in this thread.

As a steadfast advocate of transparency myself, I personally find it
heartening to see that so many participants in this discussion place
such an emphasis on transparency.  In view of this enthusiasm, I would
like to just ask if anyone can provide me with a pointer or a reference
to the place or document wherein a full list of the natural person
beneficial owners of DarkMatter may be found, preferably along with
indications of percentage ownership stakes of each such natural person
beneficial owner.

I am very eager to review whatever document or documents provide this
basic information.

My apologies to all if I just simply missed some earlier post in this
thread which supplied a link to this information.


Regards,
rfg
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

On Thursday, March 7, 2019 at 1:27:42 PM UTC-5, Kristian Fiskerstrand wrote:
> On 3/7/19 6:59 PM, Jaime Hablutzel via dev-security-policy wrote:
> > So the following holds true and (from my point of view) very critical
> > indeed. Quoting Benjamin Gabriel:
> > 
> >> ...that sovereign nations have the fundamental right to provide
> >> digital services to their own citizens, utilizing their own
> >> national root, without being held hostage by a provider situated in
> >> another nation.  You should note that DarkMatter's request is also
> >> for the inclusion of UAE's national root
> 
> I would question the assertion of any "fundamental right" of a sovereign
> nation in this context; But sidestepping that there are still
> alternative ways to achieve it than exposing all users globally to risk;
> E.g nothing would stop a local linux distribution, or a localized
> Microsoft product version, from including the root, 

This wouldn't help UAE's companies providing their services abroad.

> or the user to
> install it locally by choice, 

This is a burden for end users.

> as its citizens are more likely to accept
> the local laws as they are governed by them already.
> 
> Trust is ultimately a subjective consideration, and no list of
> requirement can ever be the full set of requirement, as any system based
> on such a method can and will be gamed.
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

On Thursday, March 7, 2019 at 10:17:21 AM UTC-5, Ryan Sleevi wrote:
> On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I would just like to remind you all the universally accepted concept of
> > "Presumption of innocence". Quoting from
> > https://en.wikipedia.org/wiki/Presumption_of_innocence:
> >
> > >The presumption of innocence is the legal principle that one is
> > considered innocent unless proven guilty. It was traditionally expressed by
> > the Latin maxim ei incumbit probatio qui dicit, non qui negat (“the burden
> > of proof is on the one who declares, not on one who denies”).
> >
> > Where it is useful to highlight the following phrases:
> >
> > - one is considered innocent unless *proven* guilty
> > - the *burden of proof is on the one who declares*, not on one who denies
> >
> > So, unless MDSP is the jury responsible for proving DM guilty, I think
> > they should be accepted until their mischief can be proved, although I'm
> > not sure who should/could be responsible for such a task.
> >
> 
> Thanks for sharing this, Jaime, and thank you for engaging in this
> discussion.
> 
> Unfortunately, there are a number of flaws with this thinking, which I want
> to highlight, although I hope it does not discourage further participation.
> 
> As you seem to acknowledge, MDSP is not a jury and this is not a legal
> proceeding. On that basis, the application of a "Presumption of Innocence"
> is not necessary nor relevant - we're not discussing legal proceedings
> here, nor is the goal to assess "guilt" or "innocence". The fundamental
> question of a root program is whether or not an organization is trustworthy.
> 
> In some ways, you may wish to think of CAs as custodians of a given root
> programs' trust, and since we're applying Latin concepts, the phrase "Quis
> custodiet ipsos custodes" is perhaps applicable here. The answer is that
> the root program supervises the CAs, through consultation with the public.
> If it helps to frame this in concepts that may be more familiar - even if
> they are far from a perfect match - you might think of this as how officers
> of organizations or politicians are held to higher standards, and things
> which might be acceptable in the general case are not acceptable for such
> parties.
> 
> However, I think it's more fundamentally flawed to see the process as
> "default trust". The answer is rather the opposite; the default answer is
> "do not trust", and it is the CAs duty to provide sufficient evidence to
> demonstrate both their trustworthiness and utility to a root program, such
> that the vendor is willing to enter into a business relationship with them
> and entrust them with protecting the security of their users.

Fair enough, after all, Mozilla's root program is a private initiative, but 
could you please just confirm to me if the "default deny" policy is clearly and 
formally documented as part of the Mozilla Root Store Policy?.

> 
> A good example of this principle ("default deny") at play is in the
> reliance upon audits. As practiced by WebTrust practitioners, the
> professional standards of auditors actually work from a view of assuming
> that none of the principles or criteria have been met by the organization.
> The organization being audited has a duty to produce and demonstrate
> sufficient evidence so as to convince a "reasonable" auditor that the CA is
> and has been meeting the various requirements. Using the AICPA as an
> example (and similar examples exist for ISAE and CPA Canada and other
> professional auditing bodies), you can see this at [1], and in particular,
> AT-C 105.10a or 105.25iii.
> 
> As noted elsewhere, the programs goals are not necessarily to include any
> entity who meets some perfunctory checklist, but to ensure that the
> benefits outweigh the risks for the typical user. As such, there is an
> inherent burden to highlight the benefits, just as there is a
> responsibility to evaluate solutions to mitigate risks, as some have
> offered [3]. Going back to legal concepts, as inappropriate for this
> discussion as they are, one might say that the "burden of proof" exists
> with each CA participating or applying to participate in a given root
> program to demonstrate their value and to produce evidence counter to the
> claims provided.
> 
> My previous message [4] highlighted some approaches that CAs might use to
> do that, while also highlighting that, fundamentally, audits alone do not
> and have never met that fundamental sufficiency.
> 
> I hope that helps explain the flaws in this reasoning, while also
> highlighting the standards being applied are well-understood and accepted
> concepts.
> 
> [1] https://www.aicpa.org/research/standards/auditattest/ssae.html
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ
> [4]

Re: DarkMatter Concerns

[Matt Palmer via dev-security-policy]

On Thu, Mar 07, 2019 at 05:30:24PM -0600, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > Whilst those are all good points, I don't see how any of them require the
> > CA
> > to control an unconstrained intermediate CA certificate (or a root
> > certificate).  All of those things can be done as a reseller or
> > third-party-managed CA.
> 
> There's a fundamental difference in gaining membership to a root store like
> the Mozilla program.
> 
> As I recall, the program intentionally doesn't maintain contractual
> relationships with the CAs.
> 
> It could be argued under US sanctions laws that the act of working with an
> entity and adding their root to the store could in that moment be a
> regulated transaction.  However, once it's on the trust list, its
> continuation there is not a new service or product being provided to a
> sanctioned entity.  At that point, it's merely continued publication of a
> curated list, which in the US qualifies as protected speech.

That's a *really* long bow to draw.  Also, whilst Mozilla might not maintain
a contractual relationship with a CA, other root programs *do*, so if the US
government wants something distrusted, they're gone.

Conversely, though, not all existing root CAs (or even intermediates) are
based in the US, so it should be *much* easier to find a CA to resell, than
to ensure that a trust anchor remains globally included.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 5:35 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> In the face of exterior political force, the people of the UAE couldn't get
> *globally trusted* certificates full-stop.  Off the top of my head, all of
> the widely-adopted web PKI trust stores are managed by US organisations.
> One directive from the US government, and a trust anchor is *gone*.  Thus,
> having a trust anchor is not even a *sufficient* condition to produce the
> outcome you're advocating for, let alone a necessary one.
>
> if the UAE government, or its people, wishes to ensure their supply of
> "globally trusted" certificates, they need to start running their own PKI
> trust store.
>

This gets fairly far afield, but it is far more likely that successful
defenses for maintaining the entry on the trust list could be made than for
the issuance of new certificates.

One of these is literally a case of mere publishing and only to software
users.  The other is the act of actually performing a signature (doing real
work specifically for the benefit of the subscriber).  That later case is
far less protected.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matt Palmer via dev-security-policy]

On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote:
> Let's Encrypt does not quite provide certificates to everyone around the
> world.  They do prevent issuance to and revoke prior certificates for those
> on the United States various SDN (specially designated nationals) lists.
> For example, units of the Iraqi government or those acting at their behest
> may not receive Let's Encrypt certificates.
> 
> Obviously that is not an issue for the UAE or its people.  At least not
> today.  But it always could be that it will be an issue someday.
> 
> What the people of the UAE don't have today is the ability to acquire
> globally trusted certificates from a business in their own legal
> jurisdiction who would be able to provide them with certificates even in
> the face of exterior political force.

In the face of exterior political force, the people of the UAE couldn't get
*globally trusted* certificates full-stop.  Off the top of my head, all of
the widely-adopted web PKI trust stores are managed by US organisations. 
One directive from the US government, and a trust anchor is *gone*.  Thus,
having a trust anchor is not even a *sufficient* condition to produce the
outcome you're advocating for, let alone a necessary one.

if the UAE government, or its people, wishes to ensure their supply of
"globally trusted" certificates, they need to start running their own PKI
trust store.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Whilst those are all good points, I don't see how any of them require the
> CA
> to control an unconstrained intermediate CA certificate (or a root
> certificate).  All of those things can be done as a reseller or
> third-party-managed CA.


There's a fundamental difference in gaining membership to a root store like
the Mozilla program.

As I recall, the program intentionally doesn't maintain contractual
relationships with the CAs.

It could be argued under US sanctions laws that the act of working with an
entity and adding their root to the store could in that moment be a
regulated transaction.  However, once it's on the trust list, its
continuation there is not a new service or product being provided to a
sanctioned entity.  At that point, it's merely continued publication of a
curated list, which in the US qualifies as protected speech.

On the other hand, if DarkMatter (or any other foreign entity) signed a
managed SubCA deal with a CA such as Digicert (based in the US), at any
time down the road, the foreign entity might be for whatever reason subject
to US sanctions.  If that happened, any active service or product delivery
performance by Digicert would have to stop.

And so, there is a material difference.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 11:55 AM Wayne Thayer  wrote:

This line of thinking seems to conflate a few different issues.
>

That is true.  I apologize for that, but also feel that some of these
different issues and how they'd play out in relation with this current
matter and ultimately with the inclusion request need to be discussed.


> There are roughly 195 nations in existence today. I would guess that less
> than half have a domestic, publicly-trusted CA. I would agree that we have
> a big problem if websites in any jurisdiction can't obtain trusted
> certificates. The Mozilla manifesto [1] states "We are committed to an
> internet that includes all the peoples of the earth" and "The internet is a
> global public resource that must remain open and accessible". However, I
> don't think that minting 100 new CAs is the best, or even a good way to
> solve the problem.
>

Probably not a good way, but it is likely to be an effective one.


> Many CAs offer robust "reseller" programs that would allow a local company
> to provide certificates to a given region in the local language and
> currency. I acknowledge that this does not address the "exterior political
> force" portion of the concern, but it does address the concern of making it
> easy for website operators in any given country to obtain certificates.
>

Some of my concerns relate particularly to this.  As an example, once upon
a time it was forbidden for US citizens in the general case to engage in
transactions with Cuban individuals or entities (whether a part of Cuban
government or not).  That would effectively disable US based CAs from
issuing end-entity certificates to those parties.  Today, I don't believe
we immediately have that restriction, but it can happen as it has happened
before.

After the example case I've mentioned elsewhere in this thread,
usareally.com, lost its certificate from Let's Encrypt, the CT Logs suggest
that they turned to GlobalSign (who I don't believe are US based) and yet
still issued and quickly revoked certificates for the site.  At this time,
the site ultimately secured certificates from WoTrust (I believe a managed
subCA effectively operated by Certum).  It's conceivable that geopolitical
concerns could prevent potential subscribers from getting certificates.


> The very next request in the Mozilla inclusion queue is for the UAE
> government. [2] Denying DarkMatter does not mean that there can't or won't
> be a CA in the UAE.
>

Indeed, which further opens up a question of what the outcome of the
initial question of whether to revoke/OneCRL the DarkMatter intermediates
means in terms of a future where the UAE is permitted a national PKI.  What
if you OneCRL Dark Matter, only to have the UAE National CA decide that
commercial and individual interests in the UAE would be served by having at
least one commercial CA operating in-country and so create a fully
delegated SubCA for DarkMatter?  (I have no insider knowledge at all here -
no reason to suspect things would or could go that way.)  But pre-supposing
the possibility that Mozilla would need to respond to that in some way is
intriguing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matt Palmer via dev-security-policy]

On Wed, Mar 06, 2019 at 08:56:47PM -0800, astronut--- via dev-security-policy 
wrote:
> Setting aside the discussion about DarkMatter specifically, here are some
> ways in which having a CA in a new jurisdiction that isn't currently
> represented in the ecosystem can bring value:
>
> * Allow users to transact business in their normal currency
>
> * Allow users to transact business without international currency usage
>   fees
>
> * A "domestic" CA is far more likely to be able to do business in the
>   local language compared to CAs that don't have any presence in a country
>   where that language is spoken.
>
> * Many, if not all, subscription agreements have a choice of venue clause
>   in them.  A "local" CA allows subscribers to ensure the contract is
>   subject to their local laws rather than those of a foreign country
>
> * There are many other factors easier to transact business domestically
>   than internationally, even with things as benign as contacting the CA by
>   phone or mail.

Whilst those are all good points, I don't see how any of them require the CA
to control an unconstrained intermediate CA certificate (or a root
certificate).  All of those things can be done as a reseller or
third-party-managed CA.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 11:33 AM Wayne Thayer  wrote:

> Nadim and Matthew,
>
> Can you explain and provide examples for how this "set of empirical
> requirements" differs from the objective requirements that currently exist?
>

Hi, Wayne,

I think the matter of whether or not I could or should opine on that
question essentially turns on events for which we don't yet have outcomes.

Specifically, if the decision is made that the current DarkMatter
intermediates do not require revocation and listing in OneCRL or if that
action is taken but without further prejudice to their root inclusion
request (say, for example, by mutual consent of the program and DarkMatter
that it would be acceptable to move forward without prejudice on a new root
hierarchy), then I would believe that objective policy as set out had been
followed and so there would be no delta versus current policy for me to
propose.

If, at the other extreme end, the intermediate is revoked and OneCRL'ed
with prejudice to continuing the root inclusion request AND the stated
cause were rooted principally in a subjective perception of the
organization versus objective data points, I would propose significant
changes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 11:29 AM James Burton  wrote:

> I'm talking about someone from a restricted country using a undocumented
> domain name to obtain a Let's Encrypt certificate and there is nothing that
> can be done about it. We can't predict the future.
>

So your assertion, then, is that when a domain is outed as owned by an SDN
listed party, that the SDN listed party should just acquire a new domain
name?  Giving up their one identifier that there's broad consensus on
having continuing relevancy in the WebPKI?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Kristian Fiskerstrand via dev-security-policy]

On 3/7/19 6:59 PM, Jaime Hablutzel via dev-security-policy wrote:
> So the following holds true and (from my point of view) very critical
> indeed. Quoting Benjamin Gabriel:
> 
>> ...that sovereign nations have the fundamental right to provide
>> digital services to their own citizens, utilizing their own
>> national root, without being held hostage by a provider situated in
>> another nation.  You should note that DarkMatter's request is also
>> for the inclusion of UAE's national root

I would question the assertion of any "fundamental right" of a sovereign
nation in this context; But sidestepping that there are still
alternative ways to achieve it than exposing all users globally to risk;
E.g nothing would stop a local linux distribution, or a localized
Microsoft product version, from including the root, or the user to
install it locally by choice, as its citizens are more likely to accept
the local laws as they are governed by them already.

Trust is ultimately a subjective consideration, and no list of
requirement can ever be the full set of requirement, as any system based
on such a method can and will be gamed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

On Thursday, March 7, 2019 at 12:30:03 PM UTC-5, James Burton wrote:
> I'm talking about someone from a restricted country using a undocumented
> domain name to obtain a Let's Encrypt certificate and there is nothing that
> can be done about it. 

Until they get caught and their certificates revoked (with the corresponding 
service disruption) as indicated in 
https://community.letsencrypt.org/t/according-to-mcclatchydc-com-lets-encrypt-revoqued-and-banned-usareally-com/81517/10?u=hablutzel1:

> When it is brought to our attention that we are serving an entity on the SDN 
> list, and if we can confirm the report, we will respond by revoking 
> outstanding certs and banning future issuance to the entity.
>
>...
>
>This happens to maybe one domain per month, to give you some idea of the 
>frequency.

So in the best case scenario they could keep getting free LE certificates at 
the expense of the quality of the service they provide, e.g. because of the 
need to renew domains constantly.

> We can't predict the future.
> 
> Thank you,
> 
> Burton
> 
> On Thu, Mar 7, 2019 at 5:23 PM Matthew Hardeman  wrote:
> 
> >
> > On Thu, Mar 7, 2019 at 11:11 AM James Burton  wrote:
> >
> >> Let's be realistic, anyone can obtain a domain validated certificate from
> >> Let's Encrypt and there is nothing really we can do to prevent this from
> >> happening. Methods exist.
> >>
> >
> > I am continuing to engage in this tangent only in as far as it illustrates
> > the kinds of geopolitical issues that already taint this space and in as
> > much as that, I believe has some relevance for the larger conversation.
> > Now that I've said that, please, by all means, if I'm wrong about the
> > referenced assertion that I've posted, reach out to the usareally.com
> > people and help them get a Let's Encrypt certificate.  Good luck with that.
> >
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

On Thursday, March 7, 2019 at 11:20:54 AM UTC-5, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> >
> > There isn't any monopoly that prevents citizens and organizations in the
> > United Arab Emirates to get certificates from CAs and they are not
> > expensive. Let's Encrypt provides free domain validated certificates to
> > everyone around the world. Next.
> >
> 
> This is not entirely accurate and the manner in which it is inaccurate may
> be material to this discussion.
> 
> Let's Encrypt does not quite provide certificates to everyone around the
> world.  They do prevent issuance to and revoke prior certificates for those
> on the United States various SDN (specially designated nationals) lists.
> For example, units of the Iraqi government or those acting at their behest
> may not receive Let's Encrypt certificates.
> 
> Obviously that is not an issue for the UAE or its people.  At least not
> today.  But it always could be that it will be an issue someday.
> 
> What the people of the UAE don't have today is the ability to acquire
> globally trusted certificates from a business in their own legal
> jurisdiction who would be able to provide them with certificates even in
> the face of exterior political force.

I think that the information you provided made it clear that there actually 
exists a *benefit for the consumers* allowing UAE's national root to be 
included in the program, because it provides safeguards to their citizens and 
companies (in the context of UAE's national cyber security strategy) in the 
event of an international conflict (e.g. a war for whatever reason), where 
adversary countries could impose sanctions for them, provoking disruption in 
their services because of their certificates (obtained from foreign CAs) 
getting revoked. 

Although it is worth noting that the advantages of managing their own national 
root for the sake of sovereignty defense would be clearly diminished if the 
Mozilla root program (or the company behind?) could be obliged by any 
government at that point to retire UAE's national root from the program too.

So the following holds true and (from my point of view) very critical indeed. 
Quoting Benjamin Gabriel:

> ...that sovereign nations have the fundamental right to provide digital 
> services to their own citizens, utilizing their own national root, without 
> being held hostage by a provider situated in another nation.  You should note 
> that DarkMatter's request is also for the inclusion of UAE's national root.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

On Thu, Mar 7, 2019 at 9:20 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> What the people of the UAE don't have today is the ability to acquire
> globally trusted certificates from a business in their own legal
> jurisdiction who would be able to provide them with certificates even in
> the face of exterior political force.
>
> This line of thinking seems to conflate a few different issues.

There are roughly 195 nations in existence today. I would guess that less
than half have a domestic, publicly-trusted CA. I would agree that we have
a big problem if websites in any jurisdiction can't obtain trusted
certificates. The Mozilla manifesto [1] states "We are committed to an
internet that includes all the peoples of the earth" and "The internet is a
global public resource that must remain open and accessible". However, I
don't think that minting 100 new CAs is the best, or even a good way to
solve the problem.

Many CAs offer robust "reseller" programs that would allow a local company
to provide certificates to a given region in the local language and
currency. I acknowledge that this does not address the "exterior political
force" portion of the concern, but it does address the concern of making it
easy for website operators in any given country to obtain certificates.

The very next request in the Mozilla inclusion queue is for the UAE
government. [2] Denying DarkMatter does not mean that there can't or won't
be a CA in the UAE.

[1] https://www.mozilla.org/en-US/about/manifesto/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1474556
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

Nadim and Matthew,

Can you explain and provide examples for how this "set of empirical
requirements" differs from the objective requirements that currently exist?

Nadim, your latest suggestion sounds different from your earlier suggestion
that Mozilla provide a "set of unambiguous statements for which it would
require DarkMatter to categorically and fully deny." In my opinion, the
question is not if DarkMatter can make such promises (their CP already
states  that “Public Trust Issuing CAs in the UAE National PKI must not be
used for Man in the Middle (MITM) purposes”), but if DarkMatter is trusted
to uphold such promises.

- Wayne

On Thu, Mar 7, 2019 at 9:10 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Mar 7, 2019 at 9:18 AM nadim--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > I would like to repeat my call for establishing a set of empirical
> > requirements that take into account the context of DarkMatter's current
> > position in the industry as well as their specific request for the
> > inclusion of a specific root CA.
>
>
> I also concur in this to the extent possible.
>
>
> > While I don't necessarily fully support the method with which Benjamin
> > chose to address Ryan's contributions to the discussion so far, I think
> > we're all choosing to kid ourselves here if we continue to say that the
> > underlying impetus for this discussion isn't primarily sociopolitical.
> The
> > sooner an end is put to this, the better.
> >
>
> I concur in as far as the result, which is to say that I don't necessarily
> say that it _is_ "primarily sociopolitical" but rather that there is at
> least the appearance and nearly indefensible criticism that it could be.
>
>
> > The right thing to do, right now, is for there to be a documented process
> > through which a set of empirical, falsifiable, achievable requirements
> are
> > set by either Mozilla, the CABForum, or both, for DarkMatter to fulfill
> so
> > that they can be considered for inclusion. If these requirements are (1)
> > defined fairly and (2) achieved by DarkMatter verifiably, then great.
> > Otherwise, too bad.
> >
>
> Indeed the ramifications of a discretionary revocation of the intermediates
> or block from joining the root program, if not objectively and cleanly
> explained, would likely have a chilling effect on ANY newcomer.  When a
> reasonable, documentable, objective path to earning and maintaining trust
> in the program exists, investment of time and resources can reasonably
> flow.  A new counter-case of an organization that has met all the
> requirements and still somehow doesn't meet the bar would be most
> discouraging.
> ___
> 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

Re: DarkMatter Concerns

[James Burton via dev-security-policy]

I'm talking about someone from a restricted country using a undocumented
domain name to obtain a Let's Encrypt certificate and there is nothing that
can be done about it. We can't predict the future.

Thank you,

Burton

On Thu, Mar 7, 2019 at 5:23 PM Matthew Hardeman  wrote:

>
> On Thu, Mar 7, 2019 at 11:11 AM James Burton  wrote:
>
>> Let's be realistic, anyone can obtain a domain validated certificate from
>> Let's Encrypt and there is nothing really we can do to prevent this from
>> happening. Methods exist.
>>
>
> I am continuing to engage in this tangent only in as far as it illustrates
> the kinds of geopolitical issues that already taint this space and in as
> much as that, I believe has some relevance for the larger conversation.
> Now that I've said that, please, by all means, if I'm wrong about the
> referenced assertion that I've posted, reach out to the usareally.com
> people and help them get a Let's Encrypt certificate.  Good luck with that.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 11:11 AM James Burton  wrote:

> Let's be realistic, anyone can obtain a domain validated certificate from
> Let's Encrypt and there is nothing really we can do to prevent this from
> happening. Methods exist.
>

I am continuing to engage in this tangent only in as far as it illustrates
the kinds of geopolitical issues that already taint this space and in as
much as that, I believe has some relevance for the larger conversation.
Now that I've said that, please, by all means, if I'm wrong about the
referenced assertion that I've posted, reach out to the usareally.com
people and help them get a Let's Encrypt certificate.  Good luck with that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[James Burton via dev-security-policy]

Let's be realistic, anyone can obtain a domain validated certificate from
Let's Encrypt and there is nothing really we can do to prevent this from
happening. Methods exist.

Thank you,

Burton

On Thu, Mar 7, 2019 at 4:59 PM Matthew Hardeman  wrote:

>
> On Thu, Mar 7, 2019 at 10:54 AM James Burton  wrote:
>
>> Let's Encrypt issues domain validation certificates and anyone with a
>> suitable domain name (e.g. .com, .net, .org  ) can get one of these
>> certificates just by proving control over the domain by using the DNS or "
>> /.well-known/pki-validation" directory as stated in the CAB Forum baseline
>> requirements. Country location doesn't matter.
>>
>
> I'm sorry, but that is inaccurate.  There are literally banned
> subscribers.  Let's Encrypt has publicly and officially acknowledged
> this[1].
>
> [1]
> https://community.letsencrypt.org/t/according-to-mcclatchydc-com-lets-encrypt-revoqued-and-banned-usareally-com/81517/10?u=mdhardeman
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 10:54 AM James Burton  wrote:

> Let's Encrypt issues domain validation certificates and anyone with a
> suitable domain name (e.g. .com, .net, .org  ) can get one of these
> certificates just by proving control over the domain by using the DNS or "
> /.well-known/pki-validation" directory as stated in the CAB Forum baseline
> requirements. Country location doesn't matter.
>

I'm sorry, but that is inaccurate.  There are literally banned
subscribers.  Let's Encrypt has publicly and officially acknowledged
this[1].

[1]
https://community.letsencrypt.org/t/according-to-mcclatchydc-com-lets-encrypt-revoqued-and-banned-usareally-com/81517/10?u=mdhardeman
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Folks,

My apologies, I have been airborne without connectivity and it appears I have a 
LOT of dialogue to catch up on.

At DarkMatter, we are passionate about what we do (as I know most folks 
contributing here are also - just by very nature of the time and effort taken 
to engage). The operations of the Trust Services business unit is my 
responsibility.

The DM Trust Services team has has been working studiously for more than 3 
years to bring to realization a Certification Authority capable of providing 
services in our local market that can also be recognized in the global 
community at large.

The Mozilla community is not just a valuable partner in this endeavor, but also 
a critical milestone to measure our progress against.

We want to engage in an open discussion. We just want a fair and transparent 
debate and process.

I am committed to a respectful dialogue, and I too (as others have already 
suggested here) would appreciate clear and definitive criteria in respect to 
what Mozilla requires to enable DM Trust Services to demonstrate we have the 
same commitment to security and trust that the Mozilla community subscribes to, 
and as such, that we may be considered for inclusion in the Root Store.

Regards,
-Scott


Scott Rea | Senior Vice President - Trust Services
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.








___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[James Burton via dev-security-policy]

I mean country location of the individual doesn't matter. They could be for
example be using a VPN to connect to Google Cloud instance and get a
certificate that way.

Thank you,

Burton

On Thu, Mar 7, 2019 at 4:53 PM James Burton  wrote:

> Let's Encrypt issues domain validation certificates and anyone with a
> suitable domain name (e.g. .com, .net, .org  ) can get one of these
> certificates just by proving control over the domain by using the DNS or "
> /.well-known/pki-validation" directory as stated in the CAB Forum baseline
> requirements. Country location doesn't matter.
>
> Thank you
>
> Burton
>
>
> On Thu, Mar 7, 2019 at 4:29 PM Matthew Hardeman 
> wrote:
>
>>
>>
>> On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman 
>> wrote:
>>
>>>
>>> Let's Encrypt does not quite provide certificates to everyone around the
>>> world.  They do prevent issuance to and revoke prior certificates for those
>>> on the United States various SDN (specially designated nationals) lists.
>>> For example, units of the Iraqi government or those acting at their behest
>>> may not receive Let's Encrypt certificates.
>>>
>>
>> Whoops!  I meant to say the Iranian government.
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[James Burton via dev-security-policy]

Let's Encrypt issues domain validation certificates and anyone with a
suitable domain name (e.g. .com, .net, .org  ) can get one of these
certificates just by proving control over the domain by using the DNS or "
/.well-known/pki-validation" directory as stated in the CAB Forum baseline
requirements. Country location doesn't matter.

Thank you

Burton


On Thu, Mar 7, 2019 at 4:29 PM Matthew Hardeman  wrote:

>
>
> On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman 
> wrote:
>
>>
>> Let's Encrypt does not quite provide certificates to everyone around the
>> world.  They do prevent issuance to and revoke prior certificates for those
>> on the United States various SDN (specially designated nationals) lists.
>> For example, units of the Iraqi government or those acting at their behest
>> may not receive Let's Encrypt certificates.
>>
>
> Whoops!  I meant to say the Iranian government.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman 
wrote:

>
> Let's Encrypt does not quite provide certificates to everyone around the
> world.  They do prevent issuance to and revoke prior certificates for those
> on the United States various SDN (specially designated nationals) lists.
> For example, units of the Iraqi government or those acting at their behest
> may not receive Let's Encrypt certificates.
>

Whoops!  I meant to say the Iranian government.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> There isn't any monopoly that prevents citizens and organizations in the
> United Arab Emirates to get certificates from CAs and they are not
> expensive. Let's Encrypt provides free domain validated certificates to
> everyone around the world. Next.
>

This is not entirely accurate and the manner in which it is inaccurate may
be material to this discussion.

Let's Encrypt does not quite provide certificates to everyone around the
world.  They do prevent issuance to and revoke prior certificates for those
on the United States various SDN (specially designated nationals) lists.
For example, units of the Iraqi government or those acting at their behest
may not receive Let's Encrypt certificates.

Obviously that is not an issue for the UAE or its people.  At least not
today.  But it always could be that it will be an issue someday.

What the people of the UAE don't have today is the ability to acquire
globally trusted certificates from a business in their own legal
jurisdiction who would be able to provide them with certificates even in
the face of exterior political force.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via
dev-security-policy  wrote:

> Is the issue that a Dark Matter business unit may influence the Dark
> Matter Trust Services (a separate unit, but part of the same company) to
> issue certificates for malicious purposes?
>
> or is it a holistic corporate ethics issue (in regards to Mozilla
> community safety) of a Mozilla-trusted service operated within a company
> that sells offensive cyber services?
>

This particular question is one that I'd very much like to see the program
address officially.  I personally reject the "corporate ethics issue" as
inappropriate to this domain, but I don't really get a vote.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Thu, Mar 7, 2019 at 9:18 AM nadim--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would like to repeat my call for establishing a set of empirical
> requirements that take into account the context of DarkMatter's current
> position in the industry as well as their specific request for the
> inclusion of a specific root CA.


I also concur in this to the extent possible.


> While I don't necessarily fully support the method with which Benjamin
> chose to address Ryan's contributions to the discussion so far, I think
> we're all choosing to kid ourselves here if we continue to say that the
> underlying impetus for this discussion isn't primarily sociopolitical. The
> sooner an end is put to this, the better.
>

I concur in as far as the result, which is to say that I don't necessarily
say that it _is_ "primarily sociopolitical" but rather that there is at
least the appearance and nearly indefensible criticism that it could be.


> The right thing to do, right now, is for there to be a documented process
> through which a set of empirical, falsifiable, achievable requirements are
> set by either Mozilla, the CABForum, or both, for DarkMatter to fulfill so
> that they can be considered for inclusion. If these requirements are (1)
> defined fairly and (2) achieved by DarkMatter verifiably, then great.
> Otherwise, too bad.
>

Indeed the ramifications of a discretionary revocation of the intermediates
or block from joining the root program, if not objectively and cleanly
explained, would likely have a chilling effect on ANY newcomer.  When a
reasonable, documentable, objective path to earning and maintaining trust
in the program exists, investment of time and resources can reasonably
flow.  A new counter-case of an organization that has met all the
requirements and still somehow doesn't meet the bar would be most
discouraging.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ken Myers (personal capacity) via dev-security-policy]

Is the issue that a Dark Matter business unit may influence the Dark Matter 
Trust Services (a separate unit, but part of the same company) to issue 
certificates for malicious purposes? 

or is it a holistic corporate ethics issue (in regards to Mozilla community 
safety) of a Mozilla-trusted service operated within a company that sells 
offensive cyber services?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nadim Kobeissi via dev-security-policy]

On Thu, Mar 7, 2019, 4:29 PM Ryan Sleevi  wrote:

>
> On Thu, Mar 7, 2019 at 10:18 AM nadim--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I think we're all choosing to kid ourselves here if we continue to say
>> that the underlying impetus for this discussion isn't primarily
>> sociopolitical. The sooner an end is put to this, the better.
>>
>
> I don't think it's productive nor charitable to suggest that the
> participants are behaving disingenuously, especially when it's been
> repeatedly highlighted that the concerns are not and have not been
> sociopolitical in nature. This seems unnecessarily dismissive of the
> discussion to date, and likely prevents productive discourse.
>

I'm not at all suggesting that any folks are behaving disingenuously. I'm
just saying that it probably would be useful to admit that at this point,
this discussion has become driven by concerns against Dark Matter that are
largely informed from their previous work, journalistic reporting on said
work, the fact that they're based in the UAE, etc.

This isn't an indicator of disingenuous behavior or anything like that.
It's just distracting from progress and that was my point.


>
>> by either Mozilla, the CABForum, or both
>>
>
> I just want to highlight that the CA/Browser Forum has absolutely no
> relevance to this discussion or matter, nor has it ever. The CA/Browser
> Forum is merely a discussion forum for examining common baseline technical
> requirements. It is not, nor has it ever, been an appropriate place to
> discuss the inclusion, exclusion, or trustworthiness of given entities, and
> has zero bearing whatsoever in the security and policy decisions
> application software vendors may produce.
>

Thanks for clarifying this. I'm regardless still wondering if it would be
better to move forward in the way that I'm proposing: presenting a
documented process through which a set of empirical, falsifiable,
achievable requirements for DarkMatter to fulfill so that they can be
considered for inclusion. If these requirements are (1) defined fairly and
(2) achieved by DarkMatter verifiably, then great. Otherwise, too bad.

You're the expert, Ryan, and so I ask: isn't this the right way to move
forward? How can we pivot in this direction, so that the discussion becomes
more fair and appropriate for all parties?

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 7, 2019 at 10:18 AM nadim--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think we're all choosing to kid ourselves here if we continue to say
> that the underlying impetus for this discussion isn't primarily
> sociopolitical. The sooner an end is put to this, the better.
>

I don't think it's productive nor charitable to suggest that the
participants are behaving disingenuously, especially when it's been
repeatedly highlighted that the concerns are not and have not been
sociopolitical in nature. This seems unnecessarily dismissive of the
discussion to date, and likely prevents productive discourse.


> by either Mozilla, the CABForum, or both
>

I just want to highlight that the CA/Browser Forum has absolutely no
relevance to this discussion or matter, nor has it ever. The CA/Browser
Forum is merely a discussion forum for examining common baseline technical
requirements. It is not, nor has it ever, been an appropriate place to
discuss the inclusion, exclusion, or trustworthiness of given entities, and
has zero bearing whatsoever in the security and policy decisions
application software vendors may produce.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Peter Bowen via dev-security-policy]

On Thu, Mar 7, 2019 at 12:09 AM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda.  Whether in CABForum, or
> Mozilla-dev-security-policy, I represent the viewpoints of my employer
> DarkMatter and passionately believe in our unflagging efforts to provide
> the citizens, residents and visitors to the United Arab Emirates with the
> same internet security and privacy protections that are taken for granted
> in other parts of the world.
>
> On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:
> >  (Writing in a personal capacity)
>
> Until such time as we have been formally advised by your employer
> (Google), that you no longer represent their views in CABForum, or in this
> Mozilla-dev-security-policy forum, we will proceed on the basis that all of
> your statements are the official viewpoint of your employer (Google).
>

Benjamin,

This statement is at odds with how the mozilla.dev.security.policy group
works.  Many people who are active in the Mozilla community, both in this
group and others, do so independently of their employer. I think it is safe
to assume that the majority of people you will meet in the Mozilla
community have paid employment; those employers may or may not be involved
with Mozilla.  When participants make it clear they are writing in a
personal capacity, or when they explicitly state they are representing
their employer, then that is what we as fellow participants should accept.
There is a page on the Mozilla wiki (
https://wiki.mozilla.org/CA/Policy_Participants ) that has a list of common
participants and whether they are speaking for anyone else.

I will not that in this specific email, to be clear, I am writing in a
personal capacity.  I have not discussed this with anyone else at my
employer and my employer may not even agree with what is in this email.  Or
they may. I simply do not know and would have to ask someone who is in a
position to represent my employer to find out.  This is what I mean when I
say I'm writing in a personal capacity.


> sovereign nations have the fundamental right to provide digital services
> to their own citizens, utilizing their own national root, without being
> held hostage by a provider situated in another nation.  You should note
> that DarkMatter's request is also for the inclusion of UAE's national root.
>
> Benjamin Gabriel
> General Counsel
> Dark Matter Group
>
>
> Benjamin Gabriel | General Counsel & SVP Legal
>

I think this is a great example of why it is important to be clear on who
you are speaking for when participating in public groups.  As per
Kathleen's post (which was clear it was posted in her role as a Mozilla
module owner), this discussion is about the subordinate CAs which Dark
Matter operates.  It was my impression that these are operated on a
commercial basis by one of the Dark Matter Group of companies and you are
writing as a representative of the Dark Matter Group.  You then raise that
DarkMatter is also requesting inclusion of the United Arab Emirates
national root.  This would appear to imply that DarkMatter is also acting
as a representative of the Government of the UAE.  We have seen other
governments use privately owned contractors to help operate their national
PKIs and these contractors have participated in the Mozilla groups.

Can you please clarify if you are speaking for Dark Matter as a commercial
entity or if you are speaking for the Government of the UAE?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[nadim--- via dev-security-policy]

I would like to repeat my call for establishing a set of empirical requirements 
that take into account the context of DarkMatter's current position in the 
industry as well as their specific request for the inclusion of a specific root 
CA.

While I don't necessarily fully support the method with which Benjamin chose to 
address Ryan's contributions to the discussion so far, I think we're all 
choosing to kid ourselves here if we continue to say that the underlying 
impetus for this discussion isn't primarily sociopolitical. The sooner an end 
is put to this, the better.

The right thing to do, right now, is for there to be a documented process 
through which a set of empirical, falsifiable, achievable requirements are set 
by either Mozilla, the CABForum, or both, for DarkMatter to fulfill so that 
they can be considered for inclusion. If these requirements are (1) defined 
fairly and (2) achieved by DarkMatter verifiably, then great. Otherwise, too 
bad.

It is my humble belief that any alternative course of action is a further 
descent into distraction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would just like to remind you all the universally accepted concept of
> "Presumption of innocence". Quoting from
> https://en.wikipedia.org/wiki/Presumption_of_innocence:
>
> >The presumption of innocence is the legal principle that one is
> considered innocent unless proven guilty. It was traditionally expressed by
> the Latin maxim ei incumbit probatio qui dicit, non qui negat (“the burden
> of proof is on the one who declares, not on one who denies”).
>
> Where it is useful to highlight the following phrases:
>
> - one is considered innocent unless *proven* guilty
> - the *burden of proof is on the one who declares*, not on one who denies
>
> So, unless MDSP is the jury responsible for proving DM guilty, I think
> they should be accepted until their mischief can be proved, although I'm
> not sure who should/could be responsible for such a task.
>

Thanks for sharing this, Jaime, and thank you for engaging in this
discussion.

Unfortunately, there are a number of flaws with this thinking, which I want
to highlight, although I hope it does not discourage further participation.

As you seem to acknowledge, MDSP is not a jury and this is not a legal
proceeding. On that basis, the application of a "Presumption of Innocence"
is not necessary nor relevant - we're not discussing legal proceedings
here, nor is the goal to assess "guilt" or "innocence". The fundamental
question of a root program is whether or not an organization is trustworthy.

In some ways, you may wish to think of CAs as custodians of a given root
programs' trust, and since we're applying Latin concepts, the phrase "Quis
custodiet ipsos custodes" is perhaps applicable here. The answer is that
the root program supervises the CAs, through consultation with the public.
If it helps to frame this in concepts that may be more familiar - even if
they are far from a perfect match - you might think of this as how officers
of organizations or politicians are held to higher standards, and things
which might be acceptable in the general case are not acceptable for such
parties.

However, I think it's more fundamentally flawed to see the process as
"default trust". The answer is rather the opposite; the default answer is
"do not trust", and it is the CAs duty to provide sufficient evidence to
demonstrate both their trustworthiness and utility to a root program, such
that the vendor is willing to enter into a business relationship with them
and entrust them with protecting the security of their users.

A good example of this principle ("default deny") at play is in the
reliance upon audits. As practiced by WebTrust practitioners, the
professional standards of auditors actually work from a view of assuming
that none of the principles or criteria have been met by the organization.
The organization being audited has a duty to produce and demonstrate
sufficient evidence so as to convince a "reasonable" auditor that the CA is
and has been meeting the various requirements. Using the AICPA as an
example (and similar examples exist for ISAE and CPA Canada and other
professional auditing bodies), you can see this at [1], and in particular,
AT-C 105.10a or 105.25iii.

As noted elsewhere, the programs goals are not necessarily to include any
entity who meets some perfunctory checklist, but to ensure that the
benefits outweigh the risks for the typical user. As such, there is an
inherent burden to highlight the benefits, just as there is a
responsibility to evaluate solutions to mitigate risks, as some have
offered [3]. Going back to legal concepts, as inappropriate for this
discussion as they are, one might say that the "burden of proof" exists
with each CA participating or applying to participate in a given root
program to demonstrate their value and to produce evidence counter to the
claims provided.

My previous message [4] highlighted some approaches that CAs might use to
do that, while also highlighting that, fundamentally, audits alone do not
and have never met that fundamental sufficiency.

I hope that helps explain the flaws in this reasoning, while also
highlighting the standards being applied are well-understood and accepted
concepts.

[1] https://www.aicpa.org/research/standards/auditattest/ssae.html
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/LPCGngLxBwAJ
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/rNWEMEkUAQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[astronut--- via dev-security-policy]

[Writing in a personal capacity, these views do not represent those of my 
employer]

On Wednesday, March 6, 2019 at 7:51:21 AM UTC-8, Ryan Sleevi wrote:
> 
> 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 has been raised several times, somewhat dismissively in this thread, so I 
felt like speaking out.

Setting aside the discussion about DarkMatter specifically, here are some ways 
in which having a CA in a new jurisdiction that isn't currently represented in 
the ecosystem can bring value:
* Allow users to transact business in their normal currency
* Allow users to transact business without international currency usage fees
* A "domestic" CA is far more likely to be able to do business in the local 
language compared to CAs that don't have any presence in a country where that 
language is spoken.
* Many, if not all, subscription agreements have a choice of venue clause in 
them. A "local" CA allows subscribers to ensure the contract is subject to 
their local laws rather than those of a foreign country
* There are many other factors easier to transact business domestically than 
internationally, even with things as benign as contacting the CA by phone or 
mail.

[Further discussion about choice in the marketplace elided to keep this mail 
more on point]

> This is, of course,
> comparable to the domain name system of gTLDs (rather than ccTLDs), which
> is inherently global in nature.

The reasons above might help to explain why 
https://www.icann.org/registrar-reports/accredited-list.html lists almost 2500 
domain registrars in 70 different countries. 

Again, I'm not taking any sort of position on DarkMatter's inclusion request. I 
just want to point out that while more CAs may add risk to the ecosystem, more 
choice for subscribers adds value as well, and the trade-off shouldn't be so 
easily dismissed.

Benjamin
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

I would just like to remind you all the universally accepted concept of 
"Presumption of innocence". Quoting from 
https://en.wikipedia.org/wiki/Presumption_of_innocence: 

>The presumption of innocence is the legal principle that one is considered 
>innocent unless proven guilty. It was traditionally expressed by the Latin 
>maxim ei incumbit probatio qui dicit, non qui negat (“the burden of proof is 
>on the one who declares, not on one who denies”). 

Where it is useful to highlight the following phrases: 

- one is considered innocent unless *proven* guilty 
- the *burden of proof is on the one who declares*, not on one who denies 

So, unless MDSP is the jury responsible for proving DM guilty, I think they 
should be accepted until their mischief can be proved, although I'm not sure 
who should/could be responsible for such a task.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jaime Hablutzel via dev-security-policy]

I would just like to remind you all the universally accepted concept of 
"Presumption of innocence". Quoting from 
https://en.wikipedia.org/wiki/Presumption_of_innocence:

>The presumption of innocence is the legal principle that one is considered 
>innocent unless proven guilty. It was traditionally expressed by the Latin 
>maxim ei incumbit probatio qui dicit, non qui negat (“the burden of proof is 
>on the one who declares, not on one who denies”).

Where it is useful to highlight the following phrases:

- one is considered innocent unless *proven* guilty
- the *burden of proof is on the one who declares*, not on one who denies

So, unless MDSP is the jury responsible for proving DM guilty, I think they 
should be accepted until their mischief can be proved, although I'm sure who 
should/could be responsible for such a task.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Rob Stradling via dev-security-policy]

On 07/03/2019 05:14, Benjamin Gabriel via dev-security-policy wrote:
> Part 1 of 2:
> 
> Dear Ryan,
> 
> A fair and transparent public discussion requires full disclosure of each 
> participant's motivations and ultimate agenda.  Whether in CABForum, or 
> Mozilla-dev-security-policy, I represent the viewpoints of my employer 
> DarkMatter and passionately believe in our unflagging efforts to provide the 
> citizens, residents and visitors to the United Arab Emirates with the same 
> internet security and privacy protections that are taken for granted in other 
> parts of the world.
> 
> On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:
>>   (Writing in a personal capacity)
> 
> Until such time as we have been formally advised by your employer (Google), 
> that you no longer represent their views in CABForum, or in this 
> Mozilla-dev-security-policy forum, we will proceed on the basis that all of 
> your statements are the official viewpoint of your employer (Google).


[Writing in a personal capacity!]

I'd like to remind everyone about the Policy Participants [1] wiki page, 
which is "an optional list of the names, affiliations (if speaking for a 
company) and backgrounds of participants in the 
mozilla.dev.security.policy group".

Since 8th September 2016, this page has included the following text:
"Ryan Sleevi
Peer of the CA Certificates Module; Works for Google; PKI policy for 
Chrome/ChromeOS; Posting in a personal capacity, with posts not 
necessarily representing the views of Google or the Mozilla CA 
Certificate Module, except where otherwise noted."

So Ryan didn't actually need to write "(Writing in a personal 
capacity)", because it would have been implied if he'd omitted it.


I'd also like to remind everyone about the Mozilla Forum Etiquette [2] 
Ground Rules, especially "Be civil" and "Be kind to newcomers".


[1] https://wiki.mozilla.org/CA/Policy_Participants

[2] https://www.mozilla.org/en-US/about/forums/etiquette/

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[James Burton via dev-security-policy]

Benjamin,

There is one theme in all of your responses and it's perfectly clear that
you feel strongly that this discussion as a whole is an attack not only on
DarkMatter's operations but on the United Arab Emirates sovereignty right
to able to have a root included in the Mozilla root store and use of a
non-constrained intermediate. You're constantly framing your responses to
discredit and attack well respected, fair and honest individuals by stating
that they are peddling hidden agenda against DarkMatter and United Arab
Emirates which is clearly false. There motives are to protect Mozilla users
around the world and to do this they are objectively looking at all of the
reports from multiple news organizations, previous and on going discussions
on here and other places to determent if DarkMatter's operations are truly
trustworthy to the highest degree. Remember, money can't
buy trustworthiness it must be earned by showing clearly the true face of
the operations within the organization. Next.

The CAB Forum current and previous ballots and discussions are public
knowledge and by stating that DarkMatter couldn't have known about these
discussions or ballots is porkies. What you are really saying to everyone
is that DarkMatter couldn't be bothered to search though the CAB Forum's
previous discussions and ballots which demonstrates an amateurish operation
at heart. Being a CA is a serious operation and as such they are expected
in the eyes to everyone that should know every policy, every current and
previous ballot, every rfc standard, etc which affect the CA operationally.
Next.

There isn't any monopoly that prevents citizens and organizations in the
United Arab Emirates to get certificates from CAs and they are not
expensive. Let's Encrypt provides free domain validated certificates to
everyone around the world. Next.

Thank you,

Burton

On Thu, Mar 7, 2019 at 9:54 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Mar 07, 2019 at 05:17:07AM +, Benjamin Gabriel via
> dev-security-policy wrote:
> > On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:>
> > >DarkMatter response to the serial number issue has demonstrated
> > >that DarkMatter did not do the expected due diligence to investigate
> > >and understand the issue.
> >
> > Your statement as Google's representative is quite disingenuous and
> > self-serving.  As a new member of the CABForum, we were not privy to the
> > discussions for Ballot 164, and have interpreted the Baseline
> Requirements
> > as they were written.
>
> I explained[1] how repeatedly asking an RNG for a 64-bit number that meets
> certain criteria is not 64 bits of output from said RNG.  Coming to that
> conclusion doesn't require a history lesson.
>
> Making the mistake isn't the real problem, though.  Mistakes happen.  It is
> how the mistake is responded to which is important.  DarkMatter's
> representative persisted in trying to pretend there wasn't a problem when
> there was.  That does not show the sort of openness to improvement which I,
> at least, would prefer to see in a globally-trusted CA.
>
> > >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.
> >
> > I am glad that you brought this up directly with me - and in this public
> > discussion.  Ryan, you have been one of the individuals who have been
> > persistent in spreading this false narrative - as far back as February
> > 2018 - during our initial submission to CABForum.  We have duly noted and
> > have been aware of your persistent attempts to interfere with our
> > contractual relations.  Your employer should know that we have had to
> > expend considerable effort to defend against your back-room politicking,
> > and defamatory innuendos, about the nature of our business.
>
> I'm curious how you think that throwing around veiled threats of legal
> action against one of the more widely-respected members of this community
> is
> going to encourage people to trust your organisation *more*.
>
> - Matt
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/c6HoK97RBQAJ
>
> ___
> 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