i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Viktor Dukhovni]

> On Mar 20, 2019, at 9:35 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> Your github issue notes a change from 1.0.1 to 1.0.2, not a change
> within the 1.0.2 patch release series...
> 
> Changes of behaviour between 1.0.1 and 1.0.2 were not off limits.
> 
> When testing a short program to reproduce the reported symptoms
> I see the same output encoding (BAD OBJECT) with both 1.0.1 and
> 1.0.2.  For me, it is only 0.9.8 and 1.0.0 that generate the "0" OID.

The change dates back to:

  https://github.com/openssl/openssl/commit/38a503fb8adaad331b8a67aaa9eb2fa915113ed0

which first appeared in OpenSSL 1.0.1i.  It was cherry-picked onto the
1.0.2 branch:

   https://github.com/openssl/openssl/commit/ff4cfc4c588c41d5e8d2d530231bc36cbc525add

The effect of this is that "NID_undef" generates an empty ASN.1 value, rather
than an OID of "0.0".  Single component OIDs are not representable in ASN.1
BER/DER since the OID encoding combines the first elements as a single value.

Encoding "NID_undef" (uninitialized OID) as 0.0 isn't right, because there is no
OID, and we're pretending to have an OID of 0.0.  Of course not encoding anything
isn't great either, we're then skipping an element of the enclosing structure and
generating incorrect ASN.1 for the containing structure.

Really what could/should probably happen here, is that i2d should fail, because
the structure specifies an object that has no ASN.1 encoding.

-- 
	Viktor.