Return "Error" for Certificates issued after Sep 30, 2016 with serial numbers under 64bits of entropy

[dzacharo]

According to the Baseline Requirements Section 7.1 "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".

[mpalmer]

The problem with entropy checks is that you can't just error on any certificate with a serial less than 2^64, because a CSPRNG can quite legitimately produce a stream of bits where the first N bits are zero. Conversely, just because a serial is greater than 2^64 doesn't demonstrate that it was generated with 64 bits of CSPRNG output.

To have any sort of examination of entropy, you need to examine a number of certificates from the same source, and even then you can't "prove" (in the same sense as most other BRs) that a CSPRNG wasn't used, only demonstrate that it is staggeringly unlikely that a CSPRNG was used, on the basis of statistical probability -- but you need to examine multiple certificates to do that.

[dzacharo]

Correct. I wasn't aiming on the entropy since it is almost impossible to verify without evaluating a number of certificates from the same Issuer. However, the current cablint.rb implementation (lines 78-80):

if sa != :weak && c.serial.num_bits < 20
messages << 'W: Serial numbers should have at least 20 bits of entropy'
end

makes an effort to calculate the bits, so this is the part that should probably be updated to reflect the current BRs. In any case, I leave it up to the author @pzb :)

[pzb]

The existing check for 64-bits is coded as a check that the value has at least one bit set in the 8th or later byte. If a CA is using a RNG and trying to get exactly 64 bits, they have a 1/256 chance of this warning being incorrect. I agree that trying to measure entropy given a single serial number is basically impossible, but I think a warning with <0.4% false positive seems reasonable.

[mpalmer]

Hmm... given the volume of certificates that (most) CAs put out, false positives on one in every 256 certificates seems like a straight road to alert fatigue hell. If certlint were just used by CAs for internal QC, and it was only those "bare-minimum" CAs had to deal with the fallout, it wouldn't be so bad -- it might encourage them to fix their derpy systems. However, since a major consumer of certlint output is publicly-available services like crt.sh, I'd hate for certlint to get a reputation of "oh, that thing's always complaining about useless things, you can ignore it". It would undo a lot of the great work that's been put into certlint if people stopped trusting that a certlint problem report was always legit.

[robstradling]

@pzb Since "to measure entropy given a single serial number is basically impossible", how about downgrading this lint from WARNING to INFO?

[robstradling]

Just chatted offline with @dzacharo. We'd like to propose the following:

• ERROR for serial number lengths <= N-bits.
• INFO for serial number lengths > N-bits and < 64-bits.
  (where N is 32, or 48, or somewhere inbetween)