Hi Jakob, On Thursday, March 7, 2019 at 7:30:03 PM UTC+1, Jakob Bohm wrote: > In the cause of the other discussion it was revealed that EJBCA by PrimeKey > has apparently: > > 1. Made serial numbers with 63 bits of entropy the default. Which is > not in compliance with the BRs for globally trusted CAs and SubCAs.
This has been the default setting since 2001, predating Ballot 164 quite some. At the time this was more than sufficient, and we hadn't reviewed it. > 2. Mislead CAs to believe this setting actually provided 64 bits of > entropy. I'm presuming that you're not assigning any intention to the above. We have always been open with that EJBCA generates 64 bit serial numbers, compliant with RFC5280 (3280 back then) and X.690. We weren't, at start of the previous thread, aware of the requirements made by CABF Ballot 164 as we've only been active in following the proceedings for the last couple of years, but as vendors we've historically viewed the responsibility configuring EJBCA correctly to meet existing standards as up to the end customer. We've been aware of the BR requirement for some time now, but we were not aware of the detailed previous discussion related to 63 vs 64 bits that has been held. > 3. Discouraged CAs from changing that default. This is not true in the least. Serial number size has been configurable since at least 2008 (long before B164). There is a note in the configuration file about not changing it unless you understand what you're doing, but that pertains to not lowering it below 64 bits. Raising the SN size (and thus entropy) has in fact been done by several of our customers (in response to B164, or for whatever other reason). > This raises 3 derived concerns: > > 4. Any CA using the EJBCA platform needs to manually check if they > have patched EJBCA to comply with the BR entropy requirement despite > EJBCAs publisher (PrimeKey) telling them otherwise. > Maybe this should be added to the next quarterly mail from Mozilla to > the CAs. A patch isn't required as the value is configurable in a config file, and in response to the concerns raised here we've added functionality for changing the serial number size without requiring a change to the config files. Again, I don't agree with your statement that we've told anybody that EJBCA, by default configuration, complies with the BR, as much configuration is needed to issue BR compliant certificates. A correct technical description of serial numbers is documented in the configuration file. The documentation did not consider the above discussion regarding entropy, as 64 bit serial numbers were leagues past the entropy requirements prior to 2016. The documentation absolutely does encourage the end user to feel free to use larger serial number sizes, EJBCA is used in a lot of non public CA use cases, and as such ability to configure according to BR requirement or not is a key feature. It does bear mentioning that the purpose of requiring serial number entropy was to mitigate against pre-imaging attacks against SHA-1, something which today has no bearing whatsoever. While I'm not claiming that there will never ever be a collision found against SHA256, but I hope you understand that this is a compliance issue against a requirement that for now has no has any security impact. > 5. Is it good for the CA community that EJBCA seems to be the only > generally available software suite for large CAs to use? While I agree that diversity is good for any ecosystem, I would remind you that a majority of CA's don't actually run our software, and many run their own proprietary solutions. The availability of EJBCA is likely due to the fact that the vast majority of our code is FOSS (and the rest if always available to customers), which is partly due to our wish to make PKI available to all, and partly because we encourage external inspection of our implementation. > 6. Should the CA and root program community be more active in ensuring > compliance by critical CA infrastructure providers such as EJBCA and > the companies providing global OCSP network hosting. Absolutely, and I would say that many already are. We don't have any goal other than making EJBCA as compliant as possible, and have always aimed to lay a step ahead of existing standards. Since 2016 (as a part of maturing as a software vendor) we changed focus in how we handle requirements work by actively following various standards orgs (including CABF), instead of receiving requirements from our customers. Cheers, Mike _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
