DarkMatter Concerns

[Wayne Thayer]

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/

[Corey Bonnell]

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
valrd.ca.darkmatter.ae, 2018-07-05, 3F:53:0E:C5:7D:F5:83:C5, 62
valru.ca.darkmatter.ae, 2018-07-05, 14:CB:73:81:18:20:C5:25, 61
"DigitalX1 Assured CA G4", 2018-09-05, 6D:9F:01:8E:40:8E:5F:7F, 63
"DM X1 Assured CA G4", 2018-09-05, 71:9C:24:E8:9A:D9:44:AB, 63

Thanks,
Corey

[Jonathan Rudenberg]

On Fri, Feb 22, 2019, at 16:21, Wayne Thayer via dev-security-policy wrote:
> 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.

It's worth noting that DarkMatter has already been documented to have misissued certificates, though not in a way that is obviously for malicious purposes.

1) As discovered by Rob Stradling[1], they issued at least two certificates with a CN that was not included in the SAN extension. An incident report was requested[2], but I was unable to find it in Bugzilla or on this mailing list.

2) https://crt.sh/?id=271084003&opt=zlint - This certificate has an invalid domain `apiuat.o`. I'm not aware of prior discussion about this.

With regards to the broader question, I believe that DarkMatter's alleged involvement with hacking campaigns is incompatible with operating a trustworthy CA. This combined with the existing record of apparent incompetence by DarkMatter (compare the inclusion bugs for other recently approved CAs for contrast), makes me believe that the approval request should be denied and the existing intermediates revoked via OneCRL. I don't see how approving them, or the continued trust in their intermediates, would be in the interests of Mozilla's users or compatible with the Mozilla Manifesto.

Jonathan

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

[coo...@gmail.com]

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 operating a trustworthy CA. This combined with the existing record of apparent incompetence by DarkMatter (compare the inclusion bugs for other recently approved CAs for contrast), makes me believe that the approval request should be denied and the existing intermediates revoked via OneCRL. I don't see how approving them, or the continued trust in their intermediates, would be in the interests of Mozilla's users or compatible with the Mozilla Manifesto.
>
> Jonathan
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c29
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32

I wrote a post about this issue this morning for EFF: https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else

Given DarkMatter's business interest in intercepting TLS communications adding them to the trusted root list seems like a very bad idea. (I would go so far as revoking their intermediate certificate as well, based on these revelations.)

[rjarr...@yahoo.com]

I can't trust the Dark Matter CA for a minute. It's a threat to national security. It's a national security issue.

[Kurt Roeckx]

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 with operating a trustworthy CA. This combined with the existing record of apparent incompetence by DarkMatter (compare the inclusion bugs for other recently approved CAs for contrast), makes me believe that the approval request should be denied and the existing intermediates revoked via OneCRL. I don't see how approving them, or the continued trust in their intermediates, would be in the interests of Mozilla's users or compatible with the Mozilla Manifesto.
> >
> > Jonathan
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c29
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32
>

> I wrote a post about this issue this morning for EFF: https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else
>
> Given DarkMatter's business interest in intercepting TLS communications adding them to the trusted root list seems like a very bad idea. (I would go so far as revoking their intermediate certificate as well, based on these revelations.)

I would also like to have a comment from the current root owner
(digicert?) on what they plan to do with it.


Kurt

[Scott Rea]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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
Scot...@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-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[ferenn...@gmail.com]

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" and crystal-ball like "looking into the future" (asserting they _will_ abuse their power) without a shred of conclusive evidence is considered good practice, now? Aren't the rules for admission of a CA in root stores there for a reason (among others to keep the process objective)?
Not like all the other ones in the root stores have spotless historical records either. Far from it.

> I don't see how approving them, or the continued trust in their intermediates, would be in the interests of Mozilla's users or compatible with the Mozilla Manifesto.

Oh come on. Mozilla itself isn't compatible with the Mozilla Manifesto.

