On Saturday, March 9, 2019 at 3:44:12 AM UTC+1, Matthew Hardeman wrote: > I know this isn't the place to bring a BR ballot, but I'm not presently a > participant there. > > I present alternative language along with notes and rationale which, I put > forth, would have resulted in a far better outcome for the ecosystem than > the issues which have arisen from the present BR 7.1 subsequent to ballot > 164. > > I humbly propose that this would have been a far better starting point, for > reasons I discuss in notes below. > > Effective as of Month Day, Year, CAs shall generate a certificate serial > numbers as herein specified: > > > 1. The ASN.1 signed integer encoded form of the certificate serial > number value must be represented as not less than 9 bytes and not more than > 20 bytes. [Note 1] > 2. The hexadecimal value of the first byte of the certificate serial > number shall be 0x75. [Note 2] > 3. The consecutive 64 bits immediately following the first byte of the > encoded serial number shall be the first 64 bits of output of an AES-128 > random session key generation operation, said operation having been seeded > within random data to within its design requirements. [Note 3] > 4. The remaining bytes of the encoded serial number (the 10th through > 20th bytes of the encoded serial number), to the extent any are desired, > may be populated with any values. [Note 4] > > Notes / Rationale: > > Note 1. The first bullet point sets out a structure which necessarily > requires that the encoded form of the serial number for all cases be at > least 9 bytes in length. As many CAs would have been able to immediately > see that their values, while random, don't reach 9 bytes, each CA in that > case would have had an easy hint that further work to assess compliance > with this BR change would be necessary and would definitely result in > changes. I believe that would have triggered the necessary investigations > and remediations. To the extent that it did not do so, the CAs which > ignored the change would be quickly identifiable as a certificate with an 8 > byte serial number encoding would not have been valid after the effective > date. > > Note 2. A fixed value was chosen for the first byte for a couple of > reasons. First, by virtue of not having a value of 1 in the highest order > bit, it means that ASN.1 integer encoding issues pertaining to sign are > mooted. Secondarily, with each certificate issuance subsequent to the > effective date of the proposal, a CA which has not updated their systems to > accommodate this ballot but does use random number generation to populate > the certificate serial has a probability of 127/128 of revealing that they > have not implemented the changes specified in this ballot. > > Note 3. CAs and their software vendors are quite familiar with > cryptographic primitives, cryptographic keys, key generation, etc. Rather > than using ambiguous definitions of randomness or bits of entropy or output > of a CSPRNG, the administration of a CA and their software vendors should > be able to be relied upon to understand the demands of symmetric key > generation in actual practice. By choosing to specify a symmetric block > cipher type and key size in common use, the odds of an appropriate > algorithm being selected from among the large body of appropriate > implementations of such algorithms greatly reduces odds of low quality > "random" data for the serial number. > > Note 4. Note 4 makes clear that plenty of space remains for the CA to > populate other information, be it further random data or particular data of > interest to the CA, such as sequence numbers, date/time, etc. > > Further notes / rationale: > > In supporting systems whose databases may support only a 64 bit serial > number in database storage, etc, it is noteworthy that the serial number > rules I specified here only refer to the encoded form which occurs in the > certificate itself, not any internal representation in an issuance > database. Because the first byte is hard coded to 0x75 in my proposal, > this doesn't need to be reflected in a legacy system database, it can just > be implemented as part of the certificate encoding process. > > Strategically, certificates which would conform to the proposal I've laid > out here would obviously and facially be different from any previously > deployed system which routinely utilized 8 byte encodings, meaning that > every CA previously generating 8 byte serials would have an obvious signal > that they needed to dig into their serial number generation methodologies. > > By tying the generation of high quality random data to fill the serial > number to algorithms and procedures already well known to CAs and to their > vendors, auditors, etc, my proposal enhances the odds that the required > amount of random unpredictable bits actually be backed by a mechanism > appropriate for the use of cryptography. > > If anyone thinks any of this has merit, by all means run with it. I > disclaim any proprietary interest (copyright, etc) that I might otherwise > have had by statute and declare that I'm releasing this to the public > domain. > > Thanks, > > Matt
FWIW, the easiest would've been to remove "positive" aspect of serials. Who really cares? A random number is a random number. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
