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