On Saturday, 9 March 2019 03:44:12 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]
Is it still important that the random bits are not all zero? Because that seems to be omitted here. And if it is then the next question is: is it still important that the entropy of the whole thing is at least 64 bits? For if that is the case then you will need at least one more bit in the random part because of the exclusion of the all zeroes value, which reduces entropy to slightly below 64 bits. CU Hans _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
