Hi, Since EJBCA as a product was mentioned we thought we could chime in with some background and updates.
EJBCA was possible the first (certainly one of the first) CA products to use random serial numbers. From the very beginning, 64 bit random serial numbers, from a CSPRNG, were used. This was back in the days when the opinion was that sequential serial numbers had to be used. We had some work convincing some users that random was better than sequential. By default 8 bytes (64 bits) were used, as it's a nice power of 2 number. Back then longer serial numbers were frowned upon and there were product out there that could not even parse 16 byte serial numbers, so 8 bytes was a good choice that was compatible. As years went by we introduced the possibility to use longer serial numbers, through a configuration setting at build time. This setting is no convenient to use (automatically persisted across upgrades etc) in our Appliance and cloud platforms, and we had on the roadmap to remedy this with a more use friendly setting. A very strong goal of EJBCA, and PrimeKey, is to be standard compliant with both open standards and regulations, and thus we are not completely satisfied with debating 63 vs 64 bits. We are planning to release a fix version with a convenient per CA setting, and default to larger serials, in short time. Any existing CA will be easily configured to use between 4 and 20 octets serial numbers for future issuance. Serial numbers must be compliant with RFC5280 and X.690, which is the test we do on the output from the CSPRNG, only using compliant ones. https://jira.primekey.se/browse/ECA-4991 In addition to random serial numbers, EJBCA checks for collisions, so even in the very unlikely event of equal serial numbers being generated, no certificates with duplicated serial numbers should be issued from a CA based on the EJBCA software. By comparison, collisions do happen regularly in testing when using 32 bit serial numbers (and are averted), so the underlying checks function as we expect. Looking back at the origin to when public CAs moved form sequential to random serial numbers we believe this originated from the weakness in SHA1, making a preimage attack at least theoretically possible against SHA1. EJBCA was very early on supporting SHA256 as well. To our knowledge there are no known preimage attacks against SHA256, correct us if we're wrong. In other words, we do not consider this a security issue, but (only) a compliance issue. Cheers, Tomas Gustafsson (CTO) and Mike Agrenius Kushner (PO EJBCA) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
