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" <dev-security-policy-boun...@lists.mozilla.org on behalf > 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 > > 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&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 > 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
Hi Scott, Thank you for the prompt response and the transparency in regard to the software stack used by your CA operations. The detailed response that you provided will hopefully make it easier to highlight the disconnect we have. You are correct that ASN.1 INTEGERs are 2's-complement signed integers. Every DarkMatter-issued certificate that I've encountered (both those chained to Digicert roots as well as your roots as well as the DarkMatter root certificates themselves) has an INTEGER data size of exactly 8 octets (64 bits). By outputting 64 random bits from the CSPRNG and then coercing the most significant bit to 0 (to make the INTEGER value positive, as you mentioned) means that the CA software is discarding one bit from the CSPRNG (since the most significant bit is being coerced to 0) and embedding only 63 bits of CSPRNG output in the certificate serial number. Section 7.1 of the Baseline Requirements requires at least 64 bits output from a CSPRNG, so I do not believe the serial number generation scheme that you have described is compliant. Thanks, Corey _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
