On Thursday, March 14, 2019 at 11:54:52 PM UTC+1, James Burton wrote:
> Let's Encrypt CA software 'Boulder' is open source for everyone to browse
> and check for issues. All other CAs should follow the Let's Encrypt lead
> and open source their own CA software for everyone to browse and check for
> issues. We might have found the serial number issue sooner.
> 
> Thank you,
> 
> Burton

Dude, EJBCA has been open source long enough to be able to legally vote and 
have a driver's license. Literally. But I agree, and we are open source for 
exactly that reason. 

I will add though, and stress, that this was not an issue with how EJBCA 
generates serial numbers. EJBCA still produces serial numbers with the max 
entropy for a given serial number length, as configured in number of octets. If 
you set EJBCA to use 20 octets you'll get 159 bits of entropy, the max 
available without breaking the RFC, and it's been that way since 2014. 

To save people time, by the way, here you go:
https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java

This was not an issue with the source, it was an issue with the end user's 
understanding of what it means to define an SN length as given number of of 
octets, how integer octets are defined in x690, and what entropy that can be 
derived. That is all a documentation failure on our end - we could have been 
more explicit, and we could have reached out more. 

There's also the faulty assumption that SN length = entropy. As we've seen, 
many other CA implementations produce SNs with far less entropy than their 
length would allow. I'm not saying that there's anything inherently wrong with 
that, but it illustrates the danger of making assumptions. 

As we didn't follow cabf at the time we weren't fully aware of the severity of 
the problem, and assumed that affected parties understood their configurations 
and raised the SN length.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to