rfc5280 serialNumber question

[Robert Moskowitz]

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
>
>