It seems this thread has diverged a bit from its stated purpose, the determination of the question of mis-issuance of a set of certificates which have (possibly) longer than allowed serial numbers.
I raised a question as to the history of the selection of the 20 bytes limit for serial numbers and it was pointed out that this is the size of an SHA-1 hash. As the principal use of serial these days is double-duty as both unique identifier within an issuer DN as well as an early-in-the-certificate-document insertion of unpredictable entropy for mitigation of pre-image collision attacks, the continued merits of the notion of serial number as needing to store an SHA-1 value are certainly questionable. I merely raise the point that IF the framers of the 20 bytes rule did, in fact, simultaneously intend that arbitrary SHA-1 hash results should be able to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER encoded integer field value must be a positive integer and that insertion of a leading 0x00 byte to ensure that the high order bit would be 0 (thus regarded as a positive value per the coding), THEN it must follow that at least in the minds of those who engineered the rule, that the inserted 0x00 byte must not be part of the 20 byte maximum size of the value AS legitimate SHA-1 values of 20 bytes do include values where the high order bit would be 1 and without pre-padding the proper interpretation of such a value would be as a negative integer. The language of the 20 bytes rule is actually ambiguous. If that ambiguity is coupled with a possible (prior) intent that it be possible to store a SHA-1 output as the serial number, it's more than just ambiguous. If it is essential that the total encoded representation within the certificate structure not exceed 20 bytes, I would think that a clarification in line with Peter Bowen's proposal in this thread might be appropriate. _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy