Re: DarkMatter CAs in Google Chrome and Android

[Scott Rea via dev-security-policy]

G’day Devon et al,

It would appear that Chrome has implemented distrust of the UAE NPKI 
intermediates immediately - can you please explain the rationalization for this 
decision?

These intermediates have been operating without issue for a few years now, what 
was the rationale for immediate distrust without giving DigitalTrust the 
opportunity to contact customers about the need to update site certificates? 
This is extremely distruptive and has left all public trust customers 
inoperable unless their customers swap to a browser other than Chrome.

Can you please outline the justification behind this?

Regards,
-Scott

Sent from my iPhone


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.


> On Jul 24, 2019, at 10:42 AM, Scott Rea via dev-security-policy 
>  wrote:
>
> Caution: This email originated from outside DarkMatter. Do not click links or 
> open attachments unless you recognize the sender and believe the content is 
> safe.
>
> --
>
> G’day Devon et al,
>
> Can you please detail the reason behind Google withdrawing trust for the UAE 
> NPKI intermediates?
> Can you also please provide the timeline for the in-band delivery of the 
> restriction by Google? As you can imagine this will have catastrophic impact 
> for existing customers and we would like to provide them a reasonable plan to 
> manage the transition.
>
> As you are aware, DarkMatter and DigitalTrust have appealed the decision by 
> Mozilla on the basis of multiple elements which have also be published to the 
> list. Has the appeal or any of the points at the heart of that appeal been 
> taken into account in this decision by Google?
>
> Regards,
> -Scott
>
> On 7/23/19, 11:02 PM, "dev-security-policy on behalf of Devon O'Brien via 
> dev-security-policy"  of dev-security-policy@lists.mozilla.org> wrote:
>
>(Writing on behalf of Google Chrome and Android)
>
>On behalf of Google Chrome and Android, we would like to thank the 
> participants that have contributed to the discussion on the broader M.D.S.P 
> thread on this topic. We will be taking similar steps to those proposed by 
> Wayne and approved by Kathleen, in that we will be removing trust in the 
> DarkMatter-operated intermediates across Google Chrome and Android and we 
> will not be including DarkMatter’s proposed new root certificates. We 
> anticipate these changes will be delivered via our existing in-band delivery 
> mechanisms to clients and require no user action.
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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 CAs in Google Chrome and Android

[Scott Rea via dev-security-policy]

G’day Devon et al,

Can you please detail the reason behind Google withdrawing trust for the UAE 
NPKI intermediates?
Can you also please provide the timeline for the in-band delivery of the 
restriction by Google? As you can imagine this will have catastrophic impact 
for existing customers and we would like to provide them a reasonable plan to 
manage the transition.

As you are aware, DarkMatter and DigitalTrust have appealed the decision by 
Mozilla on the basis of multiple elements which have also be published to the 
list. Has the appeal or any of the points at the heart of that appeal been 
taken into account in this decision by Google?

Regards,
-Scott

On 7/23/19, 11:02 PM, "dev-security-policy on behalf of Devon O'Brien via 
dev-security-policy"  wrote:

(Writing on behalf of Google Chrome and Android)

On behalf of Google Chrome and Android, we would like to thank the 
participants that have contributed to the discussion on the broader M.D.S.P 
thread on this topic. We will be taking similar steps to those proposed by 
Wayne and approved by Kathleen, in that we will be removing trust in the 
DarkMatter-operated intermediates across Google Chrome and Android and we will 
not be including DarkMatter’s proposed new root certificates. We anticipate 
these changes will be delivered via our existing in-band delivery mechanisms to 
clients and require no user action.


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











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

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

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

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

