[EXTERNAL] Re: rfc5280 serialNumber question.

[Robert Moskowitz]

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>