Also, I don't see how a corporate organization's manifesto should have any bearing on the truststore used in many independent FOSS operating systems and applications. Mozilla might not agree with many things based on political bias and let's leave that out the door, shall we? Or do you want to start refusing or distrusting CAs that have any sort of affiliation with right-wing political parties next?

[Kurt Roeckx]

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

[alex....@gmail.com]

(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 article. Being able to articulate which conduct described there is incompatible with participation in the Mozilla Root Program.

I propose two answers (to start with :-)):

First, is honesty. Even as we build technologies such as CT and audit regimes which improve auditability and accountability, CAs are ultimately in the business of trust. https://twitter.com/josephfcox/status/1090592247379361792 makes the argument that DarkMatter has been in the business of lying to journalists. Lying is fundamentally incompatible with trust.

Second, is vulnerability exploitation. The Reuter's article describes use of the "Karma" malware/exploits against iOS. It's difficult for me to imagine anyone in the business of using iOS 0days that doesn't also have a few Firefox exploits up their sleeve (possibly in the form of Tor Browser 0days). This is a leap, but not a big one. Using Firefox 0days in the wild (particularly against the sort of targets alleged: human rights activists, journalists, etc.) is not compatible with Mozilla's mission, or our parochial interest in the security of our own software.

Alex

[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

[Scott Rea]

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

[Nex]

On 2/23/19 11:07 AM, Scott Rea via dev-security-policy wrote:
> G’day Wayne et al,
>
> In response to your post overnight (included below), I want to assure you that DarkMatter’s work is solely focused on defensive cyber security, secure communications and digital transformation. We have never, nor will we ever, operate or manage non-defensive cyber activities against any nationality.
>

> Furthermore, in the spirit of transparency, we have published all our public trust TLS certificates to appropriate CT log facilities (including even all our OV certificates) before this was even a requirement. We have been entirely transparent in our operations and with our clients as we consider this a vital component of establishing and maintaining trust.
>
> We have used FIPS certified HSMs as our source of randomness in creating our Authority certificates, so we have opened an investigation based on Corey Bonnell’s earlier post regarding serial numbers and will produce a corresponding bug report on the findings.
>
> I trust this answers your concerns and we can continue the Root inclusion onboarding process.

For clarity, are you rejecting all of the following articles and blog
posts as false and fabricated?

1. https://www.reuters.com/investigates/special-report/usa-spying-raven/
2.
https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
3.
https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/

I don't mean to be cynical, but a personal assurance vs. the amounting
evidence and sources spanning over years, isn't a very convincing argument.

Best,
C.

[cwbu...@gmail.com]

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 certificates that were signed by QuoVadis to OneCRL; and
3. Demand an explanation from DigiCert as to why the intermediate CA certificates were issued in the first place and why they remain unrevoked.

[eve....@gmail.com]

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.

[named...@gmail.com]

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 (https://ca.darkmatter.ae/UAE/index.html).

[Corey Bonnell]

I would like to bolster my previous assertion that the serial number generation scheme used in the DarkMatter certificate hierarchy likely does not meet the requirements set forth in the Baseline Requirements, section 7.1.

A further analysis of all DarkMatter-issued certificates which were logged to Certificate Transparency logs with a notBefore date of 2016-09-30 or later was performed. This certificate corpus of 235 unique certificates (pre-certificate and final certificate pairs are considered to be a single “unique certificate” to avoid double-counting) is overwhelmingly comprised of end-entity TLS certificates, but there are also several infrastructure-related certificates (such as OCSP Response Signing certificates, etc.) included. DarkMatter has asserted that all publicly trusted TLS certificates that they have issued are logged to Certificate Transparency logs, so this set of 235 unique certificates includes the entirety of publicly trusted TLS certificates issued by DarkMatter since 2016-09-30.

This analysis has revealed that all 235 unique certificates have a serial number of 8 octets (64 bits) and a big-endian most significant bit set to 0. Given that the probability of all 64 bits being output from a CSPRNG with a most significant bit value of 0 for all 235 such certificates is 1 in 2^235, it is extremely likely that these certificates do not contain the minimum number of bits (64) output from a CSPRNG and are therefore mis-issued under the Baseline Requirements.

A comprehensive list of the 235 unique certificates can be found here: https://gist.github.com/CBonnell/1f01ccd93667c37800b67e518340c606

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&opt=cablint, https://crt.sh/?id=19415522&opt=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.

Thanks,
Corey

[Scott Rea]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> wrote:

On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:

I would like to bolster my previous assertion that the serial number generation scheme used in the DarkMatter certificate hierarchy likely does not meet the requirements set forth in the Baseline Requirements, section 7.1.

A further analysis of all DarkMatter-issued certificates which were logged to Certificate Transparency logs with a notBefore date of 2016-09-30 or later was performed. This certificate corpus of 235 unique certificates (pre-certificate and final certificate pairs are considered to be a single “unique certificate” to avoid double-counting) is overwhelmingly comprised of end-entity TLS certificates, but there are also several infrastructure-related certificates (such as OCSP Response Signing certificates, etc.) included. DarkMatter has asserted that all publicly trusted TLS certificates that they have issued are logged to Certificate Transparency logs, so this set of 235 unique certificates includes the entirety of publicly trusted TLS certificates issued by DarkMatter since 2016-09-30.

This analysis has revealed that all 235 unique certificates have a serial number of 8 octets (64 bits) and a big-endian most significant bit set to 0. Given that the probability of all 64 bits being output from a CSPRNG with a most significant bit value of 0 for all 235 such certificates is 1 in 2^235, it is extremely likely that these certificates do not contain the minimum number of bits (64) output from a CSPRNG and are therefore mis-issued under the Baseline Requirements.

A comprehensive list of the 235 unique certificates can be found here: https://gist.github.com/CBonnell/1f01ccd93667c37800b67e518340c606

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&opt=cablint, https://crt.sh/?id=19415522&opt=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.

Thanks,
Corey

Scott Rea | Senior Vice President - Trust Services
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
Scot...@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]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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&opt=cablint, https://crt.sh/?id=19415522&opt=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.

[Corey Bonnell]

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

[Corey Bonnell]

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]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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.