[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

[Scott Rea via dev-security-policy]

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 compliance and I want to again 
emphasize that we have a proven compliance and clean record in the three years 
of operations and have been through two complete web trust audits that have 
verified that we are operating within industry standards.

•   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 inception of the DM CA we have had two technical compliance 
issues during its three years of operation, both were addressed immediately and 
resolved.

•   The first was that DM misissued 2 TLS certificates that were not in 
compliance with the BRs as reported by Rob Stradling - specifically the FQDN 
listed in the CN was not also included in the SAN. The 2 offensive certs were 
already flagged by DM and were held and revoked and were only in existence for 
approximately 18hrs and at NO TIME were they LIVE on the internet protecting 
any services. They were promptly replaced by properly attributed BR-compliant 
certificates. Comment 31 of the UAE and DM Root inclusion Bug is where the two 
misissued certs were documented see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262

•   The second was the serialNumber entropy raised by Corey Bonnell, this 
amounted to an interpretation of the BRs standards that was known to CAs 
following the time of Ballot 164, whereas DM interpreted the BRs as they are 
written. DM was not privy to the discussions around Ballet 164 and the 
subsequent community discussions. DM analyzed the BRs post Ballot 164 and 
concluded based on the definition in Section 7.1, that our platform was 
compliant with the BRs. This continued to be our position until Ryan Sleevi 
posted historical data regarding the interpretations provided to other CAs 
after the adoption of Ballet 164. At this point DM took the decision to align 
with the general community interpretation of Section 7.1 (which up to that 
point was not known to us). It was not a bug originally, our platform was 
compliant at the time it was introduced. The update to the BRs appears to have 
lost some specificity in its re-wording which existing CAs knew about at the 
time, but any new CAs coming after the change may not make the same conclusion 
without the benefit of the background information. All public trust TLS certs 
issued by DM have now been replaced and the platform updated as documented in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 
NOTE: The Roots and Issuing CAs have not yet been re-issued at this time, 
awaiting availability of WT Audit staff. There is also an open question on MDSP 
group about the necessity to re-issue the Roots.

It’s evident from the above that DM has expeditiously addressed any issues 
raised and Mozilla has already said that there is no direct evidence of 
misissuance by DarkMatter. We have adhered to the rules and satisfied all 
technical criteria to be included. And we operate entirely transparently, 
providing all our public trust TLS certificates to CT logs so that anyone can 
see all the certificates that were issued over time and in this way, DarkMatter 
goes beyond required standards.

2.  Risk of Misuse

I also find it extremely troubling that speculation by members on this list has 
far exceeded the bounds of reality. 

Claim:  DM certifications could be issued to malicious actors who could then 
impersonate legitimate websites.  

Response:   
•   DM does not issue certificates that can be used for MITM as stated in 
our published policies which we are audited against.  

•   There is no test that we’re aware of that allows us to ascertain 
someone’s malicious intent in the future and if we find any misuse of a 
certificate in this regards we revoke it immediately. We are willing to engage 
in a dialogue with the industry on how to minimize the probability of malicious 
actors and willingly subscribe to the industry consensus on this.

Referenced claim: outlandish claims of DM being able to decrypt all its 
customers’ data if granted Root acceptance in Mozilla. 

Response:   
•   As everybody here knows, this is entirely ludicrous as commercial CAs 
never hold customer’s private keys and therefore are incapable of doing this.

I’m disappointed that when I started this journey for inclusion of our Roots, 
that the process was clearly defined in terms of compliance and controls, but 
the process now appears to have devolved into dealing with the sort of wild 
speculation we are now experiencing.


Regards,
 
-- 

Scott Rea

 


 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 417 1417 | 

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Scott Rea via dev-security-policy]

Thanks Ryan!

Honestly I would prefer things to be clean, but obviously new Root ceremonies 
also come at a significant cost...

I am happy to be guided by Kathleen and Co on this to ensure the community 
standards are maintained without playing favorites.

But if it becomes necessary for the community to consider past incidents while 
considering our case, then it would surely be a service to have such data 
available.

I am very grateful for your offer of assistance, and for the previous data 
points you also provided that gave us a better understanding of community 
consensus that was not apparent from reading the BRs.

Regards,
-Scott

Sent from my iPhone


Scott Rea
Senior Vice President - Trust Services

[cid:image59a03a.PNG@a459c918.459fb124]<http://www.darkmatter.ae>

Level 15, Aldar HQ
Abu Dhabi, United Arab Emirates
T  +971 2 417 1417
M +971 52 847 5093
E  scott@darkmatter.ae<mailto:scott@darkmatter.ae>

darkmatter.ae<http://darkmatter.ae>

[Linkedin]<https://www.linkedin.com/company/dark-matter-llc> [Twitter] 
<https://twitter.com/GuardedbyGenius>
 [Year of Zayed]  [expo]



The information in this email is intended only for the person(s) or entity to 
whom it is addressed and may contain confidential or privileged information. If 
you receive this email by error, please notify us immediately, delete the 
original message and do not disclose the contents to any other person, use or 
store or copy the information in any medium and for whatever purpose. Any 
unauthorized use is strictly prohibited.

On Mar 3, 2019, at 11:58 PM, Ryan Sleevi 
mailto:r...@sleevi.com>> wrote:

This is a question for Kathleen, as Module Owner.

In the past, CAs which have had BR violations in their root certificates - such 
as negative serial numbers, improper DER encodings, or RFC5280 violations (such 
as keyUsages) - have been required to create new roots before inclusion 
progresses. There have also been a few exceptions, depending on the nature of 
the non-compliance.

Please let me know if it would be helpful to dig up those past incidents for 
such examples.

On Sun, Mar 3, 2019 at 2:47 PM Scott Rea via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
G’day Folks,

we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with the 
latest actions taken by DarkMatter

A question I am posing to this list relates to the trust anchors produced with 
64-bit serial numbers...

A Root certificate is included by explicit trust, and therefore pre-image 
attacks (which is what the increased randomness in serialNumber is meant to 
mitigate) do not apply. As such, is it still necessary to create new Root 
certificates to update serialNumber for submission to Mozilla?

Regards,


--

Scott Rea

On 3/1/19, 8:23 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy" 
mailto:dev-security-policy-boun...@lists.mozilla.org>
 on behalf of 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

Thank you for the detailed incident report Scott. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue,
and attributed it to QuoVadis as the responsible root CA program member.

On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <

dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

