> Von: Ryan Sleevi <r...@sleevi.com> > Betreff: Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to > 63 bit serial numbers) > > On Mon, Mar 11, 2019 at 1:18 PM Buschart, Rufus via dev-security-policy > <dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > wrote: > > > [...] 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. > > Oof, > > With the requirement to be a positive integer greater than zero, you can > think of the serial number space as the one of /natural > numbers/ (or, because zero is excluded, /whole numbers/) whose DER encoding > is less than or equal to twenty bytes. The sequential > requirement is 'meant' to apply to serial numbers being constructed in order > of that sequence of whole numbers - that is, 1, 2, 3 is > sequential in the set of whole numbers, although 1, 3 would be out of > sequence with respect to the set of valid whole number serials. > > If I understand the question correctly, you're describing a situation in > which the serial number construct follows a strict ordering, and > thus itself forms a sequence of whole numbers which maintain sequential order > of the set of all valid whole numbers, but which does > not include each whole number, provided that no two certificates are issued > in the same millisecond. If two certificates are issued in > the same millisecond, the 64-bits of entropy create a probability that the > certificates will not appear in sequential (monotonically > increasing) order. Is that correct?
Yes, exactly > Put differently, the question is whether or not the algorithm, as specified, > needs to consider two certificates issued at different times > (and, presuming time is linear and increasing, so too will the serial > numbers), or whether it can/should consider certificates issued at > the same time (and thus be probabilistically out of sequential ordering) > > Just making sure I've phrased and framed it correctly. You got it totally right. Now basically we have two possible definitions of "sequential serial numbers": 1) A CA generates "sequential serial numbers" if every generated serial number meets the following criteria: serialNumber(n) = serialNumber(n-1)+1, with n being the n-th number of generated serial numbers 2) A CA generates "sequential serial numbers" if every generated serial number meets the following criteria: serialNumber(n) > serialNumber(n-m) (or serialNumber(n) < serialNumber(n-m) ), with n being the n-th number of generated serial numbers and m any whole number smaller n Since choice 1 is a logical consequence of "containing 64 bits of random data", I was always under the impression, that choice 2 was meant by the BRGs. If choice 1 is meant, then I think the requirement of being 'non-sequential' is just some lyrical sugar in the BRGs. Maybe there is a third definition of "sequential" that I haven't thought of? To put in a concrete example: There is a CA that generated the following serial numbers: 1843319960437720643048278653969636 on 2019-01-11 09:53:47 UTC 1843319960437694134774632325152679 on 2019-01-10 13:49:21 UTC 1843319960437689654817618007073336 on 2019-01-10 09:05:57 UTC 1843319960437665986305459379269472 on 2019-01-09 09:24:59 UTC 1843319960437653534927818400454844 on 2019-01-08 10:24:51 UTC 1843319960437625653787354520462187 on 2019-01-08 08:40:14 UTC 1843319960437610711593417697551974 on 2019-01-08 08:39:37 UTC Are those serial numbers sequential? I think, yes, they are, but I admit, there are good arguments to say, no, they are not. 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
