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

2016-05-10 Thread Matt Caswell via RT 
This is intended behaviour for the certificate in question, so closing this
ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-12 Thread Erwann Abalea 
Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL 
> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff 
like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-12 Thread Erwann Abalea via RT 
Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL 
> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff 
like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-12 Thread Cristian Berneanu via RT 
FYI, I checked other machines that have a TPM device manufactured by STM,
but I could not find another with a serial number less than 20 bytes (I
guess they do padding in that case).
I also have a certificate from an Atmel device where I get a notice that
the serial number is negative.

For me personally, it would be perfectly fine if I could have a "relaxed
parsing" option that I could pass when I expect these kinds of broken
encodings.


On Fri, Feb 12, 2016 at 11:38 AM, Erwann Abalea 
wrote:

> Bonjour,
>
> Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL 
> a écrit :
>
> Again, you are right, but what's the lesser evil‎ - being unable to use
> the new OpenSSL because it refuses to deal with the cert that some
> dim-witten TPM maker screwed up, or accept a certificate with a (minor)
> violation of DER (but not of BER)? What bad in your opinion could happen if
> OpenSSL allowed parsing an integer with a leading zero byte (when it
> shouldn't be there by DER)?
>
>
> As shown yesterday, this INTEGER encoding isn’t even valid BER.
>
> Being liberal in what you accept, when dealing with crypto, gives you
> stuff like this:
> https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/
>
> Cordialement,
> Erwann Abalea
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
Testing the previous Github version of OpenSSL-1.1 produced encouraging
results (notice the leading zero, right where it belongs):

$ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
0:d=0  hl=2 l=   2 prim: INTEGER   :80
  02 02 00 80   ||
0004
$ dumpasn1 d.der
  0   2: INTEGER 128

0 warnings, 0 errors.
$




P.S. dumpasn1.c doesn’t seem to parse negative integers correctly:

$ x=-128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
0:d=0  hl=2 l=   1 prim: INTEGER   :-80
  02 01 80  |...|
0003
$ dumpasn1 d.der
  0   1: INTEGER 128
   :   Error: Integer has a negative value.

0 warnings, 1 error.
$ 


-- 
Regards,
Uri Blumenthal





On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.
>
>In BER, almost anything goes :)
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.

I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
cite the sources, might add the ASN.1 standard itself, and “ASN.1
Complete” by John Larmouth) that a leading zero *is* necessary and
required for a positive integer when its MSB is one (e.g., 0x80). In other
cases it indeed does not belong.

>In BER, almost anything goes :)

We are *explicitly* and *exclusively* discussing DER. Anything goes for
Bear. :-)

P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
first “valuable” byte was 0x59), so the leading zero byte did not belong.
But I hope OpenSSL-1.1 would properly process 0x02020080.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
>wrote:
>>On Wed Feb 10 21:59:12 2016, bcri...@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
 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
.
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
 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

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

2016-02-11 Thread Viktor Dukhovni 

> On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Testing the previous Github version of OpenSSL-1.1 produced encouraging
> results (notice the leading zero, right where it belongs):
> 
> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
> hexdump -C d.der
>0:d=0  hl=2 l=   2 prim: INTEGER   :80
>   02 02 00 80   ||
> 0004

There's no leading zero in this example.  Don't confuse zero nibbles
with zero octets.

-- 
Viktor.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Salz, Rich 
> Larmouth) that a leading zero *is* necessary and required for a positive
> integer when its MSB is one (e.g., 0x80). In other cases it indeed does not
> belong.

Agreed.  Perhaps I mis-read your note.  Sorry.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
>>On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL
>> wrote:
>> 
>> Testing the previous Github version of OpenSSL-1.1 produced encouraging
>> results (notice the leading zero, right where it belongs):
>> 
>> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
>> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der
>>&&
>> hexdump -C d.der
>>0:d=0  hl=2 l=   2 prim: INTEGER   :80
>>   02 02 00 80   ||
^^ this is the leading zero

>There's no leading zero in this example.

But there is - “00 80” rather than “80”.

>Don't confuse zero nibbles with zero octets.

Thank you, I don’t. :)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Salz, Rich 
If arbitrary leading zero's were allowed in DER, then the encoding wouldn't be 
*distinguished*, i.e., unique.

In BER, almost anything goes :)

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Richard Levitte 
Let's put this to rest, shall we?

: ; cat > checkasn1int.sh
#! /bin/sh

CMD="$@"

for x in "3003 02011F" \
 "3003 020180" \
 "3004 0202001F" \
 "3004 02020080"; do