> This incident report relates to the 64-bit serial numbers in all
> certificates that DarkMatter CAs have issued since their inception.  The
> dialog surrounding CABF Ballot 164 “Certificate Serial Number Entropy” was
> unknown to DarkMatter until shared with us recently by Ryan Sleevi of
> Google, and demonstrated to DM that the industry expected at least 64-bits
> of entropy in resulting serialNumbers despite the actual wording of the 
BRs
> Section 7.1.
>
> 1. How your CA first became aware of the problem (e.g. via a problem
> report submitted to your Problem Reporting Mechanism, a discussion in
> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
> the time and date.
>
> A post by Corey Bonnell to the mozilla.dev.security.policy group on
> February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the
> Baseline Requirements and the specific sentence he believed DM was
> violating: “Effective September 30, 2016, CAs SHALL generate 
non-sequential
> Certificate serial numbers greater than zero (0) containing at least 64
> bits of output from a CSPRNG”. Corey also listed 23 certificates (CAs &
> EE’s) and their serialNumbers as evidence. Corey followed this up 2 days
> later with a more comprehensive list that included DMs pre-certs and final
> certs published to various CT 

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Scott Rea via dev-security-policy]

G’day Folks,

we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with the 
latest actions taken by DarkMatter

A question I am posing to this list relates to the trust anchors produced with 
64-bit serial numbers...

A Root certificate is included by explicit trust, and therefore pre-image 
attacks (which is what the increased randomness in serialNumber is meant to 
mitigate) do not apply. As such, is it still necessary to create new Root 
certificates to update serialNumber for submission to Mozilla?

Regards,
 

-- 

Scott Rea

On 3/1/19, 8:23 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy"  wrote:

Thank you for the detailed incident report Scott. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue,
and attributed it to QuoVadis as the responsible root CA program member.

On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This incident report relates to the 64-bit serial numbers in all
> certificates that DarkMatter CAs have issued since their inception.  The
> dialog surrounding CABF Ballot 164 “Certificate Serial Number Entropy” was
> unknown to DarkMatter until shared with us recently by Ryan Sleevi of
> Google, and demonstrated to DM that the industry expected at least 64-bits
> of entropy in resulting serialNumbers despite the actual wording of the 
BRs
> Section 7.1.
>
> 1. How your CA first became aware of the problem (e.g. via a problem
> report submitted to your Problem Reporting Mechanism, a discussion in
> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
> the time and date.
>
> A post by Corey Bonnell to the mozilla.dev.security.policy group on
> February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the
> Baseline Requirements and the specific sentence he believed DM was
> violating: “Effective September 30, 2016, CAs SHALL generate 
non-sequential
> Certificate serial numbers greater than zero (0) containing at least 64
> bits of output from a CSPRNG”. Corey also listed 23 certificates (CAs &
> EE’s) and their serialNumbers as evidence. Corey followed this up 2 days
> later with a more comprehensive list that included DMs pre-certs and final
> certs published to various CT Logs.  Corey also pointed out a second issue
> in respect to nameConstrained intermediates issued by Quo Vadis to DM as
> also a potential violation, but this shall be dealt with in a separate
> incident report, since DM was not the issuer of these ICAs. Corey’s second
> post was received on the list at 12:50am UAE time February 25, 2019.
>
> 2. A timeline of the actions your CA took in response. A timeline is a
> date-and-time-stamped sequence of all relevant events. This may include
> events before the incident was reported, such as when a particular
> requirement became applicable, or a document changed, or a bug was
> introduced, or an audit was done.
>
> 29-Apr-16:  DM having previously engaged with QuoVadis for the
> establishment of a National PKI utilizing a platform and hardware that
> would initially be located in QV DCs, held key ceremonies for Private PKIs
> on EJBCA platform. Platform was configured for random 64-bit serialNumbers
> which at the time was considered far in excess of the then current BR
> requirement of 20-bit entropy.
> 30-Apr-16: QV creates DM intermediates intended for issuance of EV and OV
> public trust TLS. These intermediates are instantiated in separate
> partitions to the DM Private Trust PKIs, but issuance from them is still
> subject to the same platform setting of 64-bit random serialNumbers.
> 08-Jul-16: CABF Ballot 164 closes and passes. The phrase Corey highlighted
> above is added in place of the previous 20-bit entropy statement.
> 28-Mar-17: Transition of DM private PKIs and platform to DM DC’s is
> complete under supervision of EY as WebTrust Auditors. Public Trust CAs
> continue to operate out of QV DCs.
> 08-Jun-17: DM Point In Time Audit is complete. NOTE: DM is now responsible
> for platform configuration in compliance with BRs. DM considers current
> serialNumber setting of platform (64-bit SNs) as compliant with BRs 
Section
> 7.1
> 27-Oct-17: DM successfully completes WebTrust Period In Time.
> 04-Nov-17: QV & DM complete transfer of DM public trust intermediates from
> QV to DM under EY & KMPG audit observation
> 18-Dec-17: DM & UAE Roots submitted to Mozilla
> 02-Oct-18: DM successfully completes 2nd WebTrust Audit
> 

Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Scott Rea via dev-security-policy]

This incident report relates to the 64-bit serial numbers in all certificates 
that DarkMatter CAs have issued since their inception.  The dialog surrounding 
CABF Ballot 164 “Certificate Serial Number Entropy” was unknown to DarkMatter 
until shared with us recently by Ryan Sleevi of Google, and demonstrated to DM 
that the industry expected at least 64-bits of entropy in resulting 
serialNumbers despite the actual wording of the BRs Section 7.1.

