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

Fri Mar 22 18:12:44 UTC 2019

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" <openssl-users-bounces at openssl.org on behalf of Michael.Wojcik at microfocus.com> wrote:

    > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
    > Viktor Dukhovni
    > Sent: Thursday, March 21, 2019 14:07
    > To: openssl-users at openssl.org
    >
    > > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
    > 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

-------------- 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/20190322/6a6cdd2a/attachment.bin>