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

[Blumenthal, Uri - 0553 - MITLL]

First, let me prefix that while I don't want to badmouth anybody, even incompetence cannot excuse deliberately generating bad/unparsable encoding. That's one of the cases when the cure is clearly worse than the disease.

On 3/21/19, 13:58, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:
    > > On the OpenSSL side, having found that we emit dubious encodings
    > > of structures with an (unspecified) null OID element, I am considering
    > > whether it would make sense to encode them as a zero-length (invalid,
    > > but faithful) ASN.1 OBJECT:
    > > 
    > >    06 00
    > > 
    > > *and* decode these back to a zero length NID_undef object.
    
    After discussing this idea with a friend, I am less enthusiastic
    about this option.  His point is that if OpenSSL starts emitting
    invalid empty OIDs as a way to support encoding incompletely
    initialized structures, this could contaminate the ecosystem with
    subsequent new downstream work-arounds in other implementations.

I don't see how it is worse than what's there now.
    
    His order of "preference" is:
    
        1.  Return failure from i2d_ASN_OBJECT(), which then percolates
    	up to failure to encode the containing structure.

That would be the correct but strict behavior: OID is required, therefore no OID -> no encoding. Just fail (hopefully with an explanatory error code, and documented!)

            2.  Emit a "harmless" default OID (such as 0.0), returning to
    	the behaviour prior to 1.0.1i

I'm OK with that, and it's probably more acceptable than (1), though OID "0.0" is not the same as "no-OID". I wonder if there's ever a case when OID "0.0" can appear in this construct? If so, then (2) is unacceptable, otherwise I don't know.

But the original "fix" (can't call it that but in quotes and with big tongue-in-cheek) was there for a reason, however misguided the actual change turned out to be. What was the reason for changing this (original) behavior? Just desire for "purity" (....), or something more tangible/reasonable?
    
        3.  Emit the invalid empty OID (06 00) in the expectation that
    	this would not be something that other decoders would have
    	to support.  That is, it would only be used, as in this case,
    	to serialize and deserialize objects *within* an application,
    	and there would be no pressure on other implementations to
    	follow suit.

I'm OK with (3) too. In fact, this would probably be my first preference - and yes, implementations that care to support use cases with no-OID would have to support this. But at least they won't have a broken parser on their hands.
    
    Failing in i2d_ASN1_OBJECT() is unlikely to do harm, because the
    current invalid output is not better, and we've not seen any
    complaints until now in ~5 years of OpenSSL 1.0.2 deployment.
    So use of i2d on partially created objects looks rather rare,
    and perhaps explicit failure is better than any ad-hoc output?

Failing in i2d_ASN1_OBJECT() would be my second preference. My first preference would be your (3). I can live with (2), but I don't like it much because substituting a valid OID for a no-OID is "slippery".
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190321/919bab69/attachment.bin>