1. How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.

A post by Corey Bonnell to the mozilla.dev.security.policy group on February 
23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the Baseline 
Requirements and the specific sentence he believed DM was violating: “Effective 
September 30, 2016, CAs SHALL generate non-sequential Certificate serial 
numbers greater than zero (0) containing at least 64 bits of output from a 
CSPRNG”. Corey also listed 23 certificates (CAs & EE’s) and their serialNumbers 
as evidence. Corey followed this up 2 days later with a more comprehensive list 
that included DMs pre-certs and final certs published to various CT Logs.  
Corey also pointed out a second issue in respect to nameConstrained 
intermediates issued by Quo Vadis to DM as also a potential violation, but this 
shall be dealt with in a separate incident report, since DM was not the issuer 
of these ICAs. Corey’s second post was received on the list at 12:50am UAE time 
February 25, 2019.

2. A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.

29-Apr-16:  DM having previously engaged with QuoVadis for the establishment of 
a National PKI utilizing a platform and hardware that would initially be 
located in QV DCs, held key ceremonies for Private PKIs on EJBCA platform. 
Platform was configured for random 64-bit serialNumbers which at the time was 
considered far in excess of the then current BR requirement of 20-bit entropy.
30-Apr-16: QV creates DM intermediates intended for issuance of EV and OV 
public trust TLS. These intermediates are instantiated in separate partitions 
to the DM Private Trust PKIs, but issuance from them is still subject to the 
same platform setting of 64-bit random serialNumbers.
08-Jul-16: CABF Ballot 164 closes and passes. The phrase Corey highlighted 
above is added in place of the previous 20-bit entropy statement.
28-Mar-17: Transition of DM private PKIs and platform to DM DC’s is complete 
under supervision of EY as WebTrust Auditors. Public Trust CAs continue to 
operate out of QV DCs.
08-Jun-17: DM Point In Time Audit is complete. NOTE: DM is now responsible for 
platform configuration in compliance with BRs. DM considers current 
serialNumber setting of platform (64-bit SNs) as compliant with BRs Section 7.1
27-Oct-17: DM successfully completes WebTrust Period In Time.
04-Nov-17: QV & DM complete transfer of DM public trust intermediates from QV 
to DM under EY & KMPG audit observation
18-Dec-17: DM & UAE Roots submitted to Mozilla
02-Oct-18: DM successfully completes 2nd WebTrust Audit
06-Nov-18: DM submits new WebTrust Audits to Mozilla
23-Feb-19: 1:28am: Corey posts to MDSP claiming DM has mis-issuance of certs 
due to BRs Section 7.1
23-Feb-19: 3:36am: Post is observed by DM, internal investigation requested 
immediately.
23-Feb-19: 6:14pm: Internal investigation confirms 64-bit setting for all 
certificates, certlint/cablint/zlint do not complain about certs submitted with 
this setting. Confirm that settings appear to be compliant with BRs. Further 
validation sought from platform provider, support ticket opened.
25-Feb-19: 12:50am: Second email from Corey with expanded list of pre-certs and 
issued certs is posted to MDSP
25-Feb-19: 5:08am: Response posted to Corey on MDSP regarding DM’s 
investigation and the conclusion that DM is in compliance with BRs Section 7.1. 
NOTE: over next two days several folks weigh in on the 64-bit entropy vs 64-bit 
CSPRNG output wording of BRs and what that means.
26-Feb-19: 7:41pm: Wayne Thayer posts to MSDP that 64-bit serialNumber with 
63-bit entropy are mis-issued under the BRs.
27-Feb-19:10:55am: DM responds to Wayne reiterating our position of compliance 
since BRs only say 64-bit output from a CSPRNG and do not say anything about 
entropy. However, DM commits to make a move to 128-bit serialNumbers from a 
CSPRNG in next change control to seek to alleviate concerns. More discussion 
continues on the list.
27-Feb-19: 11:55am: Ryan Sleevi posts historical data/discussions links to MDSP 
regarding the change resulting from Ballet 164 that 

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

is.  But that probably
> will do you no favors as to public perception at a time point when your
> request for inclusion is at a crucial phase.
>
    > On Wed, Feb 27, 2019 at 12:56 AM Scott Rea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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, 2016, CAs SHALL generate non-sequential
