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
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
>
Exactly what I was thinking
On 2019-03-07 09:21, Georg Koppen via dev-security-policy wrote:
Benjamin Gabriel via dev-security-policy:
Dear Ryan,
A fair and transparent public discussion requires full disclosure of each
participant's motivations and ultimate agenda.
It would be neat if you
On 2019-03-07 06:14, Benjamin Gabriel via dev-security-policy wrote:
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
Benjamin Gabriel via dev-security-policy:
> Dear Ryan,
>
> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda.
It would be neat if you could tone down your rhetoric a bit and refrain
from ad-hominem attacks. That would help
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
Part 2 of 2
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
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
All,
Thank you to those of you that have been providing thoughtful and
constructive input into this discussion. I have been carefully reading
and contemplating all of the messages posted in the
mozilla.dev.security.policy forum.
As the owner of Mozilla’s CA Certificates Module[1] and in an
(Writing in a personal capacity)
Benjamin,
I've focused only on the substantive new information added to this
discussion relevant to trust. I hope the past messages have highlighted why
much of the message may be fundamentally misunderstanding the purpose of a
root store and the root store
On Tuesday, March 5, 2019 at 7:18:39 PM UTC+1, Ryan Sleevi wrote:
> On Tue, Mar 5, 2019 at 12:11 PM Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> By comparison, the discussion around DarkMatter has been more similar to
> the discussion of Symantec
Dear Selena,
On Wednesday, 6 March 2019 02:58:19 UTC+4, Selena Deckelmann wrote:
>
> I think what you've quoted are accurate statements. That is, recent articles
> raised questions that I, and others, felt were important to bring to this
> public forum to discuss.
>
While we welcome and are
It seems to me that the acceptance of this root can cause great damage to
Mozilla to the future and cause great discussions in the Linux community. Is
Mozilla ready to do all this and lose the support of a large number of users in
the future? In my opinion these are the main issues.
On Friday, February 22, 2019 at 2:21:24 PM UTC-7, Wayne Thayer wrote:
> The recent Reuters report on DarkMatter [1] has prompted numerous questions
> about their root inclusion request [2]. The questions that are being raised
> are equally applicable to their current status as a subordinate CA
Hi!
Just wanted to briefly comment in response to Benjamin Gabriel's statement.
On Tuesday, March 5, 2019 at 7:07:51 AM UTC-8, Benjamin Gabriel wrote:
> Marshal Erwin, director of trust and security for Mozilla, said the Reuters
> Jan. 30 report had raised concerns inside the company that
On Tue, Mar 5, 2019 at 1:58 PM Matthew Hardeman wrote:
> I suppose my initial response to the concern as presented is that it would
> seem to be a fairly trivial (just paperwork, really) matter for DarkMatter
> (or indeed any other applicant) to separate the CA into a fully separate
> legal
On 05/03/2019 16:11, Benjamin Gabriel wrote:
Message Body (2 of 2)
[... continued ..]
Dear Wayne
> ...
Yours sincerely,
Benjamin Gabriel
General Counsel
DarkMatter Group
As an outside member of this community (not employed by Mozilla or any
public CA), I would like to state the
On Tue, Mar 5, 2019 at 12:18 PM Ryan Sleevi wrote:
>
> I believe you may have misunderstood the details of these incidents and
> their relationship to what's currently under discussion.
>
> In the Sectigo + NSO Group, these were entities that shared common
> investment ownership, but otherwise
On Tue, Mar 5, 2019 at 12:11 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Objections to DarkMatter on the sole basis of the actions of a sibling
> business with common owners is dangerous turf to get into, if we care about
> historic precedent.
On Tue, Mar 5, 2019 at 11:10 AM Matthew Hardeman
wrote:
>
> This means there are two recent precedents for which this category of
> issues has not resulted in delegation of trust and one proposal that the
> same category of behaviors should. I am not suggesting that a position
> against
On Tue, Mar 5, 2019 at 8:16 AM Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> You're right, there is no test. That's why some of us believe we should
> look at proxies: such as honesty, considering root membership is ultimately
> about trust. DM has made
Hi Scott,
On Tue, Mar 5, 2019, at 09:02, Scott Rea via dev-security-policy wrote:
>
> • DM has resolved all technical and policy issues raised in the UAE and
> DM Roots submission process on Mozilla list: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
>
> • Since the
I am a non technical person by far and read most of this article. What I am
wondering, is why is there no public CA authority independent of nations
elected by nations such as NATO but global?
___
dev-security-policy mailing list
Message Body (2 of 2)
[... continued ..]
Dear Wayne
Furthermore, it is unfortunate that Mozilla have chosen to reference
categorically misleading articles (and which continue to be recycled on
slow-news days, on an annual basis since 2016) to support the allegation of
“credible evidence”,
Message body (1 of 2)
Mozilla CA Certificate Policy Module Owner
Dear Wayne,
I am writing to provide an official response to the public discussion that you
have initiated, on mozilla.dev.security.policy, in accordance with Article 7,1
of the Mozilla Root Store Policy, on the inclusion of
On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have addressed most if not all of the various technical comments in this
> list in respect to DarkMatter’s Roots submission and it might be helpful if
> I summarize here the raised
I have addressed most if not all of the various technical comments in this
list in respect to DarkMatter’s Roots submission and it might be helpful if I
summarize here the raised Compliance Concerns and Risk of Misuse Concerns:
1. Compliance
Questions have been raised about DarkMatter’s
My perspective is that of an end user and also that of a software developer
involved in a non-web-browser space in which various devices and
manufacturers generally defer to the Mozilla root program's trust store.
As such, I'm quite certain that my opinions don't -- and should not -- have
the
On Mon, Mar 4, 2019 at 9:04 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote:
>
> >
> > It is not clear how this follows. As my previous messages tried to
> > capture, the program is, and has always
On Mon, Mar 4, 2019 at 11:03 AM Matthew Hardeman
wrote:
>
>
> On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote:
>
>>
>> It is not clear how this follows. As my previous messages tried to
>> capture, the program is, and has always been, inherently subjective and
>> precisely designed to support
On Sun, Mar 3, 2019 at 6:13 PM Ryan Sleevi wrote:
>
> It is not clear how this follows. As my previous messages tried to
> capture, the program is, and has always been, inherently subjective and
> precisely designed to support discretionary decisions. These do not seem to
> inherently conflict
On Mon, Mar 4, 2019 at 3:29 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Writing with my personal hat on:
>
>
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> Im Auftrag von Matthew Hardeman via dev-security-policy
> > On Sun,
On Sun, Mar 3, 2019 at 5:54 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > Insane that this is even being debated. If the
On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Insane that this is even being debated. If the floodgates are opened here
> you will NOT be able to get things back under control.
>
While I can appreciate the passion of
On Friday, February 22, 2019 at 2:21:24 PM UTC-7, Wayne Thayer wrote:
> The recent Reuters report on DarkMatter [1] has prompted numerous questions
> about their root inclusion request [2]. The questions that are being raised
> are equally applicable to their current status as a subordinate CA
I have removed these malicious certificates from firefox and Windows machine
and contacted various Anti-Virus companies requesting they mark these
certificates as malicious in their scans. I suggest others do the same! Thank
you for bringing this to my attention.
On Thu, Feb 28, 2019 at 7:31 PM Matthew Hardeman
wrote:
> Regarding program policy as it now stands, it is not unreasonable to
> arrive at a position that the root program would be better positioned to
> supervise and sanction DarkMatter as a member Root CA than as a trusted
> SubCA. For
I wanted to take a few moments to say that I believe that Ryan Sleevi's
extensive write-up is one of the most meticulously supported and researched
documents that I've seen discuss this particular aspect of trust delegation
decisions as pertains to the various root programs. It is an incredible
(Writing in a personal capacity)
I want to preemptively apologize for the length of this message. Despite
multiple rounds of editing, there's still much to be said, and I'd prefer
to say it in public, in the spirit of those past discussions, so that they
can be both referred to and (hopefully)
While I was going to respond to the below, Nick Lamb has beaten me to it.
I concur in full with the remarks in that reply.
We should not be picking national favorites as a root program. There's a
whole world out there which must be supported.
What we should be doing is ensuring that we know the
On Wed, 27 Feb 2019 09:30:45 -0500
Alex Gaynor via dev-security-policy
wrote:
> Finally, I think there's a point that is very much being stepped
> around here. The United States Government, including its intelligence
> services, operate under the rule of law, it is governed by both
> domestic
(Writing in my personal capacity)
On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
[...]
> All of Google, Amazon, and Microsoft are in the program. All of these have
> or had significant business with at least the US DOD
G’day Folks,
I want to thank Ryan for sharing the relevant discussion history regarding the
change that precipitated the current language for serialNumber entropy in the
BRs. Based on this background, it is clear to DM what is required for expected
compliance with this control and that this
> (Sorry for continuing this off-topic thread.)
>
> Hello Tomas,
>
> I hope this is indeed not your current implementation and that it wasn’t in
> use anymore when ballot 164 became effective, because that’s not safe:
I tried to say so in my original post, but I see I was not very clear.
tomasshredder--- via dev-security-policy
writes:
>We still get asked by customers to implement sequential serial numbers from
>time to time, but it's getting more and more rare.
Another reason for using random data, from the point of view of a software
toolkit provider, is that it's the only
On 27 Feb 2019, at 09:07, tomasshredder--- via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
Mike Kushner via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
writes:
On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
> Mike Kushner via dev-security-policy
> writes:
>
> >EJBCA was possible the first (certainly one of the first) CA products to use
> >random serial numbers.
>
> Random serial numbers have been in use for a long, long
As Matthew highlights, this is not a new or novel interpretation.
It was introduced in Ballot 164 -
https://cabforum.org/2016/03/31/ballot-164/
The first discussion of this in the CA/B Forum as a Ballot was
https://cabforum.org/pipermail/public/2016-February/006893.html . This
discussion
The issue I see with that interpretation is that the very same matter has
previously been discussed on this list and resolved quite vocally in the
favor of the other position: that making careful choices about the CSPRNG
output to conform it to mask out the high order bit makes the output of at
G’day Wayne et al,
I am not sure why members of the group keep making the claim that these
certificates are misused under the BRs.
Corey pointed to the following paragraph in Section 7.1 of the BRs as the
source of the control that DM is accused of not complying with:
“Effective September 30,
Mike Kushner via dev-security-policy
writes:
>EJBCA was possible the first (certainly one of the first) CA products to use
>random serial numbers.
Random serial numbers have been in use for a long, long time, principally to
hide the number of certs a CA was (or wasn't) issuing. Here's the
I'd like to take a moment to point out that determination of the beneficial
ownership of business of various sorts (including CAs) can, in quite a
number of jurisdictions, be difficult to impossible (short of initiating
adverse legal proceedings) to determine.
What does this mean for Mozilla's
Le mardi 26 février 2019 16:35:11 UTC+1, Hanno Böck a écrit :
> This statement repeats the claim that you wrote here previously,
> specifically:
> "I want to assure you that DarkMatter's work is solely focused on
> defensive cyber security, secure communications and digital
> transformation."
>
>
On Sat, Feb 23, 2019 at 06:51:11AM -0800, alex.gaynor--- via
dev-security-policy wrote:
> (Writing in my personal capacity)
I'm writing in my personal capacity, as much as possible, as well (I am
a Tor/Tor Browser developer).
>
> One of the things that I think is important is to tease out
Thanks for the clarification.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Scott,
On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> G’day folks,
>
> we appreciate the many suggestions made on the list to strengthen the
> entropy of random serialNumbers.
>
> One challenge we face currently is that our
This statement repeats the claim that you wrote here previously,
specifically:
"I want to assure you that DarkMatter's work is solely focused on
defensive cyber security, secure communications and digital
transformation."
The statement does not comment on the Reuters article, but it is in
stark
On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote:
Hi Scott. It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.
Direct link:
On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote:
> G’day Folks,
>
> DarkMatter CEO (Karim Sabbagh), has provided an official response to
> Mozilla on the recent media article about the UAE that referenced
> security and intelligence matters. Per Wayne’s request to
Hi Scott. It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.
Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699
On
So then every cert signed by the keys intended for the trust store will be
CT logged?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Hi,
Since EJBCA as a product was mentioned we thought we could chime in with some
background and updates.
EJBCA was possible the first (certainly one of the first) CA products to use
random serial numbers. From the very beginning, 64 bit random serial numbers,
from a CSPRNG, were used. This
G’day Folks,
DarkMatter CEO (Karim Sabbagh), has provided an official response to Mozilla on
the recent media article about the UAE that referenced security and
intelligence matters. Per Wayne’s request to potentially share this on the
list, I am attaching a copy of that letter to this post.
store or copy the information in any medium and for whatever purpose. Any
unauthorized use is strictly prohibited.
From: Richard Salz
Date: Tuesday, February 26, 2019 at 5:31 PM
To: Scott Rea
Cc:
Subject: Re: DarkMatter Concerns
So then every cert signed by the keys intended for the
G’day Rich,
DM has submitted Roots intended for Public Trust to Mozilla and other browser
operators, but we also operate private trust PKIs under separate anchors. These
private PKIs also issue certificates to secure TLS in closed environments, but
Private Roots are not in public CT Logs and
G’day folks,
we appreciate the many suggestions made on the list to strengthen the entropy
of random serialNumbers.
One challenge we face currently is that our platform (which does support higher
entropy) but only supports this at a global level. So if we make a global
change, then ALL our
: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, February 25, 2019 1:43 PM
To: Buschart, Rufus ;
mozilla-dev-security-policy
Subject: RE: DarkMatter Concerns
Hi all,
Sorry for the delayed response. Been traveling and haven't had a chance to
properly format
If DarkMatter is issuing from a CA that chains to a Quovadis root trusted by
Mozilla, the issuance is in scope of the Mozilla policy. But that also
means the cert is publicly trusted. Thus, I read it as "all TLS certs issued
from the public ICA are publicly logged", which matches what Scott told
.
Jeremy
-Original Message-
From: dev-security-policy On
Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, February 25, 2019 9:53 AM
To: Nick Lamb ; dev-security-policy@lists.mozilla.org
Cc: Kurt Roeckx
Subject: Re: DarkMatter Concerns
On 25/02/2019 16:17, Nick Lamb via dev
On Mon, Feb 25, 2019 at 12:15 PM Richard Salz wrote:
> You miss the point of my question.
>
> What types of certs would they issue that would NOT expect to be trusted
> by the public?
>
>>
>>>
I get the question in principle. If it is a certificate not intended for
public trust, I suppose I
The answer to the question of what certificates they intend to CT log or
not may be interesting as a point of curiosity, but the in-product CT
logging requirements of certain internet browsers (Chrome, Safari) would
seem to ultimately force them to CT log the certificates that are intended
to be
Apart from the concerns others have already raised, I am bothered by the
wording of one of the Dark Matter commitments, which says that "TLS certs
intended for public trust" will be logged. What does public trust mean? Does
it include certificates intended only for use within their country?
On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
> wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
>
> Two other things would be
On Sat, 23 Feb 2019 10:16:27 +0100
Kurt Roeckx via dev-security-policy
wrote:
> I would also like to have a comment from the current root owner
> (digicert?) on what they plan to do with it.
Two other things would be interesting from Digicert on this topic
1. To what extent does DarkMatter
There are other ways to achieve a guarantee of non-collision besides
re-generating. For example, we incorporate the timestamp of issuance into the
serial number alongside the random bits. You could also incorporate a
sequential value into your serial number. Both methods serve to guarantee
On 25/02/2019 11:42, Scott Rea wrote:
G’day Paul,
I cannot speak for other CAs, I can only surmise what another CA that is as
risk intolerant as we are might do. For us, we will collision test since there
is some probability of a collision and the test is the only way to completely
mitigate
G’day Paul,
I cannot speak for other CAs, I can only surmise what another CA that is as
risk intolerant as we are might do. For us, we will collision test since there
is some probability of a collision and the test is the only way to completely
mitigate that risk.
There is a limitation in our
Hi Scott,
Comments inline.
On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:
G’day Corey,
To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from
G’day Corey,
To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in the
serialNumber is to generate the required output and then test it to see if it
can be a valid serialNumber. If it is not a valid
Matt Palmer via dev-security-policy
writes:
>Imagine if a CA said "we generate a 64-bit serial by getting values from the
>CSPRNG repeatedly until the value is one greater than the previously issued
>certificate, and use that as the serial number.".
Well, something pretty close to that works
On Mon, Feb 25, 2019 at 02:11:40AM +, Scott Rea via dev-security-policy
wrote:
> My anticipation is that what happens is that CSPRNG process is repeated
> until a positive INTEGER is returned. In which case a 64-bit output from
> a CSPRNG is contained in the serialNumber as is required.
G’day Corey,
I can see your point – perhaps the more accurate way explicitly allowed under
5280 would have been to encode the constraint as type uniformResourceIdentifier
rather than the type dNSName that was used.
I don’t recall if we actually tried that in our tests at the time with QV, but
G’day Corey,
I am not sure if the phrase “…outputting 64 random bits from the CSPRNG and
then coercing the most significant bit to 0” is actually an accurate
representation of what is happening under the covers – we have asked for
clarification from the developers so we can all have an
On Sunday, February 24, 2019 at 8:05:10 PM UTC-5, Scott Rea wrote:
> G’day Corey,
>
> In respect to the previously issued constrained intermediates – can you
> clarify where in RFC5280 Section 4.2.1.10 that the prohibition against a
> leading period is specified for the name constraints?
> I
On Sunday, February 24, 2019 at 7:39:34 PM UTC-5, Scott Rea wrote:
> G’day Corey,
>
> I did not check your math, but is it possible that you are interpreting the
> serial number conversion output as an unsigned integer representation? If so,
> then I can understand your potential concern
G’day Corey,
In respect to the previously issued constrained intermediates – can you clarify
where in RFC5280 Section 4.2.1.10 that the prohibition against a leading period
is specified for the name constraints?
I see in the RFC the specific sentence: “When the constraint begins with a
G’day Corey,
I did not check your math, but is it possible that you are interpreting the
serial number conversion output as an unsigned integer representation? If so,
then I can understand your potential concern regarding the findings of your
analysis.
DarkMatter uses an EJBCA platform with
On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective September
> 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers
> greater than zero (0) containing at least 64 bits of output from
This certificate already infested all major browsers. Removing it breaks a lot
of pages and gives you Invalid certificate error.
TOR, Chrome, Firefox... all infested.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Op zaterdag 23 februari 2019 20:38:51 UTC schreef Todd Troxell:
> IDK this seems like an obvious one to me. Let them find another way. We don't
> have to make it easy.
>
> -Todd
It should also be noted DarkMatter has very strong ties with the UAE government
and operates the UAE national PKI
This seems like an absolute no-brainer to me. DarkMatter's past behavior and
line of business are fundamentally incompatible with the level of trust reposed
in CA's. This is not even a close call. I believe Mozilla should:
1. Deny the root inclusion request;
2. Add the intermediate CA
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
G’day Kurt,
DarkMatter has several business units that focus on a broad range of cyber
security activities. The Trust Services BU is responsible for the DarkMatter CA
and primarily focused on enabling secure communications and digital
transformation. We utilize the services of other DM BU’s
IDK this seems like an obvious one to me. Let them find another way. We don't
have to make it easy.
-Todd
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
(Writing in my personal capacity)
One of the things that I think is important is to tease out factual predicates
that could be grounds for exclusion. It's clear to me that there is a
tremendous level of unease with DarkMatter, largely (though not exclusively!)
as a result of the Reuter's
On Sat, Feb 23, 2019 at 02:07:38PM +0400, 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
On Friday, February 22, 2019 at 10:21:24 PM UTC+1, Wayne Thayer wrote:
> 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.
So, basing the trust of a CA on "suggestion"
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
On Fri, Feb 22, 2019 at 03:45:39PM -0800, cooperq--- via dev-security-policy
wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged
> > involvement with hacking campaigns is incompatible
On Friday, February 22, 2019 at 6:51:52 PM UTC-5, coo...@gmail.com wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged
> > involvement with hacking campaigns is incompatible with
101 - 200 of 202 matches
Mail list logo
