G’day folks, we appreciate the many suggestions made on the list to strengthen the entropy of random serialNumbers.
One challenge we face currently is that our platform (which does support higher entropy) but only supports this at a global level. So if we make a global change, then ALL our CAs will use the larger serialNumbers and this would have an impact for example on CAs which are in completely different hierarchies to those used for Public Trust to have to also adopt the change (and for CA’s used for constrained environments e.g. IoT, the size of each extension has an impact). However, we have been working with our platform provider and can now report that effective beginning of next week, DarkMatter will move to using random 128-bit serial numbers for all our Public Trust certificates. The remaining question is what should be done if anything about existing certificates with 64-bit serialNumbers? Regards, -- Scott Rea On 2/25/19, 7:51 PM, "dev-security-policy on behalf of Tim Shirley via dev-security-policy" <[email protected] on behalf of [email protected]> wrote: There are other ways to achieve a guarantee of non-collision besides re-generating. For example, we incorporate the timestamp of issuance into the serial number alongside the random bits. You could also incorporate a sequential value into your serial number. Both methods serve to guarantee that, even in the extremely unlikely event that you duplicate the random component of your serial number in 2 different certificates, you still have 2 different serial numbers. But at least 64 bits of whatever is produced needs to be entropy, and if any "acceptability test" is applied after the random value is generated and actually rejects a value, then you've reduced your number of effective bits of entropy. From what has been described here, it seem clear that in this case what's actually being generated is 63 bits of entropy. Any process truly generating 64 bits of entropy should be producing serial numbers with 9 octets ~50% of the time. Regards, Tim Shirley Software Architect t: +1 412.395.2234 www.securetrust.com <http://www.securetrust.com> Introducing the Global Compliance Intelligence Report <https://www2.trustwave.com/Global-Compliance-Intelligence-Report-Registration.html> On 2/25/19, 3:58 AM, "dev-security-policy on behalf of Scott Rea via dev-security-policy" <[email protected] on behalf of [email protected]> wrote: I think it reasonable to expect that EVERY implementation of a compliant CA software is doing this post-processing to ensure the intended serialNumber has not already been used, and this is not something unique to EJBCA. As such, every CA out there will have some process that requires post-processing of whatever value is returned with a possibility to have to repeat the process if there is a collision. Scott Rea | Senior Vice President - Trust Services Tel: +971 2 417 1417 | Mob: +971 52 847 5093 [email protected] The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
