On 18/03/2019 21:11, Hector Martin 'marcan' wrote: > On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote: >> On 18/03/2019 17:05, Kurt Roeckx wrote: >>> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via >>> dev-security-policy wrote: >>>> >>>> When a value in column E is 100%, this is pretty solid evidence of >>>> noncompliance with BR 7.1. >>>> When the values in column E and G are both approximately 50%, this >>>> suggests (but does not prove) that the CA is handling the output from >>>> their CSPRNG correctly. >>> >>> Sould F/G say >= 64, instead of > 64? >> >> Yes. Fixed. Thanks! > > Perhaps it would make sense to separate out <64, ==64, >64? > > 100% "64-bit" serial numbers would indicate an algorithm using 63 bits > of entropy and the top bit coerced to 1.
Even better than that (and many thanks to Andrew Ayer for suggesting this idea)... To enable folks to do more thorough statistical analysis, I've produced another, richer summary table (named serial_number_entropy_20190325) on the crt.sh DB where each row contains... - the CA ID. - a count of the total number of unique serial numbers. - 160 counts, representing the number of times a given serial number bit is 1. (Serial numbers of <20 octets were left-padded with 0x00 bytes). This report covers all serial numbers in certs known to crt.sh where: - there is an unrevoked serverAuthentication trust path to a Mozilla built-in root. - the notBefore date is between 2018-04-01 and 2019-02-22. Duplicate serial numbers (i.e., precertificate/certificate pairs) are deduplicated. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