[Scott Rea]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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

[Matt Palmer]

On Mon, Feb 25, 2019 at 02:11:40AM +0000, 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.

That is not any better than just setting the MSB to zero. 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.". It's hard to imagine that
that would be considered sufficient, and it's fundamentally the same as the
process you're describing.

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

If the process is repeatedly asking for a value from the CSPRNG until it
gets one it "likes", then no, you're not using 64 bits of output from a
CSPRNG. The value may be 64 bits long, but not all 64 of those bits came from
the CSPRNG -- some of the bits came from the acceptability test, not the
CSPRNG.

- Matt

[Peter Gutmann]

Matt Palmer via dev-security-policy <dev-secur...@lists.mozilla.org> 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 for Bitcoin (the relation is <
rather than >). Come to think of it, you could actually mine cert serial
numbers, and then record them in a public blockchain, for auditability of
issued certificates.

(Note: This is satire. I'm not advocating using blockchain anything for
anything other than (a) pump-and-dump digital currency schemes and (b)
attracting VC funding).

Peter.

[Scott Rea]

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
Scot...@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" <Scot...@darkmatter.ae> 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

[Paul Kehrer]

Hi Scott,

Comments inline.

On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (

dev-secur...@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.

[Scott Rea]

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

[Jakob Bohm]

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

I believe the commonly accepted interpretation of the BR requirement is
to ensure that for each new certificate generated, there are at least
2**64 possible serial numbers and no way for anyone involved to predict
or influence which one will be used.

This rule exists to prevent cryptographic attacks on the algorithms used
for signing the certificates (such as RSA+SHA256), and achieves this
protection because of the location of the serial number in the
certificate structure.

If all the serial numbers are strictly in the range 0x0000000000000001
to 0x7FFFFFFFFFFFFFFF then there is not enough protection of the signing
algorithm against these attacks.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Tim Shirley]

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>

[Nick Lamb]

