Dear mdsp! I really like reading this discussion about 64 vs. 63 bits and how to read the BRGs as it shows a lot of passion by all of us in the PKI community. Never the less, in the discussion, I miss one interesting aspect. The BRGs not only speak about 64 bits as output from a CSPRNG but also about serial numbers being "non-sequential". But nowhere the BRGs define the exact meaning of "non-sequential". I always read this as serial numbers being totally random, but I know there is at least one CA out there that constructs its serial numbers like this:
serialNumber = timeInMS() + random(64) + 'constant_suffix' Serial numbers constructed like this are strict monotonously rising but never the less contain 64 bits of random data. Do we consider those as "non-sequential"? We can't even go by the definition in the dictionary, because according to that (at least the one I consulted), every list of numbers is 'sequential', as one number comes after another. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Freyeslebenstr. 1 91058 Erlangen, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > -----Ursprüngliche Nachricht----- > Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> Im > Auftrag von Daymion Reynolds via dev-security-policy > Gesendet: Montag, 11. März 2019 18:00 > An: mozilla-dev-security-pol...@lists.mozilla.org > Betreff: Re: EJBCA defaulting to 63 bit serial numbers > > On Monday, March 11, 2019 at 8:57:27 AM UTC-7, Ryan Sleevi wrote: > > I don’t think there’s anything inherently wrong with an approach that > > uses a fixed prefix, whether of one bit or more, provided that there > > is at least > > 64 bits of entropy included in the serial prior to encoding to DER. > > > > This means a scheme with guarantees a positive INTEGER will generate > > *encoded* serials in the range of one bit to sixty five bits, of the > > goal is to use the smallest possible amount of entropy. > > > > However, as you note, this issue only arises when one uses the > > absolute minimum. A robust solution is to use 159 bits, the maximum > > allowed. This helps ensure that, even when encoded, it will not exceed > > 20 bytes, this avoiding any client interpretation issues regarding > > whether the 20 bytes mentioned in 5280 are pre-encoding (the intent) > > or post-encoding (as a few embedded libraries implemented). > > > > Note, however, even with 159 bits of entropy, it’s still possible to > > have a compressed encoding of one byte, due to zero folding. Using a > > one bit prefix in addition to the sign bit (thus, two fixed bits in > > the serial) can help ensure that a leading run of zero bits are not folded > > when encoding. > > Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit in > a 64 bit serial number would result in less than 64 bits of > entropy. If you are going to fix a significant bit it must be beyond the > 64th bit. If your 64 bit serial number does not contain 1's in the > significant byte, as long as you still write 64 full bits of data to the cert > with 0's left padded, then the desired entropy is achieved and is > valid. CAs should keep this in mind while building their revocation lists. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
