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

Peter Waltenberg via RT rt at openssl.org
Fri Feb 12 00:25:07 UTC 2016


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" <rt at openssl.org>
To:	bcristi at gmail.com
Cc:	openssl-dev at 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-bounces at 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 at openssl.org‎
Reply To: openssl-dev at openssl.org
Cc: Stephen Henson via RT; bcristi at 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 +0000, 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160212/f2ef220e/attachment.gif>


More information about the openssl-dev mailing list