On Sat, 23 Feb 2019 10:16:27 +0100
Kurt Roeckx via dev-security-policy

<dev-secur...@lists.mozilla.org> 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 have practical ability to issue
independently of Digicert?

https://crt.sh/?caid=22507

It would be nice to know where this is on the spectrum of intermediate
CAs, between the cPanel intermediate (all day-to-day operations
presumably by Sectigo and nobody from cPanel has the associated RSA
private keys) and Let's Encrypt X3 (all day-to-day operations by Let's
Encrypt / ISRG and presumably nobody from IdenTrust has the associated
RSA private keys)


2. Does Digicert agree that currently misissuances, even on seemingly
minor technical issues like threadbare random serial numbers are their
problem, since they are the root CA and ultimately responsible for this
intermediate ?


Nick.

[Rob Stradling]

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
> <dev-secur...@lists.mozilla.org> 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 have practical ability to issue
> independently of Digicert?
>
> https://crt.sh/?caid=22507
>
> It would be nice to know where this is on the spectrum of intermediate
> CAs, between the cPanel intermediate (all day-to-day operations
> presumably by Sectigo and nobody from cPanel has the associated RSA
> private keys)

Hi Nick. I can confirm that all day-to-day operations for the cPanel
intermediates are performed by Sectigo, and nobody from cPanel has the
associated RSA private keys.

> and Let's Encrypt X3 (all day-to-day operations by Let's
> Encrypt / ISRG and presumably nobody from IdenTrust has the associated
> RSA private keys)

<snip>

QuoVadis disclosed [1] that...

"The DarkMatter CAs were previously hosted and operated by QuoVadis, and
included in the QuoVadis WebTrust audits through 2017. In November 2017,
the CAs were transitioned to DarkMatter’s own control following
disclosure to browser root programs."

I take that to mean that DarkMatter are in possession of the RSA private
key corresponding to https://crt.sh/?caid=22507.


[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[rich...@gmail.com]

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?

[Matthew Hardeman]

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 trusted by a broad set of internet browsers.

[Matthew Hardeman]

On Mon, Feb 25, 2019 at 12:15 PM Richard Salz <rich...@gmail.com> 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 wonder whether or not it's truly in scope for
policy / browser inclusion / etc discussions?

[Buschart, Rufus]

> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Matthew Hardeman via dev-security-policy

If the certificate is part of a hierarchy that chains up to a root under Mozillas Root Program there should be no question about this - yes it is in scope.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Jeremy Rowley]

Hi all,

Sorry for the delayed response. Been traveling and haven't had a chance to
properly format my thoughts until now.

As you all know, DigiCert recently acquired the Quovadis CA. As the operator
of the CA, DigiCert is responsible for the issuing CA controlled by
DarkMatter. DarkMatter controls the keys of the intermediate, have their own
CPS, and undergo their own annual audits.

With one exception, DigiCert has a policy against signing externally
operated intermediate CAs capable of issuing TLS certificates. The exception
is for browser operators who want a cross-sign, which is not applicable in
this case. We've found that limiting external CAs provides a better
situation for users and the security community. As we've done in the past,
we feel there is a logical and legal way to address inherited contracts and
externally operating CAs so that we do not leave site operators and relying
parties using those sites in a lurch. We are committed to working with
DarkMatter on a plan that works for them and aligns to our policy.

As for DarkMatter, we have not received direct evidence of any intentional
mis-issuance or use of a certificate for a MiTM attack. As a policy, we do
not revoke certificates based purely on allegations of wrongdoing. This is
true regardless of source, such as trademark disputes, government requests
for revocation, and similar matters. We do revoke certificates after
receiving a formal request for revocation from a trust store operator. I
think this policy is a logical approach as the policy avoids government
influence and public pressure over unpopular sites while acknowledging the
browser's control over their root store.

If we are presented with direct evidence of serious BR violations or
wrongdoing, we will certainly act in the best interests of user security and
revoke the intermediate. Wrongdoing warranting revocation definitely
includes using the issuing CA to intercept communication where the
certificate holder does not control the domain.

