# [EXTERNAL] Re: rfc5280 serialNumber question.

Robert Moskowitz rgm at htt-consult.com
Sun Jul 23 19:52:07 UTC 2023

```While on my flight to IETF, I made 2 certs identical in content other
than the serial numbers.  You can clearly see the 0x00 prepended:

0:d=0  hl=4 l= 331 cons: SEQUENCE
4:d=1  hl=3 l= 254 cons:  SEQUENCE
7:d=2  hl=2 l=   3 cons:   cont [ 0 ]
9:d=3  hl=2 l=   1 prim:    INTEGER           :02
12:d=2  hl=2 l=   9 prim:   INTEGER           :9F07C87244927FBE
23:d=2  hl=2 l=   5 cons:   SEQUENCE

0:d=0  hl=4 l= 330 cons: SEQUENCE
4:d=1  hl=3 l= 253 cons:  SEQUENCE
7:d=2  hl=2 l=   3 cons:   cont [ 0 ]
9:d=3  hl=2 l=   1 prim:    INTEGER           :02
12:d=2  hl=2 l=   8 prim:   INTEGER           :1BB3EC3B4F2E645C
22:d=2  hl=2 l=   5 cons:   SEQUENCE

And after spending lots of times reading the appropriate sections of
5280, I realized I was making this harder in my mind than needed. So the
encoding puts 0x00 in front of a type Integer.  The decoder just rips it
off and makes sure the resultant value is positive.

But it does increase the DER by a byte.  Interestingly in this specific
case the PEM was the same size for both.

On 7/21/23 14:20, Erwann Abalea wrote:
> On 8 bits, if the highest bit is set to 1, then the value is between
> 0x80 and 0xFF.
> In your examples, the highest octet of the integer has its highest bit
> set (0xFE in the first example, 0xAE in the second), and therefore the
> DR encoding added a heading 00, making the real length 9 octets (l=9
> on third column).
>
>
>
> On Fri, Jul 21, 2023 at 8:00 PM Robert Moskowitz <rgm at htt-consult.com>
> wrote:
>
>     I looked at a couple of certs.  I might think that if the first
>     hex is
>     "F" then the 1st bit is 1, but:
>
>
>
>          8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
>         10:d=3  hl=2 l=   1 prim:    INTEGER           :02
>         13:d=2  hl=2 l=   9 prim:   INTEGER :FE0E6F3753087370
>
>          8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
>         10:d=3  hl=2 l=   1 prim:    INTEGER           :02
>         13:d=2  hl=2 l=   9 prim:   INTEGER :AEB77AEE2A3CBCD3
>
>
>     I am not seeing a difference in the serialNumber field length.
>
>     On 7/21/23 08:58, Robert Moskowitz wrote:
>     > Per sec 4.1.2.2
>     >
>     >    Given the uniqueness requirements above, serial numbers can be
>     >    expected to contain long integers.  Certificate users MUST be
>     able to
>     >    handle serialNumber values up to 20 octets. Conforming CAs
>     MUST NOT
>     >    use serialNumber values longer than 20 octets.
>     >
>     >
>     > At some point some years ago it was pointed out here that
>     serialNumber
>     > OID encoding preappends 0x00 if the first bit is a 1.
>     >
>     > Does this actually make the serialNumber a byte longer? Or is this
>     > only encoding?  Thus IF that first bit is a 1, obviously the OID
>     value
>     > is a byte longer.  But when the serialNumber OID is decoded is this
>     > longer value returned or the original value?
>     >
>     >
>     > I am girding up to debate an implementation where the CP says
>     > serialNumber MUST be unique, and their implementation uses a
>     20-byte
>     > SN.  I don't think they take care at all about the value of the 1st
>     > byte.  I doubt in their testing to date they have generated a SN in
>     > that range.
>     >
>     > So how does the SN with the added byte get decoded?
>     >
>     > thanks
>     >
>     >
>
>
>
> --
> Cordialement,
> Erwann Abalea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230723/0cc60a2e/attachment.htm>
```