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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Alex Gaynor via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matt Palmer via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... Peter Gutmann via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Jakob Bohm via dev-security-policy
      • Re: Certificates ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Matthew Hardeman via dev-security-policy
  • Re: Certificates with inva... okaphone.elektronika--- via dev-security-policy

Reply via email to