You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We parse serial numbers of certificate into hex string stored in database. The parsing currently ignores leading zero, and should append them properly.
According to @jcjones, there should only ever be a single leading zero, as while ASN.1 permits INTEGER to do insane things, the WebPKI (because of DER-form) only lets there be one leading zero, corresponding to the first nybble of the most significant byte. In this case, the actual ASN.1 is:
02 04 07 27 7F 52
so it's cool and correct to show that leading zero. It's ASN.1-legal to encode something more like:
02 04 00 07 DE AD
but that's not the minimal form of the integer, so it is not DER-encoded, and thus shouldn't pass one of CertLint / CABLint (I forget which one).
Another important example here would be something like 02 03 00 F0 0F where the leading 00 indicates that this is a positive value, not negative. (Serial numbers must be positive under RFC 5280, but some CAs have issued certificates where the serial number's leading bit is set, meaning it is actually negative.)
A good rule might be to show exactly the contents of the value portion of the tag-length-value of the serial number encoding. That is, for the certificate in question, we might display "07277F52". For the example I
added, we might display "00F00F".
The text was updated successfully, but these errors were encountered:
We parse serial numbers of certificate into hex string stored in database. The parsing currently ignores leading zero, and should append them properly.
According to @jcjones, there should only ever be a single leading zero, as while ASN.1 permits INTEGER to do insane things, the WebPKI (because of DER-form) only lets there be one leading zero, corresponding to the first nybble of the most significant byte. In this case, the actual ASN.1 is:
02 04 07 27 7F 52
so it's cool and correct to show that leading zero. It's ASN.1-legal to encode something more like:
02 04 00 07 DE AD
but that's not the minimal form of the integer, so it is not DER-encoded, and thus shouldn't pass one of CertLint / CABLint (I forget which one).
@mozkeeler added:
Another important example here would be something like 02 03 00 F0 0F where the leading 00 indicates that this is a positive value, not negative. (Serial numbers must be positive under RFC 5280, but some CAs have issued certificates where the serial number's leading bit is set, meaning it is actually negative.)
A good rule might be to show exactly the contents of the value portion of the tag-length-value of the serial number encoding. That is, for the certificate in question, we might display "07277F52". For the example I
added, we might display "00F00F".
The text was updated successfully, but these errors were encountered: