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

[Viktor Dukhovni]

On Thu, Mar 21, 2019 at 05:22:24PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> > On the DER padding front, the minimal
> > working suffix is 7 bytes:

Apparently I can't count today, clearly the suffix is 8 bytes.

> > 
> >    30 03    -- Length 3 sequence
> >    06 01 00 -- OBJECT ID: 0.0
> >    03 01 00 -- empty BIT STRING
> > 
> > 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.

His order of "preference" is:

    1.  Return failure from i2d_ASN_OBJECT(), which then percolates
	up to failure to encode the containing structure.

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

    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 am curious what other OpenSSL developers and users would like to
see happen.  Any of the above?  Or something else?  The present
behaviour seems wrong to me, because we're silently generating
invalid structures with missing required fields (when encoding
incompletely initialized structures).

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?

-- 
	Viktor.