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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