> > Certificate serial numbers greater than zero (0) containing at least 64
> > bits of output from a CSPRNG.”
> >
> > DarkMatter has responded to show that we have actually followed this
> > requirement exactly as it is written. Furthermore, since there seems to
> be
> > a number of folks on the Group that believe more stringent controls are
> > needed, DM has agreed to move all its public trust certificates to 
random
> > serialNumbers with double the required entropy following our next change
> > control in the coming week.
> >
> > It is not a requirement of Section 7.1 that serialNumber contain random
> > numbers with 64-bit entropy – which appears to be the claim you are
> making.
> > If this was the intention of this section in the BRs then perhaps we can
> > propose such a change to the BRs. perhaps something like the following
> > could be proposed:
> >
> > “Effective September 30, 2016, CAs SHALL generate non-sequential
> > Certificate serial numbers greater than zero (0) and output from a 
CSPRNG
> > such that the resulting serialNumber contains at least 64 bits of
> entropy.”
> >
> > However, once again, I want to reiterate the current practice of DM for
> > the public trust certificates that we have generated to date:
> > 1. all serial numbers are non-sequential;
> > 2. all serial numbers are greater than zero;
> > 3. all serial numbers contain at least 64 bits of output from a CSPRNG
> >
> > As such, all DM certificates that Corey specifically highlighted were
> > issued in compliance with the BRs and specifically in compliance with
> > Section 7.1 that Corey quoted.
> >
> > If there is another requirement in the BRs in respect to serial numbers
> > where it states that they must contain 64 bits of entropy then can you
> > please point this out?
> >
> >
> > Regards,
> >
> > --
> >
> > Scott Rea
> >
> > On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via
> > dev-security-policy"  > behalf of dev-security-policy@lists.mozilla.org> wrote:
> >
> > >I assume you are referring to those certificates containing a 
serial
> > number with effectively 63-bits of entropy? They are misissued. BR
> > section
> > 4.9.1.1 provides guidance.
> >
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >  

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 copi

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

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, 2016, CAs SHALL generate non-sequential Certificate 
serial numbers greater than zero (0) containing at least 64 bits of output from 
a CSPRNG.”

DarkMatter has responded to show that we have actually followed this 
requirement exactly as it is written. Furthermore, since there seems to be a 
number of folks on the Group that believe more stringent controls are needed, 
DM has agreed to move all its public trust certificates to random serialNumbers 
with double the required entropy following our next change control in the 
coming week.

It is not a requirement of Section 7.1 that serialNumber contain random numbers 
with 64-bit entropy – which appears to be the claim you are making. If this was 
the intention of this section in the BRs then perhaps we can propose such a 
change to the BRs. perhaps something like the following could be proposed:

“Effective September 30, 2016, CAs SHALL generate non-sequential Certificate 
serial numbers greater than zero (0) and output from a CSPRNG such that the 
resulting serialNumber contains at least 64 bits of entropy.”

However, once again, I want to reiterate the current practice of DM for the 
public trust certificates that we have generated to date:
1. all serial numbers are non-sequential;
2. all serial numbers are greater than zero;
3. all serial numbers contain at least 64 bits of output from a CSPRNG

As such, all DM certificates that Corey specifically highlighted were issued in 
compliance with the BRs and specifically in compliance with Section 7.1 that 
Corey quoted.

If there is another requirement in the BRs in respect to serial numbers where 
it states that they must contain 64 bits of entropy then can you please point 
this out?


Regards,

-- 

Scott Rea

On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy"  wrote:

>I assume you are referring to those certificates containing a serial
number with effectively 63-bits of entropy? They are misissued. BR section
4.9.1.1 provides guidance.


 

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

[Scott Rea via dev-security-policy]

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.

Regards,
 
-- 
Scott Rea

 

 

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

[Scott Rea via dev-security-policy]

G’day Rich,

This is correct with one qualification – every TLS cert chained to the 
submitted Roots are CT logged. The exception is that we also issue Public Trust 
client certificates (through a separate Issuing CA) and these are not required 
to be logged. From memory, our EV’s currently go to 4 different logs, and OVs 
got to 3 different logs. We don’t do DV at this time.

Regards,

--
Scott Rea


Scott Rea
Senior Vice President - Trust Services

[cid:image447aa1.PNG@2f49b9ba.4485a5f4]

Level 15, Aldar HQ
Abu Dhabi, United Arab Emirates
T  +971 2 417 1417
M +971 52 847 5093
E  scott@darkmatter.ae

darkmatter.ae

[Linkedin] [Twitter] 

 [Year of Zayed]  [expo]



The information in this email is intended only for the person(s) or entity to 
whom it is addressed and may contain confidential or privileged information. If 
you receive this email by error, please notify us immediately, delete the 
original message and do not disclose the contents to any other person, use or 
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 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

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

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 therefore these private TLS certs 
are not logged.

Regards,
 

-- 

Scott Rea

On 2/25/19, 9:59 PM, "dev-security-policy on behalf of rich.salz--- via 
dev-security-policy"  wrote:

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? Those 
intended to be used only on a small, privately-specified, set of recipients?

Perhaps a better way to phrase my question is: what certs would DM issue 
that would *not* be subject to their CT logging SOP?

Is there any other trusted root that has made a similar exemption?
 

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



 






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

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 CAs will use the larger serialNumbers and this would have 
an impact for example on CAs which are in completely different hierarchies to 
those used for Public Trust to have to also adopt the change (and for CA’s used 
for constrained environments e.g. IoT, the size of each extension has an 
impact).

However, we have been working with our platform provider and can now report 
that effective beginning of next week, DarkMatter will move to using random 
128-bit serial numbers for all our Public Trust certificates. 

The remaining question is what should be done if anything about existing 
certificates with 64-bit serialNumbers?  



Regards,
 

-- 

Scott Rea

On 2/25/19, 7:51 PM, "dev-security-policy on behalf of Tim Shirley via 
dev-security-policy"  wrote:

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 
that, even in the extremely unlikely event that you duplicate the random 
component of your serial number in 2 different certificates, you still have 2 
different serial numbers.

