On Monday, August 7, 2017 at 5:20:13 PM UTC-5, Ryan Sleevi wrote: > This is entirely unnecessary and would present serious stability issues due > to backwards compatibility. > > It may not be appropriate for this thread - discussing specific misissuances > - but there is zero benefit from extending the serial number, and obvious > serious detriment to the wide variety of applications - including, of course, > NSS and CryptoAPI - that specifically expect serial numbers to be less than > or equal to 20 bytes, when encoded. > > I appreciate your multiyear perspective, but given that it provides no > articulated value, and of which significant discussion around the limits of > other fields, such as commonName, are both relevant and informative, it would > merely be change for change sake.
One question: the choice of 20 bytes of serial number is an unusual length for an integer type. It's not a nice clean power of 2. It doesn't align to any native integer data type length on any platform I'm aware of. Does the history of the choice of the 20 byte length actual owe to an attempt to make the serial size capable of encompassing an SHA-1 hash output? The reason that I ask is that IF the intent in the choice of the length of 20 bytes was intentional for purpose of facilitating the output of an SHA-1 hash operation, this would speak FOR the argument that the leading 0x00 byte prepend (in cases of a leading 1 bit in the serial number value) would NOT be counted in the length. There are certainly plenty of SHA-1 hash values which would have a leading 1 bit. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