We already received a formal report on the serial number issue. This issue
reminds me of past discussion
(https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr
opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which
did not warrant removal from the root store. We plan on filling a bug report
on the incident and working with DarkMatter to ensure their systems are
compliant with the BRs. This includes their replacing non-compliant
certificates in accordance with 4.9.1.1. Considering that the certificates
resulted from a misreading of the BRs rather than a malicious act and the
historical precedent in not removing CAs for entropy issues, I don't think
there is justification to revoke the CA. IWe, of course, expect DarkMatter
to update their systems and work with the Mozilla community in providing all
information necessary to resolve concerns about their operation.

Hopefully that answers questions you have. Feel free to ask me anything.

Jeremy

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

[Jeremy Rowley]

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 me
in the past.

You really can't log private certs as they don't chain to a root trusted by
any of the CT logs.

[Jeremy Rowley]

One other thing I wanted to get ahead of is that we are revoking three Dark
Matter issuing CAs tomorrow. This revocation was planned well before this
discussion started. These three certificates were issued in 2016 with
improper name constraints. The 2017 certificates currently used are
replacements for those certificates without any name constraints. The three
certificates are:

CN=DarkMatter Assured CA,O=DarkMatter LLC,C=AE
4812bd923ca8c43906e7306d2796e6a4cf222e7d 2024-04-29 22:53:00
6b6fa65b1bdc2a0f3a7e66b590f93297b8eb56b9
CN=DarkMatter High Assurance CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c836 2024-04-29 22:38:11
8835437d387bbb1b58ff5a0ff8d003d8fe04aed4
CN=DarkMatter Secure CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c836 2024-04-29 22:45:18
6a2c691767c2f1999b8c020cbab44756a99a0c41

Jeremy

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On

[Scott Rea]

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

[Scott Rea]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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]

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:image44...@2f49b9ba.4485a5f4]<http://www.darkmatter.ae>

Level 15, Aldar HQ
Abu Dhabi, United Arab Emirates
T +971 2 417 1417<tel:+971%202%20417%201417>
M +971 52 847 5093<tel:+971%2052%20847%205093>
E Scot...@darkmatter.ae<mailto:Scot...@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.

From: Richard Salz <rich...@gmail.com>
Date: Tuesday, February 26, 2019 at 5:31 PM
To: Scott Rea <Scot...@darkmatter.ae>
Cc: <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DarkMatter Concerns

So then every cert signed by the keys intended for the trust store will be CT logged?

[Scott Rea]

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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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" <dev-security-...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> 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]

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

[Mike Kushner]

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 was back in the days when the opinion was that sequential serial numbers had to be used. We had some work convincing some users that random was better than sequential. By default 8 bytes (64 bits) were used, as it's a nice power of 2 number. Back then longer serial numbers were frowned upon and there were product out there that could not even parse 16 byte serial numbers, so 8 bytes was a good choice that was compatible.
As years went by we introduced the possibility to use longer serial numbers, through a configuration setting at build time. This setting is no convenient to use (automatically persisted across upgrades etc) in our Appliance and cloud platforms, and we had on the roadmap to remedy this with a more use friendly setting.

A very strong goal of EJBCA, and PrimeKey, is to be standard compliant with both open standards and regulations, and thus we are not completely satisfied with debating 63 vs 64 bits.
We are planning to release a fix version with a convenient per CA setting, and default to larger serials, in short time. Any existing CA will be easily configured to use between 4 and 20 octets serial numbers for future issuance. Serial numbers must be compliant with RFC5280 and X.690, which is the test we do on the output from the CSPRNG, only using compliant ones.
https://jira.primekey.se/browse/ECA-4991

In addition to random serial numbers, EJBCA checks for collisions, so even in the very unlikely event of equal serial numbers being generated, no certificates with duplicated serial numbers should be issued from a CA based on the EJBCA software. By comparison, collisions do happen regularly in testing when using 32 bit serial numbers (and are averted), so the underlying checks function as we expect.