But at least 64 bits of whatever is produced needs to be entropy, and if 
any "acceptability test" is applied after the random value is generated and 
actually rejects a value, then you've reduced your number of effective bits of 
entropy.  From what has been described here, it seem clear that in this case 
what's actually being generated is 63 bits of entropy.  Any process truly 
generating 64 bits of entropy should be producing serial numbers with 9 octets 
~50% of the time.

Regards,
 
Tim Shirley  
Software Architect  
t: +1 412.395.2234 
 
www.securetrust.com <http://www.securetrust.com> 
 
Introducing the Global Compliance Intelligence Report 
<https://www2.trustwave.com/Global-Compliance-Intelligence-Report-Registration.html>
 
 

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

I think it reasonable to expect that EVERY implementation of a 
compliant CA software is doing this post-processing to ensure the intended 
serialNumber has not already been used, and this is not something unique to 
EJBCA. As such, every CA out there will have some process that requires 
post-processing of whatever value is returned with a possibility to have to 
repeat the process if there is a collision.

 

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



 






___
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 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 current platform that sets the serialNumber 
bit-size globally, however we expect a future release will allow this to be 
adjusted per CA. Once that is available, we can use any of the good suggestions 
you have made below to adjust all our Public Trust offerings to move to larger 
entropy on serialNumber determination.

However, the following is the wording from Section 7.1 of the latest Baseline 
Requirements:
“Effective September 30, 2016, CAs SHALL generate non-sequential Certificate 
serial numbers greater than zero (0) containing at least 64 bits of output from 
a CSPRNG.”

Unless we are misreading this, it does not say that serialNumbers must have 
64-bit entropy as output from a CSPRNG, which appears to be the point you and 
others are making. If that was the intention, then perhaps the BRs should be 
updated accordingly?

We don’t necessarily love our current situation in respect to entropy in 
serialNumbers, we would love to be able to apply some of the solutions you have 
outlined, and we expect to be able to do that in the future. However we still 
assert that for now, our current implementation of EJBCA is still technically 
complaint with the BRs Section 7.1 as they are written. Once an update for 
migration to larger entropy serialNumbers is available for the platform, we 
will make the adjustment to remove any potential further isssues.

Regards,
 

-- 

Scott Rea

On 2/25/19, 1:32 PM, "dev-security-policy on behalf of Paul Kehrer via 
dev-security-policy"  wrote:

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 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 serialNumber, it is
discarded, and new value is generated. This process is repeated until the
first valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate
each serialNumber that gets used, and this is complaint with the BRS
Section 7.1.

This approach (assuming it is accurately described) discards exactly half
of all values, thus halving the address space. That means there are 63-bits
of entropy, so I do not agree that this process is compliant with the
baseline requirements. More generally, RFC 5280 allows up to 20 octets in
the serial number field so why are you choosing to issue on the lower bound?



I will also point out that if the returned value is a valid as a
serialNumber, it is further checked to see if that value has not been used
before, since there is obviously a minimal chance of collision in any truly
random process. In this case the serialNumber value will also be discarded
and the process repeated.

I don't believe all public CAs do collision detection because many have
chosen to implement serial generation such that collision is highly
improbable. For example, a CA may choose to generate a 160-bit value and
clamp the high bit to zero. This provides 159-bits of entropy, with a
collision probability of roughly 1 in 2 ** 79.5. Alternately, a CA might
choose to issue with 80-bits of entropy concatenated with a 64-bit
nanosecond time resolution timestamp. This provides 1 in 2 ** 40 collision
probability for any given nanosecond. As a final example, Let's Encrypt's
Boulder CA generates a 136-bit random value and prefixes it with an 8-bit
instance ID:

https://github.com/letsencrypt/boulder/blob/a9a0846ee92efa01ef6c6e107d2e69f4ddbea7c0/ca/ca.go#L511-L532

1 in 2 ** 79.5 is roughly as probable as a randomly generated number
successfully passing typical Miller-Rabin primality testing while in
reality being composite. This is not a risk we worry about when creating
new root keys.


I think it reasonable to expect that EVERY implementation of a compliant CA
software is doing this post-processing to ensure the intended serialNumber
has not already been used, and this is not something unique to EJBCA. As
such, every CA out there will have some process that requires
post-processing of whatever value is returned with a possibility to have to
repeat the process if there is a collision.



Regards,


-- 

Scott Rea
 

Scott Rea | Senior Vice President - Trust Services 
T

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

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 serialNumber, it is 
discarded, and new value is generated. This process is repeated until the first 
valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate each 
serialNumber that gets used, and this is complaint with the BRS Section 7.1.

I will also point out that if the returned value is a valid as a serialNumber, 
it is further checked to see if that value has not been used before, since 
there is obviously a minimal chance of collision in any truly random process. 
In this case the serialNumber value will also be discarded and the process 
repeated.

I think it reasonable to expect that EVERY implementation of a compliant CA 
software is doing this post-processing to ensure the intended serialNumber has 
not already been used, and this is not something unique to EJBCA. As such, 
every CA out there will have some process that requires post-processing of 
whatever value is returned with a possibility to have to repeat the process if 
there is a collision.

Regards,
 

-- 

Scott Rea

 

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.

