Re: Survey of (potentially noncompliant) Serial Number Lengths
On Mon, 25 Mar 2019 22:16:27 + Rob Stradling via dev-security-policy wrote: > 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. Thanks for creating this report Rob! I used the following query to estimate the serial number entropy of every CA which has issued more than 1,000 certificates: SELECT issuer_ca_id,(SELECT COUNT(*) FROM (SELECT unnest(bit_position_sums)/(cert_count::float) AS ratio) subq WHERE ratio >= 0.45 AND ratio <= 0.55) AS entropy_estimate FROM serial_number_entropy_20190325 WHERE cert_count > 1000 ORDER BY issuer_ca_id; (This query considers a bit "random" if it's 1 between 45% and 55% of the time.) Fortunately, this did not find any CA not already listed in Rob's spreadsheet. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
Doug: You'll need to connect directly to the certwatch database using a tool like psql: psql -h crt.sh -p 5432 -U guest certwatch Here's Rob's announcement of direct database access: https://crt.sh/forum?place=msg%2Fcrtsh%2FsUmV0mBz8bQ%2FK-6Vymd_AAAJ On Tue, Mar 26, 2019 at 11:34 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Rob, > > I'm sure you provided this info somewhere, but I can't figure our where the > new summary table (named serial_number_entropy_20190325) is located. Is it > somewhere on your Google Doc, or somewhere else? > > > https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjC > Fn6lKoc/edit#gid=1093195185 > <https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit#gid=1093195185> > > > > -Original Message- > From: dev-security-policy > On > Behalf Of Rob Stradling via dev-security-policy > Sent: Monday, March 25, 2019 6:16 PM > To: Hector Martin 'marcan' ; > mozilla-dev-security-pol...@lists.mozilla.org > Cc: Kurt Roeckx > Subject: Re: Survey of (potentially noncompliant) Serial Number Lengths > > 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 +, 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 > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Survey of (potentially noncompliant) Serial Number Lengths
Rob, I'm sure you provided this info somewhere, but I can't figure our where the new summary table (named serial_number_entropy_20190325) is located. Is it somewhere on your Google Doc, or somewhere else? https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjC Fn6lKoc/edit#gid=1093195185 -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-policy Sent: Monday, March 25, 2019 6:16 PM To: Hector Martin 'marcan' ; mozilla-dev-security-pol...@lists.mozilla.org Cc: Kurt Roeckx Subject: Re: Survey of (potentially noncompliant) Serial Number Lengths 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 +, 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
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 +, 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
Re: Survey of (potentially noncompliant) Serial Number Lengths
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 +, 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. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 17:05, Kurt Roeckx wrote: > On Mon, Mar 18, 2019 at 03:30:37PM +, 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! -- 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
Re: Survey of (potentially noncompliant) Serial Number Lengths
On Mon, Mar 18, 2019 at 03:30:37PM +, 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? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote: > On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > >> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: >> If any other CA wants to check theirs before someone else does, then now is surely the time to speak up. >>> >>> Someone else is in the process of checking... ;-) >> >> The purpose of this survey is to flush out any further CAs that are (or >> have been) noncompliant with BR 7.1 but have not yet disclosed an >> incident. The report now also includes issuing CAs whose certificates have not been disclosed to the CCADB, which of course is permitted for technically-constrained intermediates. (Many thanks to the person who pointed out this oversight to me). > Columns A and B are currently empty. They are intended to hold a > Bugzilla URL and the date on which the bug was filed. > > Jonathan Rudenberg has offered to review the disclosures that have been > posted by CAs so far (thanks Jonathan!), so I've given him edit rights > to the spreadsheet. Jonathan has finished filling in Columns A & B for all of the disclosures he's seen so far. >> Having scanned the crt.sh database, I have produced the following >> spreadsheet. It covers all certificates known to crt.sh where the >> notBefore date is between 30th September 2016(*) and 22nd February >> 2019(**), and where the issuing CA... >> - is currently trusted by Mozilla to issue serverAuthentication >> certificates, and >> - has issued at least 1 certificate with a <64-bit serial number. >> >> https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing >> >> 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. >> >> For some issuing CAs, the sample sizes are too small to be able to draw >> any conclusions. >> >> >> (*) This date was chosen because BR 7.1 says: >> "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." >> >> (**) This is when Wayne started the discussion about DarkMatter, which >> is what prompted the discovery that many CAs were falling short of BR 7.1. > -- 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
Re: Survey of (potentially noncompliant) Serial Number Lengths
On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote: > On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote: >> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote: > >>> If any other CA wants to check theirs before someone else does, then now is >>> surely the time to speak up. >> >> Someone else is in the process of checking... ;-) > > The purpose of this survey is to flush out any further CAs that are (or > have been) noncompliant with BR 7.1 but have not yet disclosed an > incident. Columns A and B are currently empty. They are intended to hold a Bugzilla URL and the date on which the bug was filed. Jonathan Rudenberg has offered to review the disclosures that have been posted by CAs so far (thanks Jonathan!), so I've given him edit rights to the spreadsheet. > Having scanned the crt.sh database, I have produced the following > spreadsheet. It covers all certificates known to crt.sh where the > notBefore date is between 30th September 2016(*) and 22nd February > 2019(**), and where the issuing CA... > - is currently trusted by Mozilla to issue serverAuthentication > certificates, and > - has issued at least 1 certificate with a <64-bit serial number. > > https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing > > 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. > > For some issuing CAs, the sample sizes are too small to be able to draw > any conclusions. > > > (*) This date was chosen because BR 7.1 says: > "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." > > (**) This is when Wayne started the discussion about DarkMatter, which > is what prompted the discovery that many CAs were falling short of BR 7.1. -- 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