Looking back at the origin to when public CAs moved form sequential to random serial numbers we believe this originated from the weakness in SHA1, making a preimage attack at least theoretically possible against SHA1. EJBCA was very early on supporting SHA256 as well. To our knowledge there are no known preimage attacks against SHA256, correct us if we're wrong. In other words, we do not consider this a security issue, but (only) a compliance issue.

Cheers,
Tomas Gustafsson (CTO)
and
Mike Agrenius Kushner (PO EJBCA)

[Richard Salz]

[Rob Stradling]

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 26/02/2019 13:56, 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 potentially share this on the list, I am attaching a copy of that letter to this post.
>
> Regards,
>
>

--

[Jonathan Rudenberg]

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 potentially
> share this on the list, I am attaching a copy of that letter to this
> post.

Since attachments tend to not come through on this list, here's a link: https://bugzilla.mozilla.org/attachment.cgi?id=9046699

This statement does not appear to me to directly deny any of the media reports, it simply calls them "misleading". There is no standard definition for "defensive cyber activities", which could mean a lot of things.

As far as I know DarkMatter has not provided a comment directly to Reuters at all, let alone denied the report.

Jonathan

[Paul Wouters]

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:
> https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699

Thanks for sending the link. The letter is uhm interesting. It both
states they cannot say anything for national security reasons, say they
unconditionally comply with national security (implying even if that
violates any BRs) and claims transparency for using CT which is in fact
being forced by browser vendors on them.

"quests to protect their nations" definitely does not exclude "issuing
BR violating improper certificates to ensnare enemies of a particular
nation state".

Now of course, I don't think this is very different from US based
companies that are forced to do the same by their governments, which
is why DNSSEC TLSA can be trusted more (and monitored better) than a
collection of 500+ CAs from all main nation states that are known for
offense cyber capabilities. But you can ignore this as off-topic :)

Paul

[Hanno Böck]

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 contradiction to it, as it clearly describes "offensive cyber"
operations by Dark Matter.

I find it very hard to believe that the entire Reuters story is a hoax.
Nobdody has challenged it yet. According to the Reuters article
DarkMatter was asked for a comment and didn't reply.

Either the Reuters story is false or your CEOs statement is false. They
can't both be true.


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Wayne Thayer]

Scott,

On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy <
dev-secur...@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 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?
>

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

Mozilla provides further guidance here:
https://wiki.mozilla.org/CA/Responding_To_An_Incident

[Richard Salz]

Thanks for the clarification.

[Corey Bonnell]

According to the statement released today, DarkMatter considers their serial number generation logic to be compliant and these certificates are not mis-issued.

[hac...@gmail.com]

It reminds me of a similar story in my country:
https://security.googleblog.com/2013/12/further-improving-digital-certificate.html

Please add a strict limit to the top-level domains in Firefox...

[Matthew Hardeman]

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 trusted root program or any other root
program for that matter? I submit that it means that anyone rarely knows
to a certainty the nature and extent of ownership and control over a given
business to a high degree of confidence. This is especially true when you
start divorcing equity interest from right of control. (Famous example,
Zuckerberg's overall ownership of Facebook is noted at less than 30% of the
company, yet he ultimately has personal control of more than 70% of voting
rights over the company, the end result is that he ultimately can control
the company and its operations in virtually any respect.)

A number of jurisdictions allow for creating of trusts, etc, for which the
ownership and control information is not made public. Several of those, in
turn, can each be owners of an otherwise normal looking LLC in an innocuous
jurisdiction elsewhere, each holding say, 10% equity and voting rights.
Say there are 6 of those. Well, all six of them can ultimately be proxies
for the same hidden partner or entity. And that partner/entity would
secretly be in full control. Without insider help, it would be very
difficult to determine who that hidden party is.

Having said all of this, I do have a point relevant to the current case.
Any entity already operating a WebPKI trusted root signed SubCA should be
presumed to have all the access to the professionals and capital needed to
create a new CA operation with cleverly obscured ownership and corporate
governance. You probably can not "fix" this via any mechanism.

