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

[Stephen Henson via RT]

On Mon Jan 19 04:49:27 2015, uri at 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?
>

The problem is that the two fields containing the signature algorithm do not
match.

>From RFC5280:

4.1.2.3. Signature

...

This field MUST contain the same algorithm identifier as the
signatureAlgorithm field in the sequence Certificate (Section
4.1.1.2).

Now whether "the same algorithm identifier" means "identical" or "the same
meaning" is debatable. Currently it goes with the former and if that is taken
to be the case the certificate presented is encoded incorrectly.

The question is whether an OpenSSL workaround should be added to tolerate this.
Before this change OpenSSL completely ignored the signature field (so it could
contain anything) and only used the signatureAlgorithm field.

In general the ASN.1 NULL value and absent can be very different depending on
the ASN.1 structure being represented and "empty" can have a third distinct
meaning.

Example: imagine an OPTIONAL field where "NULL" represents a status value of
some sort. In that case an absent field would indicate no status available
while a NULL would indicate a specific status.

So in general changing ASN1_TYPE_cmp in the proposed fashion is not a good
idea.

In the very specific case of a certificate and certain digest algorithms absent
and NULL do have the same meaning.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org