On Tue, Mar 12, 2019 at 4:57 PM Hector Martin 'marcan' <[email protected]> wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote: > > Note that even 7 bytes or less may still be valid - for example, if the > > randomly generated integer was 4 [1], you might only have a one-byte > serial > > in encoded form ( '04'H ), and that would still be compliant. The general > > burden of proof would be to demonstrate that these certificates were > > generated with that given algorithm you described above. > > > > [1] https://xkcd.com/221/ > > Not only that, but, in fact, any attempt to guarantee certain properties > of the serial (such that it doesn't encode to 7 bytes or less) *reduces* > entropy. > > In particular, > > 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a > CSPRNG with at least one bit in the highest byte set to 1 > > is, strictly speaking, not true. The best possible implementation for > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, > not 64. > > Now whether 0.57% of a bit worth of entropy matters for practical > purposes, and for BR compliance purposes, is another matter entirely, > but the point is that *any* subsequent filtering and rejection of > serials with certain properties only *hurts* entropy, it doesn't help it. > Oh, wow, I missed that comment when reading the pseudo-code. I would agree that filtering like appears to be an issue, similar for the reasons discussed. If it placed no restrictions on the highest byte, it would be evenly distributed, with 0 and previously-issued serials being treated as duplicates. I think we should treat this similar to the discussion of other CAs that ensured the highest bit was 0. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
