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@xxxxxxxxxxx on behalf of Michael.Wojcik@xxxxxxxxxxxxxx> wrote:
> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of
> Viktor Dukhovni
> Sent: Thursday, March 21, 2019 14:07
> To: openssl-users@xxxxxxxxxxx
>
> > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