On 2/25/19, 6:11 AM, "Scott Rea"  wrote:

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 informed discussion (I 
know that DM is not the only CA using this platform). 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. Please note, the requirement is not a 64-bit 
number, but that a 64-bit output from a CSPRNG process is contained in the 
serialNumber, and we believe this is exactly what is happening.


Regards,
 

-- 

Scott Rea

On 2/25/19, 5:48 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

Hi Scott,
Thank you for the prompt response and the transparency in regard to the 
software stack used by your CA operations. The detailed response that you 
provided will hopefully make it easier to highlight the disconnect we have.

You are correct that ASN.1 INTEGERs are 2's-complement signed integers. 
Every DarkMatter-issued certificate that I've encountered (both those chained 
to Digicert roots as well as your roots as well as the DarkMatter root 
certificates themselves) has an INTEGER data size of exactly 8 octets (64 
bits). By outputting 64 random bits from the CSPRNG and then coercing the most 
significant bit to 0 (to make the INTEGER value positive, as you mentioned) 
means that the CA software is discarding one bit from the CSPRNG (since the 
most significant bit is being coerced to 0) and embedding only 63 bits of 
CSPRNG output in the certificate serial number. Section 7.1 of the Baseline 
Requirements requires at least 64 bits output from a CSPRNG, so I do not 
believe the serial number generation scheme that you have described is 
compliant.

Thanks,
Corey






 






___
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 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 
I do know we had some debate about how to best reflect the desired constraints 
because there did not seem to be any decent examples that we could find in the 
wild as to how others were achieving a country level restriction, and 
configuration that was finally settled on existed as an example on one the 
groups, and in testing it provided the desired results.

Even though the dNSName example in 5280 does not explicitly prohibit the 
leading “.” the example provided would lead most folks to that conclusion, and 
that is obviously how the linters are interpreting it.

These two Intermediates were re-signed without the nameConstriant extensions 
after we realized most organizations based in the UAE are often using .com or 
.org anyway to host their sites, and therefore we couldn’t effectively meet the 
needs of local customers. So these two have not been distributed for a couple 
of years now anyway.



Regards,
 

-- 

Scott Rea

On 2/25/19, 5:57 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

Hi Scott,
The verbiage from RFC 5280, section 4.2.1.10 that you quoted is in regard 
to URI GeneralNames, as the paragraph starts with "For URIs...".

The relevant paragraph in section 4.2.1.10 that specifies the required 
syntax of dNSNames in nameConstraints and explains why the two intermediates 
are non-compliant is as follows:

"DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not."

As you can see, there is no provision for encoding a leading period in 
dNSNames. Several certificate linters detect this particular problem, which you 
can see demonstrated in the two links I provided to the two intermediates' 
crt.sh entries.

Thanks,
Corey


 

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

[Scott Rea via dev-security-policy]

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 informed discussion (I 
know that DM is not the only CA using this platform). 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. Please note, the requirement is not a 64-bit 
number, but that a 64-bit output from a CSPRNG process is contained in the 
serialNumber, and we believe this is exactly what is happening.


Regards,


--

Scott Rea

On 2/25/19, 5:48 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

Hi Scott,
Thank you for the prompt response and the transparency in regard to the 
software stack used by your CA operations. The detailed response that you 
provided will hopefully make it easier to highlight the disconnect we have.

You are correct that ASN.1 INTEGERs are 2's-complement signed integers. 
Every DarkMatter-issued certificate that I've encountered (both those chained 
to Digicert roots as well as your roots as well as the DarkMatter root 
certificates themselves) has an INTEGER data size of exactly 8 octets (64 
bits). By outputting 64 random bits from the CSPRNG and then coercing the most 
significant bit to 0 (to make the INTEGER value positive, as you mentioned) 
means that the CA software is discarding one bit from the CSPRNG (since the 
most significant bit is being coerced to 0) and embedding only 63 bits of 
CSPRNG output in the certificate serial number. Section 7.1 of the Baseline 
Requirements requires at least 64 bits output from a CSPRNG, so I do not 
believe the serial number generation scheme that you have described is 
compliant.

Thanks,
Corey





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

[Scott Rea via dev-security-policy]

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 
period, it MAY be expanded with one or more labels.”  This appears to 
contradict your assertion that leading period constraints violate 5280…

During the period that these intermediates were deployed, the browsers and 
platforms dependent on these performed path processing exactly as expected with 
this configuration.

Can you please illuminate the passage in the RFC where you feel a leading 
period in a permitted subtree e.g. (“.ae”) as was used in the identified 
intermediate certificates, is a violation??

Regards,
 

-- 

Scott Rea

On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

