On Fri, 29 Dec 2017 07:24:31 +0100 Jakob Bohm via dev-security-policy <[email protected]> wrote:
> 3. Or would the elimination in #2 reduce the entropy of such serial > numbers to slightly less than 64 bits (since there are less than > 2**64 allowed values for all but the first such certificate)? The tremendous size of the numbers involved means that in practice this makes no difference. A single collision only becomes likely (not certain, merely likely) over the course of issuing billions of such certificates. If I'm right a decision to append a further byte (say 0x42) to the serial number any time a collision would otherwise occur would have the same _visible_ effect as just throwing away the colliding number and choosing another, ie no effect because collisions don't actually happen in practice. [ In my day job I maintain a system which uses a 64-bit hash of URLs to index them. We are conscious that by the pigeon hole principle this hash could sometimes confuse two URLs and there's a safeguard to detect that. Despite processing millions of URLs this way every day, for several years, the safeguard has never triggered outside of unit tests. Perhaps one day it will. ] It wouldn't surprise me if some CAs actually don't check #2 at all. Since collisions are so unlikely with truly random serial numbers it might well never come up, even if you explicitly looked for it, so that this "failure" might have no detectable consequence for a smaller CA even over the course of decades of operation. So far as we know ISRG / Let's Encrypt are issuing the largest volume from a single subCA of any CA, but I believe they just use a lot more than 64-bits, which is a rational choice here to avoid answering tricky philosophical questions about integers. I would commend this approach to other CAs wondering how best to comply. Final thought: The linter should check for at least 64-bits, but it can't check for true randomness (doing so may be literally impossible in fact) so anything further should be left for human observers and/or CA auditors. Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
