Re: DarkMatter Concerns
Matt Palmer via dev-security-policy writes: >Imagine if a CA said "we generate a 64-bit serial by getting values from the >CSPRNG repeatedly until the value is one greater than the previously issued >certificate, and use that as the serial number.". Well, something pretty close to that works 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Mon, Feb 25, 2019 at 02:11:40AM +, Scott Rea via dev-security-policy wrote: > My anticipation is that what happens is that CSPRNG process is repeated > until a positive INTEGER is returned. In which case a 64-bit output from > a CSPRNG is contained in the serialNumber as is required. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
G’day Corey, I can see your point – perhaps the more accurate way explicitly allowed under 5280 would have been to encode the constraint as type uniformResourceIdentifier rather than the type dNSName that was used. I don’t recall if we actually tried that in our tests at the time with QV, but I do know we had some debate about how to best reflect the desired constraints because there did not seem to be any decent examples that we could find in the wild as to how others were achieving a country level restriction, and configuration that was finally settled on existed as an example on one the groups, and in testing it provided the desired results. Even though the dNSName example in 5280 does not explicitly prohibit the leading “.” the example provided would lead most folks to that conclusion, and that is obviously how the linters are interpreting it. These two Intermediates were re-signed without the nameConstriant extensions after we realized most organizations based in the UAE are often using .com or .org anyway to host their sites, and therefore we couldn’t effectively meet the needs of local customers. So these two have not been distributed for a couple of years now anyway. Regards, -- Scott Rea On 2/25/19, 5:57 AM, "dev-security-policy on behalf of Corey Bonnell via dev-security-policy" wrote: Hi Scott, The verbiage from RFC 5280, section 4.2.1.10 that you quoted is in regard to URI GeneralNames, as the paragraph starts with "For URIs...". The relevant paragraph in section 4.2.1.10 that specifies the required syntax of dNSNames in nameConstraints and explains why the two intermediates are non-compliant is as follows: "DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not." As you can see, there is no provision for encoding a leading period in dNSNames. Several certificate linters detect this particular problem, which you can see demonstrated in the two links I provided to the two intermediates' crt.sh entries. Thanks, Corey Scott Rea | Senior Vice President - Trust Services Tel: +971 2 417 1417 | Mob: +971 52 847 5093 scott@darkmatter.ae The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
G’day Corey, I am not sure if the phrase “…outputting 64 random bits from the CSPRNG and then coercing the most significant bit to 0” is actually an accurate representation of what is happening under the covers – we have asked for clarification from the developers so we can all have an informed discussion (I know that DM is not the only CA using this platform). My anticipation is that what happens is that CSPRNG process is repeated until a positive INTEGER is returned. In which case a 64-bit output from a CSPRNG is contained in the serialNumber as is required. Please note, the requirement is not a 64-bit number, but that a 64-bit output from a CSPRNG process is contained in the serialNumber, and we believe this is exactly what is happening. Regards, -- Scott Rea On 2/25/19, 5:48 AM, "dev-security-policy on behalf of Corey Bonnell via dev-security-policy" wrote: Hi Scott, Thank you for the prompt response and the transparency in regard to the software stack used by your CA operations. The detailed response that you provided will hopefully make it easier to highlight the disconnect we have. You are correct that ASN.1 INTEGERs are 2's-complement signed integers. Every DarkMatter-issued certificate that I've encountered (both those chained to Digicert roots as well as your roots as well as the DarkMatter root certificates themselves) has an INTEGER data size of exactly 8 octets (64 bits). By outputting 64 random bits from the CSPRNG and then coercing the most significant bit to 0 (to make the INTEGER value positive, as you mentioned) means that the CA software is discarding one bit from the CSPRNG (since the most significant bit is being coerced to 0) and embedding only 63 bits of CSPRNG output in the certificate serial number. Section 7.1 of the Baseline Requirements requires at least 64 bits output from a CSPRNG, so I do not believe the serial number generation scheme that you have described is compliant. Thanks, Corey Scott Rea | Senior Vice President - Trust Services Tel: +971 2 417 1417 | Mob: +971 52 847 5093 scott@darkmatter.ae The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Sunday, February 24, 2019 at 8:05:10 PM UTC-5, Scott Rea wrote:
> G’day Corey,
>
> In respect to the previously issued constrained intermediates – can you
> clarify where in RFC5280 Section 4.2.1.10 that the prohibition against a
> leading period is specified for the name constraints?
> I 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" of dev-security-policy@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=cablint,
> https://crt.sh/?id=19415522=cablint) are also mis-issued under the
> Baseline Requirements.
>
> I have sent a Certificate Problem Report to Digicert to notify them of
> these findings, as these intermediates and DarkMatter-issued certificates
> chain to roots under their control.
>
>
>
>
> Scott Rea | Senior Vice President - Trust Services
> Tel: +971 2 417 1417 | Mob: +971 52 847 5093
> scott@darkmatter.ae
>
> The information transmitted, including attachments, is intended only for the
> person(s) or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and destroy any copies of
> this information.
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On Sunday, February 24, 2019 at 7:39:34 PM UTC-5, Scott Rea wrote: > G’day Corey, > > I did not check your math, but is it possible that you are interpreting the > serial number conversion output as an unsigned integer representation? If so, > then I can understand your potential concern 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" of dev-security-policy@lists.mozilla.org> wrote: > > On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote: > > Hello, > > Section 7.1 of the Baseline Requirements states that, "Effective > September 30, 2016, CAs SHALL generate non-sequential Certificate serial > numbers greater than zero (0) containing at least 64 bits of output from a > CSPRNG". > > > > An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, > and 12 end-entity interoperability/test certificates) in the DarkMatter > certificate hierarchy currently listed in the inclusion request indicates > that the hierarchy is likely not compliant with this requirement. > Specifically, all 23 certificates have an 8-octet (64 bit) serial number, but > the most significant bit (big-endian) of their serial numbers is 0. The > probability that all 23 known certificates in the hierarchy having exactly 64 > bits of output from a CSPRNG with a most significant bit value of 0 is 1 in > 2^23, or 1 in 8,388,608, which would make this a highly extraordinary event. > The far more likely case is that each certificate's serial number does not > contain the requisite number of bits (64) output from a CSPRNG. > > > > A detailed breakdown is as follows: > > > > "subject CN", notBefore, "serial number", "highest bit index set > (1-based indexing)" > > > > "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63 > > "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61 > > "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63 > > "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63 > > "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63 > > "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, > 63 > > "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, > 63 > > "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63 > > "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63 > > exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61 > > expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62 > > exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63 > > expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63 > > reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61 > > reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60 > >
Re: DarkMatter Concerns
G’day Corey,
In respect to the previously issued constrained intermediates – can you clarify
where in RFC5280 Section 4.2.1.10 that the prohibition against a leading period
is specified for the name constraints?
I see in the RFC the specific sentence: “When the constraint begins with a
period, it MAY be expanded with one or more labels.” This appears to
contradict your assertion that leading period constraints violate 5280…
During the period that these intermediates were deployed, the browsers and
platforms dependent on these performed path processing exactly as expected with
this configuration.
Can you please illuminate the passage in the RFC where you feel a leading
period in a permitted subtree e.g. (“.ae”) as was used in the identified
intermediate certificates, is a violation??
Regards,
--
Scott Rea
On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via
dev-security-policy" wrote:
Furthermore, two of the intermediates issued to DarkMatter which chain to
QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10
(https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the
dNSName in the nameConstraints extension's permittedSubtrees field contains a
leading period (".ae"), which violates the hostname syntax specified in section
4.2.1.10. Therefore, these two intermediate certificates
(https://crt.sh/?id=23432430=cablint,
https://crt.sh/?id=19415522=cablint) are also mis-issued under the Baseline
Requirements.
I have sent a Certificate Problem Report to Digicert to notify them of
these findings, as these intermediates and DarkMatter-issued certificates chain
to roots under their control.
Scott Rea | Senior Vice President - Trust Services
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae
The information transmitted, including attachments, is intended only for the
person(s) or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
in error, please contact the sender and destroy any copies of this information.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
G’day Corey, I did not check your math, but is it possible that you are interpreting the serial number conversion output as an unsigned integer representation? If so, then I can understand your potential concern regarding the findings of your analysis. DarkMatter uses an EJBCA platform with the requisite setting for 64-bit random serial numbers and our source of entropy is a FIPS140 certified HSM, so I too was surprised by the findings you reported. However, during our investigation of this potential issue, we have thus far discovered that the platform appears to be compliant with the requisite standard, and the anomaly you are highlighting is potentially due just to the integer representation you are using in your calculations. RFC5280 (section 4.1.2.2) defines serialNumber to be a positive INTEGER, and X.690 defines INTEGER to consist of one or more octets and (specifically section 8.3.3) says the octets shall be a two’s complement binary number equal to the integer value. Using the two’s complementary representation means that the output of the octet conversion is a signed integer, and it could be positive or negative – the range of integers from 64-bit numbers being from –(2^63) to [+ (2^63)-1]. But since the RFC requires only positive integers, the 64-bits of output from the CSPRNG function must eventuate only in positive numbers, and negative numbers cannot be used. In two’s complement representation, the leading bit determines whether the number is positive or negative – for positive numbers, the leading bit will always be zero (if it’s a 1, then that represents a negative number which RFC5280 prohibits). So our findings are that the platform is indeed using 64-bit output from an appropriate CSPRNG for generating serialNumbers, and that the leading zero is exactly what is required to indicate that it is a positive number in two’s complement representation of the INTEGER, which is the requirement under RFC5280. Therefore our findings indicate that the serial number generation scheme used by DarkMatter in it’s certificate hierarchy does meet the requirements set forth in the Baseline Requirements, section 7.1. Regards, -- Scott Rea On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via dev-security-policy" wrote: On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote: > Hello, > Section 7.1 of the Baseline Requirements states that, "Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG". > > An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, and 12 end-entity interoperability/test certificates) in the DarkMatter certificate hierarchy currently listed in the inclusion request indicates that the hierarchy is likely not compliant with this requirement. Specifically, all 23 certificates have an 8-octet (64 bit) serial number, but the most significant bit (big-endian) of their serial numbers is 0. The probability that all 23 known certificates in the hierarchy having exactly 64 bits of output from a CSPRNG with a most significant bit value of 0 is 1 in 2^23, or 1 in 8,388,608, which would make this a highly extraordinary event. The far more likely case is that each certificate's serial number does not contain the requisite number of bits (64) output from a CSPRNG. > > A detailed breakdown is as follows: > > "subject CN", notBefore, "serial number", "highest bit index set (1-based indexing)" > > "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63 > "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61 > "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63 > "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63 > "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63 > "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 63 > "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 63 > "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63 > "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63 > exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61 > expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62 > exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63 > expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63 > reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61 > reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60 > revrd.ca.darkmatter.ae, 2018-07-05, 0D:C6:08:0C:4F:B4:76:63, 60 > revru.ca.darkmatter.ae, 2018-07-05, 6F:5A:8C:4F:54:FC:3A:E2, 63 > valed.ca.darkmatter.ae, 2018-07-05, 1E:40:E3:2D:DF:21:95:59, 61 > valeu.ca.darkmatter.ae, 2018-07-05, 65:84:D9:1D:F5:CE:C5:89, 63 >
Re: DarkMatter Concerns
On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective September
> 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers
> greater than zero (0) containing at least 64 bits of output from a CSPRNG".
>
> An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, and
> 12 end-entity interoperability/test certificates) in the DarkMatter
> certificate hierarchy currently listed in the inclusion request indicates
> that the hierarchy is likely not compliant with this requirement.
> Specifically, all 23 certificates have an 8-octet (64 bit) serial number, but
> the most significant bit (big-endian) of their serial numbers is 0. The
> probability that all 23 known certificates in the hierarchy having exactly 64
> bits of output from a CSPRNG with a most significant bit value of 0 is 1 in
> 2^23, or 1 in 8,388,608, which would make this a highly extraordinary event.
> The far more likely case is that each certificate's serial number does not
> contain the requisite number of bits (64) output from a CSPRNG.
>
> A detailed breakdown is as follows:
>
> "subject CN", notBefore, "serial number", "highest bit index set (1-based
> indexing)"
>
> "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63
> "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61
> "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63
> "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63
> "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63
> "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 63
> "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 63
> "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63
> "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63
> exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61
> expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62
> exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63
> expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63
> reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61
> reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60
> revrd.ca.darkmatter.ae, 2018-07-05, 0D:C6:08:0C:4F:B4:76:63, 60
> revru.ca.darkmatter.ae, 2018-07-05, 6F:5A:8C:4F:54:FC:3A:E2, 63
> valed.ca.darkmatter.ae, 2018-07-05, 1E:40:E3:2D:DF:21:95:59, 61
> valeu.ca.darkmatter.ae, 2018-07-05, 65:84:D9:1D:F5:CE:C5:89, 63
> 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
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=cablint,
Re: DarkMatter Concerns
This certificate already infested all major browsers. Removing it breaks a lot of pages and gives you Invalid certificate error. TOR, Chrome, Firefox... all infested. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
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). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
