[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-users
Subject: Leading 00 byte in ASN.1 DER encoding of unsigned integers with 1st bit set - Re: rfc5280 serialNumb
From: David von Oheimb <it () von-Oheimb ! de>
Date: 2023-11-07 20:04:46
Message-ID: 2de70a60-9258-8396-c6ff-99572103be3c () von-Oheimb ! de
[Download RAW message or body]
Just stumbled over this thread of July.
There are still some (cert etc.) viewer implementations, including parts
of OpenSSL and Mozilla,
that for certain unsigned integer fields (such as in key material or
cert serial numbers)
output any leading '00' byte as if it was part of the actual byte string
content,
even when needed just for ASN.1-internal encoding reasons.
Regarding the output of RSA/DSA/DH/EC key material in OpenSSL,
I filed a fix back in January 2019:
https://github.com/openssl/openssl/pull/8136
This happens to be my oldest OpenSSL PR that is still not merged,
which is just because it could possibly break third-party scripts.
In contrast, as often in my experience, some influential Mozilla folks
appear to not really understand the issue
and considered my related bug report and fix invalid:
https://bugzilla.mozilla.org/show_bug.cgi?id=1520923
although I even gave them the - correct - OpenSSL output of an X.509
cert serial number with 1st bit set as a reference.
David
On 23.07.23 21:52, Robert Moskowitz wrote:
> 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@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.
>
[Attachment #3 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Just stumbled over this thread of July.<br>
</p>
<p>There are still some (cert etc.) viewer implementations,
including parts of OpenSSL and Mozilla,<br>
that for certain unsigned integer fields (such as in key material
or cert serial numbers) <br>
output any leading '00' byte as if it was part of the actual byte
string content, <br>
even when needed just for ASN.1-internal encoding reasons.<br>
</p>
<p>Regarding the output of RSA/DSA/DH/EC key material in OpenSSL,<br>
I filed a fix back in January 2019: <a
href="https://github.com/openssl/openssl/pull/8136"
class="moz-txt-link-freetext">https://github.com/openssl/openssl/pull/8136</a><br>
This happens to be my oldest OpenSSL PR that is still not merged,<br>
which is just because it could possibly break third-party scripts.</p>
<p>In contrast, as often in my experience, some influential Mozilla
folks appear to not really understand the issue<br>
and considered my related bug report and fix invalid: <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1520923"
class="moz-txt-link-freetext">https://bugzilla.mozilla.org/show_bug.cgi?id=1520923<br>
</a>although I even gave them the - correct - OpenSSL output of an
X.509 cert serial number with 1st bit set as a reference.<br>
</p>
<p> David</p>
<p><br>
</p>
<p></p>
<div class="moz-cite-prefix">On 23.07.23 21:52, Robert Moskowitz
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07c263c0-98ec-7162-725d-bbcddd079e60@htt-consult.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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:<br>
<br>
<br>
<font face="monospace"> 0:d=0 hl=4 l= 331 cons:
SEQUENCE <br>
4:d=1 hl=3 l= 254 cons: SEQUENCE <br>
7:d=2 hl=2 l= 3 cons: cont [ 0 ] <br>
9:d=3 hl=2 l= 1 prim: INTEGER :02<br>
12:d=2 hl=2 l= 9 prim: INTEGER
:9F07C87244927FBE<br>
23:d=2 hl=2 l= 5 cons: SEQUENCE <br>
<br>
0:d=0 hl=4 l= 330 cons: SEQUENCE <br>
4:d=1 hl=3 l= 253 cons: SEQUENCE <br>
7:d=2 hl=2 l= 3 cons: cont [ 0 ] <br>
9:d=3 hl=2 l= 1 prim: INTEGER :02<br>
12:d=2 hl=2 l= 8 prim: INTEGER
:1BB3EC3B4F2E645C<br>
22:d=2 hl=2 l= 5 cons: SEQUENCE <br>
</font><br>
<br>
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.<br>
<br>
But it does increase the DER by a byte. Interestingly in this
specific case the PEM was the same size for both.<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/21/23 14:20, Erwann Abalea
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPHyGFFodCNu_fHZjmNLOQcR1kCKML=tZ-ZH+a+y4oPGPJRxMQ@mail.gmail.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div dir="ltr">On 8 bits, if the highest bit is set to 1, then
the value is between 0x80 and 0xFF.
<div>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).</div>
<div><br>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 21, 2023 at
8:00 PM Robert Moskowitz <<a
href="mailto:rgm@htt-consult.com" moz-do-not-send="true"
class="moz-txt-link-freetext">rgm@htt-consult.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
looked at a couple of certs. I might think that if the
first hex is <br>
"F" then the 1st bit is 1, but:<br>
<br>
<br>
<br>
8:d=2 hl=2 l= 3 cons: cont [ 0 ]<br>
10:d=3 hl=2 l= 1 prim: INTEGER :02<br>
13:d=2 hl=2 l= 9 prim: INTEGER
:FE0E6F3753087370<br>
<br>
8:d=2 hl=2 l= 3 cons: cont [ 0 ]<br>
10:d=3 hl=2 l= 1 prim: INTEGER :02<br>
13:d=2 hl=2 l= 9 prim: INTEGER
:AEB77AEE2A3CBCD3<br>
<br>
<br>
I am not seeing a difference in the serialNumber field
length.<br>
<br>
On 7/21/23 08:58, Robert Moskowitz wrote:<br>
> Per sec 4.1.2.2<br>
><br>
> Given the uniqueness requirements above, serial
numbers can be<br>
> expected to contain long integers. Certificate
users MUST be able to<br>
> handle serialNumber values up to 20 octets.
Conforming CAs MUST NOT<br>
> use serialNumber values longer than 20 octets.<br>
><br>
><br>
> At some point some years ago it was pointed out here
that serialNumber <br>
> OID encoding preappends 0x00 if the first bit is a 1.<br>
><br>
> Does this actually make the serialNumber a byte
longer? Or is this <br>
> only encoding? Thus IF that first bit is a 1,
obviously the OID value <br>
> is a byte longer. But when the serialNumber OID is
decoded is this <br>
> longer value returned or the original value?<br>
><br>
><br>
> I am girding up to debate an implementation where the
CP says <br>
> serialNumber MUST be unique, and their implementation
uses a 20-byte <br>
> SN. I don't think they take care at all about the
value of the 1st <br>
> byte. I doubt in their testing to date they have
generated a SN in <br>
> that range.<br>
><br>
> So how does the SN with the added byte get decoded?<br>
><br>
> thanks<br>
><br>
><br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Cordialement,
<div>Erwann Abalea.</div>
</div>
</div>
</blockquote>
<br>
</blockquote>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic