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? >
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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
