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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email] on behalf of [hidden email]> 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".
 

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
> On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>    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).

I've opened https://github.com/openssl/openssl/issues/8553 to track
this issue.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Viktor Dukhovni
> Sent: Thursday, March 21, 2019 14:07
> To: [hidden email]
>
> > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <[hidden email]>
> wrote:
> >
> >    2.  Emit a "harmless" default OID (such as 0.0), returning to
> >     the behaviour prior to 1.0.1i

What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer.

I'm by no means an ASN.1 expert, so this may be a dumb idea.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

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

Blumenthal, Uri - 0553 - MITLL
Hmm... Registering an OID dedicated to express this case should be feasible, and perfectly within the ASN.1 rules. One question - where in the OID tree would it live, as offhand I don't have any idea. It can't be too deep down, and also, it better be fairly short.  

From the ASN.1 point of view - there's nothing dumb in this idea. There's plenty of MIB objects expressing/representing all kinds of things - might as well add this.



´╗┐On 3/22/19, 12:34, "openssl-users on behalf of Michael Wojcik" <[hidden email] on behalf of [hidden email]> wrote:

    > From: openssl-users [mailto:[hidden email]] On Behalf Of
    > Viktor Dukhovni
    > Sent: Thursday, March 21, 2019 14:07
    > To: [hidden email]
    >
    > > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <[hidden email]>
    > wrote:
    > >
    > >    2.  Emit a "harmless" default OID (such as 0.0), returning to
    > >     the behaviour prior to 1.0.1i
   
    What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer.
   
    I'm by no means an ASN.1 expert, so this may be a dumb idea.
   
    --
    Michael Wojcik
    Distinguished Engineer, Micro Focus
   
   
   
   

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Richardson

Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
    > Hmm... Registering an OID dedicated to express this case should be
    > feasible, and perfectly within the ASN.1 rules. One question - where in
    > the OID tree would it live, as offhand I don't have any idea. It can't
    > be too deep down, and also, it better be fairly short.

In some vendor PEN space if 0.0 is a bad idea.
I'm sure that someone has one, or I can volunteer a number from mine.
I don't see why it has to be short if it never leaves in a legitimate CSR.

    > From the ASN.1 point of view - there's nothing dumb in this
    > idea. There's plenty of MIB objects expressing/representing all kinds
    > of things - might as well add this.

+1.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment
12