Furthermore, two of the intermediates issued to DarkMatter which chain to 
QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10 
(https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the 
dNSName in the nameConstraints extension's permittedSubtrees field contains a 
leading period (".ae"), which violates the hostname syntax specified in section 
4.2.1.10. Therefore, these two intermediate certificates 
(https://crt.sh/?id=23432430=cablint, 
https://crt.sh/?id=19415522=cablint) are also mis-issued under the Baseline 
Requirements.

I have sent a Certificate Problem Report to Digicert to notify them of 
these findings, as these intermediates and DarkMatter-issued certificates chain 
to roots under their control.


 

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

[Scott Rea via dev-security-policy]

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 the requisite setting for 64-bit random 
serial numbers and our source of entropy is a FIPS140 certified HSM, so I too 
was surprised by the findings you reported. However, during our investigation 
of this potential issue, we have thus far discovered that the platform appears 
to be compliant with the requisite standard, and the anomaly you are 
highlighting is potentially due just to the integer representation you are 
using in your calculations.

RFC5280 (section 4.1.2.2) defines serialNumber to be a positive INTEGER, and 
X.690 defines INTEGER to consist of one or more octets and (specifically 
section 8.3.3) says the octets shall be a two’s complement binary number equal 
to the integer value. Using the two’s complementary representation means that 
the output of the octet conversion is a signed integer, and it could be 
positive or negative – the range of integers from 64-bit numbers being from 
–(2^63) to [+ (2^63)-1]. But since the RFC requires only positive integers, the 
64-bits of output from the CSPRNG function must eventuate only in positive 
numbers, and negative numbers cannot be used. In two’s complement 
representation, the leading bit determines whether the number is positive or 
negative – for positive numbers, the leading bit will always be zero (if it’s a 
1, then that represents a negative number which RFC5280 prohibits).

So our findings are that the platform is indeed using 64-bit output from an 
appropriate CSPRNG for generating serialNumbers, and that the leading zero is 
exactly what is required to indicate that it is a positive number in two’s 
complement representation of the INTEGER, which is the requirement under 
RFC5280. Therefore our findings indicate that the serial number generation 
scheme used by DarkMatter in it’s certificate hierarchy does meet the 
requirements set forth in the Baseline Requirements, section 7.1.


Regards,
 

-- 

Scott Rea

On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

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 a 
CSPRNG".
> 
> An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, 
and 12 end-entity interoperability/test certificates) in the DarkMatter 
certificate hierarchy currently listed in the inclusion request indicates that 
the hierarchy is likely not compliant with this requirement. Specifically, all 
23 certificates have an 8-octet (64 bit) serial number, but the most 
significant bit (big-endian) of their serial numbers is 0. The probability that 
all 23 known certificates in the hierarchy having exactly 64 bits of output 
from a CSPRNG with a most significant bit value of 0 is 1 in 2^23, or 1 in 
8,388,608, which would make this a highly extraordinary event. The far more 
likely case is that each certificate's serial number does not contain the 
requisite number of bits (64) output from a CSPRNG.
> 
> A detailed breakdown is as follows:
> 
> "subject CN", notBefore, "serial number", "highest bit index set (1-based 
indexing)"
> 
> "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63
> "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61
> "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63
> "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63
> "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63
> "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 63
> "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 63
> "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63
> "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63
> exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61
> expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62
> exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63
> expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63
> reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61
> reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60
> revrd.ca.darkmatter.ae, 2018-07-05, 0D:C6:08:0C:4F:B4:76:63, 60
> revru.ca.darkmatter.ae, 2018-07-05, 6F:5A:8C:4F:54:FC:3A:E2, 63
> valed.ca.darkmatter.ae, 2018-07-05, 1E:40:E3:2D:DF:21:95:59, 61
> valeu.ca.darkmatter.ae, 2018-07-05, 65:84:D9:1D:F5:CE:C5:89, 63
> 

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

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 who are primarily 
focused on defensive cyber security activities e.g. Cyber Network Defense and 
Managed Security Services to protect and ensure the integrity of the CA 
operations.

Regards,
 

-- 

Scott Rea

 

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.

On 2/23/19, 6:46 PM, "Kurt Roeckx"  wrote:

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 transformation. We have never, nor will we ever, 
operate or manage non-defensive cyber activities against any nationality.

Can you explain what you mean with defensive cyber security and
how this relates to the CA?


Kurt




 






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


Regards,
 

-- 

Scott Rea

On 2/23/19, 1:21 AM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy"  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 under
QuoVadis (recently acquired by DigiCert [3]), so it seems appropriate to
open up a discussion now. The purpose of this discussion is to determine if
Mozilla should distrust DarkMatter by adding their intermediate CA
certificates that were signed by QuoVadis to OneCRL, and in turn deny the
pending root inclusion request.

The rationale for distrust is that multiple sources [1][4][5] have provided
credible evidence that spying activities, including use of sophisticated
targeted surveillance tools, are a key component of DarkMatter’s business,
and such an organization cannot and should not be trusted by Mozilla. In
the past Mozilla has taken action against CAs found to have issued MitM
certificates [6][7]. 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.

Mozilla’s Root Store Policy [8] grants us the discretion to take actions
based on the risk to people who use our products. Despite the lack of
direct evidence of misissuance by DarkMatter, this may be a time when we
should use our discretion to act in the interest of individuals who rely on
our root store.

I would greatly appreciate everyone's constructive input on this issue.

- Wayne

[1] https://www.reuters.com/investigates/special-report/usa-spying-raven/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262

[3]

https://groups.google.com/d/msg/mozilla.dev.security.policy/hicp7AW8sLA/KUSn20MrDgAJ

[4]

https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/

[5]

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

[6]

https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/Fj-LUvhVQYEJ

[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
[8]

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
 

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



 






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