Am 19.01.2015 um 05:29 schrieb Uri Blumenthal via RT:
Well, technically youre correct - but from semantic point of view,
how different is an empty list, and a list presented as ASN.1 NULL?
Dont we have an empty list in both cases? And arent these two the
only two ways to represent an empty
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?
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
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:
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,
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
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
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
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?
--
