On 12/03/2019 21.10, Mike Kushner via dev-security-policy wrote: >>> There are no, and has never been any, 63 bit serial numbers created by >>> EJBCA. >> >> ... lead me to significantly reduce my trust in those making them, and >> their ability to correctly interpret security-critical standards in the >> future. Not everyone gets things right the first time, but owning up to >> problems, understanding the technical issue at hand, and accepting >> responsibility is a basic tenet of earning community trust. > > I'm sorry you feel that way, but here's the thing. EJBCA produces whatever > length serial numbers you request from it, restricted to an even octet and > within the span of 4 to 20. EJBCA set to produce 8 octet serial numbers will > produce exactly 64 bit serial numbers, including the MSB. Are you suggesting > that a logical behavior for a 8 octet serial number would be to produce a 9 > octet serial number and pad the first 7 bits? > EJBCA will produce exactly the serial number you've specified, and give you > as much entropy as your serial length allows.
It's clear that multiple CAs made a configuration mistake here, and in general when multiple users make the same mistake when configuring software, that points to a usability problem in the software. Your statement is just shoving the entirety of the issue on CAs, while picking the interpretation most favorable to EJBCA. While the ultimate responsibility certainly lies with the CAs, it is not helpful for EJBCA to be so dismissive of the subject. We can make several accurate statements about EJBCA configured to an 8-octet serial number size (the default): - It generates serial numbers with 63 bits of entropy (or negligibly less, if we consider the duplicate-removal code) - It generates serial numbers from 1 to 2**63 - 1 - It generates serial numbers with 63 bits of effective output from a CSPRNG (the MSB having been coerced to zero, and thus effectively eliminated; that this is done by "trying until you get lucky" is an irrelevant implementation detail and has no bearing on the result) - It generates 8-byte serial numbers in encoded DER form (which is 64 bits worth of DER). In other words, only after DER encoding does the serial number become 64 bits in length. The statement "There are no, and has never been any, 63 bit serial numbers created by EJBCA." presumes that bit length is being measured at one specific point consistent with what EJBCA is actually doing, which may not be what users expect. I would in fact expect that if software is taking N bits of output from a CSPRNG (with the goal of providing N bits of entropy), that it would then encode it as a positive integer in DER, which indeed requires adding an extra zero octet to contain the sign bit when the MSB of the original value is 1. In fact, I would dare say that the output size is less likely to be relevant to users than the amount of entropy contained within, and that if a fixed output size is desired, a solution much less likely to result in people shooting themselves in the foot is to prepend a fixed constant byte 0x01<=0x7f to the serial before encoding. The EJBCA configuration file defaults state, verbatim: > # The length in octets of certificate serial numbers generated. 8 octets is a > 64 bit serial number. > # It is really recommended to use at least 64 bits, so please leave as > default unless you are really sure, > # and have a really good reason to change it. > # Possible values: between 4 and 20 > # Default: 8 > #ca.serialnumberoctetsize=8 Considering: 1) The BRs require 64 bits of output from a CSPRNG (which can only be reasonably interpreted by anyone familiar with the subject as as 64 bits of entropy; anything else is just 'creative interpretation') 2) The configuration file *explicitly* discourages changes. 3) All references are to "64 bits", with no mention that this refers to the *encoded* serial number and, thus, one of those bits is always zero Then it's not surprising that multiple CAs made the same mistake; heck, I probably would've done the same too, without reviewing the code. > EJBCA is a general CA implementation with multiple use cases, so it's not > built to specifically conform to cabf requirements. As Ryan Sleevi pointed > out - It is up to the end customer to understand their own requirements, and > to understand that a 64 bit signed integer can in no way or fashion contain > 64 bits of entropy. > > Unless you're going under the presumption that the MSB doesn't count as a > part of the serial number (and I've never seen an RFC or requirement pointing > to that being the case, EJBCA does not produce 63 bit serial numbers. The MSB is part of the serial number *encoding*. It is part of the serial number field as encoded in a DER certificate. It is not part of the *number* itself, the integer. For example, the MSB has no meaning when certificate serial numbers are e.g. expressed in integer decimal notation. A 64-bit positive integer expressed in decimal is a number from 0 to 18446744073709551615, a range of which only half is covered by the serial numbers generated by EJBCA in this configuration. I am not claiming that EJBCA made a catastrophic mistake here. This is merely a consequence of the fact that serial numbers, as an abstract numerical entity, and serial numbers, as an encoded DER field, are not the same thing and do not have the same length. It was unclear which interpretation was used where. What I'm saying is that merely sticking to the most convenient interpretation for you and deflecting all responsibility for how we ended up here is not productive, and does not scream trustworthiness. The various actors in the WebPKI need to strive for a secure environment, not act adversarially. This includes both acting in good faith (e.g. not attempting to pursue "creative interpretations"), but also, equally, recognizing when actions and decisions may have unexpectedly and unintentionally contributed to a problem, and making changes to eliminate that possibility in the future. -- Hector Martin "marcan" ([email protected]) Public Key: https://mrcn.st/pub _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
