Steve Henson correctly pointed out that to change ASN1_TYPE_cmp() may not be
appropriate, as there could be cases when null pointer (absent list) means
something different from list being NULL.
To address that concern, I've made sure the workaround applies only to the case
when two algorithms a
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?
-
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
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, whi