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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