echo Trying sequence $x
echo $x | xxd -r -ps | $CMD
done
: ; sh checkasn1int.sh openssl asn1parse -inform d -i
Trying sequence 3003 02011F
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :1F
Trying sequence 3003 020180
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :-80
Trying sequence 3004 0202001F
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :1F
Trying sequence 3004 02020080
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :80
: ; openssl version
OpenSSL 1.0.2f  28 Jan 2016
: ; sh checkasn1int.sh util/shlib_wrap.sh apps/openssl asn1parse -inform d 
-i
Trying sequence 3003 02011F
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :1F
Trying sequence 3003 020180
0:d=0  hl=2 l=   3 cons: SEQUENCE  
2:d=1  hl=2 l=   1 prim:  INTEGER   :-80
Trying sequence 3004 0202001F
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :BAD INTEGER:[001F]
Trying sequence 3004 02020080
0:d=0  hl=2 l=   4 cons: SEQUENCE  
2:d=1  hl=2 l=   2 prim:  INTEGER   :80
: ; util/shlib_wrap.sh apps/openssl version
OpenSSL 1.1.0-pre3-dev  xx XXX 
: ; 

Cheers,
Richard

In message  on Thu, 11 Feb 2016 19:37:18 +, 
"Blumenthal, Uri - 0553 - MITLL"  said:

uri> On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
uri>  wrote:
uri> 
uri> >If arbitrary leading zero's were allowed in DER, then the encoding
uri> >wouldn't be *distinguished*, i.e., unique.
uri> 
uri> I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
uri> cite the sources, might add the ASN.1 standard itself, and “ASN.1
uri> Complete” by John Larmouth) that a leading zero *is* necessary and
uri> required for a positive integer when its MSB is one (e.g., 0x80). In other
uri> cases it indeed does not belong.
uri> 
uri> >In BER, almost anything goes :)
uri> 
uri> We are *explicitly* and *exclusively* discussing DER. Anything goes for
uri> Bear. :-)
uri> 
uri> P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
uri> first “valuable” byte was 0x59), so the leading zero byte did not belong.
uri> But I hope OpenSSL-1.1 would properly process 0x02020080.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Erwann Abalea 
Bonjour,

Le 11 févr. 2016 à 20:25, Blumenthal, Uri - 0553 - MITLL 
> a écrit :

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
>
wrote:
On Wed Feb 10 21:59:12 2016, bcri...@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

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

2016-02-11 Thread Cristian Berneanu via RT 
The EK certificate is generated and burned into the TPM during
manufacturing. The extraction operation always returns the same certificate.

On Thu, Feb 11, 2016 at 11:16 PM, Stephen Henson via RT 
wrote:

> On Thu Feb 11 07:11:17 2016, bcri...@gmail.com wrote:
> > This is the Endorsement Key certificate extracted from a TPM device.
> >
>
> Does it always do that or is this just an oddity?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Peter Waltenberg 
The problem with making those little "Oh we'll allow it  for
interoperability' choices is that they may end up as security
vulnerabilities elsewhere. Particularly when there are multiple of them
made.

So - it is quite reasonable to reject a change like that because it's near
impossible to check all the little corner cases that it might expose.

Peter





From:   "Blumenthal, Uri - 0553 - MITLL via RT" <r...@openssl.org>
To: bcri...@gmail.com
Cc: openssl-dev@openssl.org
Date:   12/02/2016 10:13
Subject:        Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
    fails to parse x509 certificate in DER format
Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org>



Again, you are right, but what's the lesser evil‎ - being unable to use the
new OpenSSL because it refuses to deal with the cert that some dim-witten
TPM maker screwed up, or accept a certificate with a (minor) violation of
DER (but not of BER)? What bad in your opinion could happen if OpenSSL
allowed parsing an integer with a leading zero byte (when it shouldn't be
there by DER)?

Even in crypto (and that's the area I've been working in for quite a while)
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I
won't gain from this decision, whichever way it turns. ;-)

Sent from my BlackBerry 10 smartphone on the
Verizon Wireless 4G LTE network.
  Original Message
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Might I suggest that the right thing in this case would be to keep
generation strict, but relax the rules on parsing? "Be conservative in what
you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Peter Waltenberg via RT 
The problem with making those little "Oh we'll allow it  for
interoperability' choices is that they may end up as security
vulnerabilities elsewhere. Particularly when there are multiple of them
made.

So - it is quite reasonable to reject a change like that because it's near
impossible to check all the little corner cases that it might expose.

Peter