In a sense, that DarkMatter isn't trying to create a new CA out of the
blue, operated and controlled by them or their ultimate ownership but
rather is being transparent about who they are is interesting.

One presumes they would expect to get caught at misissuance. The record of
noncompliance and misissuance bugs created, investigated, and resolved one
way or another demonstrates quite clearly that over the history of the
program a non-compliant CA has never been more likely to get caught and
dealt with than they are today.

I believe the root programs should require a list of human names with
verifiable identities and corresponding signed declarations of all
management and technical staff with privileged access to keys or ability to
process signing transactions outside the normal flow. Each of those people
should agree to a life-long ban from trusted CAs should they be shown to
take intentional action to produce certificates which would violate the
rules, lead to MITM, etc. Those people should get a free pass if they
whistle blow immediately upon being forced, or ideally immediately
beforehand as they hand privilege and control to someone else.

While it is unreasonable to expect to be able to track beneficial
ownership, formal commitments from the entity and the individuals involved
in day to day management and operations would lead to a strong assertion of
accountable individuals whose cooperation would be required in order to
create/provide a bad certificate. And those individuals could have "skin
in the game" -- the threat of never again being able to work for any CA
that wants to remain in the trusted root programs.

All of Google, Amazon, and Microsoft are in the program. All of these have
or had significant business with at least the US DOD and have a significant
core of managing executives as well as operations staff and assets in the
United States. As such, it is beyond dispute that each of these is
subordinate to the laws and demands of the US Government. Still, none of
these stand accused of using their publicly trusted root CAs to issue
certificates to a nefarious end. It seems that no one can demonstrate that
DarkMatter has or would either. If so, no one has provided any evidence of
that here.

It's beyond dispute that Mozilla's trusted root program rules allow for
discretionary exclusion of a participant without cause. As far as I'm
aware, that hasn't been relied upon as yet.

For technologists and logicians, it should rankle that it might be
necessary to make reliance upon such a provision in order to keep
DarkMatter out. In my mind, it actually calls into question whether they
should be kept out.

As Digicert's representative has already pointed out, the only BR
compliance matter even suggested at this point is the bits-of-entropy in
serial number issue and others have been given a pass on that. While I
suppose you could call this exclusionary and sufficient to prevent the
addition, it would normally be possible for them to create new key pairs
and issuance hierarchy and start again with an inclusion request for those,
avoiding that concern in round 2.

I think the knee-jerk reaction against this inclusion request ignores a
fundamental truth: by way of the QuoVadis signed SubCA, DarkMatter is and
has been operating a publicly trusted CA in the WebPKI for some time now.
What changes when they're directly included that increases the risk above
and beyond the now current presently accepted risk?

I strongly urge that the program contemplate that in the best case scenario
they don't and can't know the true beneficial ownership of the various CAs
and the map of the relationships of those beneficial owners to other
questionable entities. And following that line of thinking, that the
program presuppose that the ownership and governance/control is vested in
the most corruptible, evil people/groups imaginable and structure the
management of trust of CAs in a framework that assumes and accounts for as
much.

[Peter Gutmann]

Mike Kushner via dev-security-policy <dev-secur...@lists.mozilla.org> 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 first one
that came up in my collection, from twenty-five years ago:

0 551: SEQUENCE {
4 400: SEQUENCE {
8 9: INTEGER 00 A0 98 0F FC 30 AC A1 02
19 13: SEQUENCE {
21 9: OBJECT IDENTIFIER md5WithRSAEncryption (1 2 840 113549 1 1 4)
32 0: NULL
: }
[...]
81 43: SET {
83 41: SEQUENCE {
85 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
90 34: PrintableString 'A Free Internet and SET Class 1 CA'
: }
: }
: }
126 26: SEQUENCE {
128 11: UTCTime '9609010000Z'
: Error: Time is encoded incorrectly.

RFC 3280 (2002) explicitly added handling for random data as serial numbers:

Given the uniqueness requirements above, serial numbers can be
expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets.

(20 bytes being a SHA-1 hash, which was the fashion at the time).

Peter.