5

I have tried to issue a certificate beginning with 8 to F but I have found it is impossible, mostly due to the RFC:

The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.

So I would like to know if there is any actual reason not to do that beyond the "buggy ASN.1 implementation"?

TildalWave
  • 10,801
  • 11
  • 45
  • 84
kiBytes
  • 3,450
  • 15
  • 26

2 Answers2

9

Short answer: because RFC 3280, its predecessor, says so.

Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers.

X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length twos-complement form, in order to properly encode a non-negative integer which happens to have its leading bit (MSB) set, it must be padded with a leading zero, which in other circumstance is disallowed. The wording of X.690(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf‎ ) is such that the leading 9 bits of an integer must be inspected in order to verify the minimal form, thus allowing such positive integers to have leading 0 byte.

To quote Peter Gutmann

There's a second but: Historically many encoders have gotten the signedness of integers wrong, which means that (a) if you get a negative number (at least in the area of crypto, which I'm most familiar with) it's always an encoding error and never a deliberate use of a negative value, and (b) because of the widespread use of incorrect encoders, many decoders treat all integer values as unsigned. So while you can use negative values in theory, it's not a good idea in practice.

The correct determination of serial numbers is critical when it comes to revocation checks. Ambiguity is an enemy.

It seems to me that this is exactly the problem your encoder is having...

Community
  • 1
mr.spuratic
  • 7,937
  • 25
  • 37
  • 2
    It is really surprising something to become standarized mostly due to implementation faults. Thanks for your response. – kiBytes Feb 19 '14 at 07:06
0

Because a serial number is designed to be a non-negative incrementing number.

It's basically an inventory control code for a CA, and they are non-negative incrementing numbers in most inventory systems.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • This makes little to no sense. The current standard practice is to use a randomly generated value for the `serialNumber` in an X.509 certificate. – Adi Feb 18 '14 at 18:24
  • 4
    Current standard practice is unrelated to what it was *designed* for. – Stephen Touset Feb 18 '14 at 18:54