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@xxxxxxxxxxx on behalf of openssl-users@xxxxxxxxxxxx> 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".
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
