[openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Thu Feb 11 19:25:54 UTC 2016

>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <rt at openssl.org>
>wrote:
>>On Wed Feb 10 21:59:12 2016, bcristi at gmail.com wrote:
>>As the error is suggesting it doesn't like the serialNumber in the
>>certificate.
>> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
>> get:
>>
>> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
>>DA
>> : Error: Integer '00 59 ...' has non-DER encoding.
                      ^^^^^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

>>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
>>contain
>> leading zeroes. 

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others
<http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key
> had to say about this:

	The private key values are encoded as ASN.1 INTEGERs, which are signed
values
	in two's complement format. The leading zero byte is necessary when the
MSB of
	the (unsigned) RSA key value is set. Having the MSB set without a leading
zero
	byte would mean a negative value.

	The ASN.1 specs are free and are linked from Wikipedia
	<http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One>.
	The relevant section here is in X.690, "8.3 Encoding of an integer value”.

In short, the problem is that without that leading zero there is no way to
tell a negative integer from a positive integer.

Here’s how the *current* OSS Nokalva ASN.1 compiler
<http://asn1-playground.oss.com/> DER-encodes integers. First, the ASN.1
spec (had to wrap in a sequence to avoid jostling with the compiler, as I
don’t remember how to write definitions of single primitive types)

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
   Tst ::= SEQUENCE {
       value INTEGER (-256..257)
   }
END

And playing with different integer values in the given range:

my-tst Tst ::= 
{ 
   value 127
}

Encodes to 3003 02017F (relevant parts: tag 02, len 01, value 7f)

However this:

my-tst Tst ::= 
{ 
    value 128
}

Encodes to 3004 02020080 (integer tag 02, len *02*, and value 00 80) and
for a VERY good reason! If you try to decode the following

3003020180 (what you seem to suggest - the number without the leading
zero) you get:

ASN1STEP: Decoding PDU #1 :

Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3

value INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
-128

Successfully decoded 5 bytes.
rec1value Tst ::= 
{
    value -128
}

Notice that minus.

>>OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter.

I say OpenSSL-1.1 got this wrong, and needs to be fixed.

P.S. Sticking the value of the integer provided provided by Cristian into
OSS ASN.1 DER decoder gave:

         OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 22
D0022E: Integer or enumerated value needlessly long; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 20
    2147483647
S0012E: Decoding of PDU #1 failed with the return code '5'.

Trimming the leading zero from the value (as for *this* particular integer
value that zero is not needed to disambiguate between + and -):

          OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 21
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 19
    2147483647
S0012E: Decoding of PDU #1 failed with the return code '10'.

The following might also be useful (attempting to encode/decode integer
value 128).

Schema

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
  Human ::= INTEGER (0..257)
END

Data: 020180

Decoding:

         OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :

D0076S: A negative unsigned integer encountered; check PDU #1 'Human'.
S0012E: Decoding of PDU #1 failed with the return code '2'.

The error is correct: decoded value by the rules of decoding is negative,
but the type restriction said it had to be unsigned, aka non-negative.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160211/5b49860b/attachment.bin>