[openssl-users] Fwd: Problem with encoding a CRL's signing algorithm

[Dr. Stephen Henson]

On Sat, Feb 14, 2015, Benny Baumann wrote:

> 
> I want to encode a new CRL's (X509_CRL_new), currently invalid,
> Signing algorithm (i2d_X509_ALGOR( crl->siging_alg, ... ) ) and
> restore that with "d2i_X509_ALGOR( &crl->signing_alg, ...)"
> afterwards. Restoring of the algorithm works fine in OpenSSL
> 1.0.1.f, but fails in OpenSSL 1.0.1j and 1.0.1l. This is probably
> because the "i2d" function encodes the (invalid) Signing algorithms
> slightly different in the different versions. This happens, because
> the invalid signing algorithm is represented slightly different in
> the internal structure.
> In version 1.0.1f the invalid algorithm is encoded as sequence with
> an object id with length 1 and content "00" ( -> 30 03 06 01 00). In
> the newer versions (1.0.1j and 1.0.1l)  the invalid algorithm gets
> encoded as sequence with an object id of length 0 ( -> 30 02 06 00).
> This new encoding causes the "d2i" function to fail. Now the "d2i"
> function nulls the "sig_alg". This causes a "X509_CRL_verify" to
> cause a segfault.
> 
> Is this behavior expected? Am I doing something wrong? Is there a
> problem with what "X509_CRL_new" does (setting different
> "UNDEFINED"-ObjectId-Objects)?
> For better clarifying my problem, I have attached a small example
> code that creates such a CRL, tries to verify it (what will fail,
> but not crash), does the i2d, d2i re-setting of the Algorithm and
> re-calls X509_CRL_verify which now crashes in 1.0.1j and 1.0.1l, but
> works fine in 1.0.1.f.
> 

Arguably the bug is in the i2d functions which should refuse to encode
a structure which hasn't been properly initialised.

If you set the algorithm OID to a valid value (which you can change later)
this should work in all versions of OpenSSL.

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