Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Annie Yousar via RT
Am 19.01.2015 um 05:29 schrieb Uri Blumenthal via RT: Well, technically you’re correct - but from semantic point of view, how different is an empty list, and a list presented as ASN.1 NULL? Don’t we have an empty list in both cases? And aren’t these two the only two ways to represent an empty

[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 04:49:27 2015, u...@mit.edu wrote: Does the consensus on the list agree with my statement of the problem, and the proposed fix? I hope we all agree that semantically parameter list presented as ASN.1 NULL is equivalent to an empty parameter list, and should be treated as such?

[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 09:30:24 2015, a.you...@informatik.hu-berlin.de wrote: RFC 4055 as well as RFC 5754 do not make this difference, both say: When any of these four object identifiers appears within an AlgorithmIdentifier, the parameters MUST be NULL. Implementations MUST accept the parameters

[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 14:40:32 2015, steve wrote: The problem is that the two fields containing the signature algorithm do not match. The current 'x509' utility can't show this difference (I have an option I'm testing which will). It is possible to use the cms command diagnostic output though:

[openssl-dev] [openssl.org #3666] [PATCH] build with no-ts fails

2015-01-19 Thread s.resc...@avm.de via RT
Hello, Fix build of apps without ts (define OPENSSL_NO_TS) Regards Sebastian -- Mit freundlichem Gruß Sebastian Reschke AVM GmbH Sebastian Reschke Internetworking Telefon 030 39976-794 s.resc...@avm.de www.avm.de AVM Audiovisuelles Marketing und Computersysteme GmbH, Alt-Moabit 95,

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Rob Stradling via RT
On 19/01/15 14:47, Stephen Henson via RT wrote: On Mon Jan 19 14:40:32 2015, steve wrote: The problem is that the two fields containing the signature algorithm do not match. The current 'x509' utility can't show this difference (I have an option I'm testing which will). Steve, while you're

[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 16:19:50 2015, rob.stradl...@comodo.com wrote: Steve, while you're there... I've been caught out a few times in the past because the 'x509' utility displays the outer signature algorithm in the place where it should display the inner signature algorithm. This is fine when they

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Uri Blumenthal via RT
Steve, you’ve made several good points. But please consider: The problem is that the two fields containing the signature algorithm do not match. But they do according to RFC 5754 - I interpret it as declaring that in this particular case (optional parameters of AlgorithmIdentifier) NULL is

Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Uri Blumenthal via RT
Also, the way I read the current code (crypto/asn1/a_type.c, line 120 - it would (incorrectly) reject a certificate where both algorithms are encoded with absent parameter lists: if (!a || !b || a-type != b-type) return -1; I think we all agree that such a certificate would be valid/legal? --