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
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
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?
--