From:   "Blumenthal, Uri - 0553 - MITLL via RT" <r...@openssl.org>
To: bcri...@gmail.com
Cc: openssl-dev@openssl.org
Date:   12/02/2016 10:13
Subject:        Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
    fails to parse x509 certificate in DER format
Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org>



Again, you are right, but what's the lesser evil‎ - being unable to use the
new OpenSSL because it refuses to deal with the cert that some dim-witten
TPM maker screwed up, or accept a certificate with a (minor) violation of
DER (but not of BER)? What bad in your opinion could happen if OpenSSL
allowed parsing an integer with a leading zero byte (when it shouldn't be
there by DER)?

Even in crypto (and that's the area I've been working in for quite a while)
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I
won't gain from this decision, whichever way it turns. ;-)

Sent from my BlackBerry 10 smartphone on the
Verizon Wireless 4G LTE network.
  Original Message
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Might I suggest that the right thing in this case would be to keep
generation strict, but relax the rules on parsing? "Be conservative in what
you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL via RT 
Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) 
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I 
won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails 
toparse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
Again, you are right, but what's the lesser evil‎ - being unable to use the new 
OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker 
screwed up, or accept a certificate with a (minor) violation of DER (but not of 
BER)? What bad in your opinion could happen if OpenSSL allowed parsing an 
integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) 
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I 
won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: openssl-dev@openssl.org‎
Reply To: openssl-dev@openssl.org
Cc: Stephen Henson via RT; bcri...@gmail.com
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails 
toparse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL 
Might I suggest that the right thing in this case would be to keep generation 
strict, but relax the rules on parsing? "Be conservative in what you send, and 
liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the 
user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: bcri...@gmail.com
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to    
parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Blumenthal, Uri - 0553 - MITLL via RT 
Might I suggest that the right thing in this case would be to keep generation 
strict, but relax the rules on parsing? "Be conservative in what you send, and 
liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the 
user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: bcri...@gmail.com
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to    
parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Dr. Stephen Henson 
On Thu, Feb 11, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

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

I should've been a bit clearer. I should have said additional or superfluous
leading zeroes which is the cases here because there is a leading zero and the
MSB of the second octet is also zero. Others have referenced the relevant
sections of the standards that require that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Stephen Henson via RT 
On Thu Feb 11 07:11:17 2016, bcri...@gmail.com wrote:
> This is the Endorsement Key certificate extracted from a TPM device.
>

Does it always do that or is this just an oddity?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Kurt Roeckx via RT 
On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Kurt Roeckx 
On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation 
> strict, but relax the rules on parsing? "Be conservative in what you send, 
> and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-11 Thread Stephen Henson via RT 
On Thu Feb 11 21:38:18 2016, bcri...@gmail.com wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-10 Thread Stephen Henson via RT 
On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote:
> Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016"
>
> Command: "openssl x509 -inform der -in sample_ekcert.der"
>
> Result:
> "unable to load certificate
> 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal
> padding:a_int.c:223:
> 140618483803816:error:0D08303A:asn1 encoding
> routines:asn1_template_noexp_d2i:nested asn1
> error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF
> 140618483803816:error:0D08303A:asn1 encoding
> routines:asn1_template_noexp_d2i:nested asn1
> error:tasn_dec.c:648:Field=cert_info, Type=X509"
>

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.


The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain
leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter.

What was the certificate generated with?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-10 Thread Cristian Berneanu via RT 
Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016"

Command: "openssl x509 -inform der -in sample_ekcert.der"

Result:
"unable to load certificate
140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal
padding:a_int.c:223:
140618483803816:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF
140618483803816:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:tasn_dec.c:648:Field=cert_info, Type=X509"

Input file: see attachment.

Stable version works fine.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted



sample_ekcert.der
Description: application/x509-ca-cert
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-10 Thread Cristian Berneanu via RT 
This is the Endorsement Key certificate extracted from a TPM device.

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT 
wrote:

> On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote:
> > Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016"
> >
> > Command: "openssl x509 -inform der -in sample_ekcert.der"
> >
> > Result:
> > "unable to load certificate
> > 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal
> > padding:a_int.c:223:
> > 140618483803816:error:0D08303A:asn1 encoding
> > routines:asn1_template_noexp_d2i:nested asn1
> > error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF
> > 140618483803816:error:0D08303A:asn1 encoding
> > routines:asn1_template_noexp_d2i:nested asn1
> > error:tasn_dec.c:648:Field=cert_info, Type=X509"
> >
>
> 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.
>
>
> The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain
> leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is
> stricter.
>
> What was the certificate generated with?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev