<div dir="ltr"><div dir="ltr">Dear Michael,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 2:41 AM Michael Richardson <<a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Not sure who Matt quoted, wrote:<br> >> 2. Can we do something with a bunch of hard-linked non-extendable<br> >> lists of internal NIDs?<br> >><br> >> For example, providing GOST algorithms always requires a patch to<br> >> extend 3-5<br> >> internal lists.<br> >> If it could be done dynamically, it will be great.<br>
<br>Matt then wrote:<br> > The simplest solution is to submit a PR to add your OIDs to OpenSSL,<br> > so that no furher out of tree patches are required.<br>
<br>Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</a>> wrote:<br> > Dynamic NIDs don't fit very well into the design, because NIDs are<br> > expected to be stable compile-time constants. We could perhaps<br> > reserve a range for "private-use", and "engines" could allocate new<br> > NIDs in the private space at runtime. The key question is whether<br> > such NIDs are global or valid only if returned to the same engine<br> > (provider, ...). If not global, the allocation might be static<br> > within the engine, and not require any locks.<br>
<br>Having stubbed my toe on some NID stuff, I must question exposting NIDs.<br>ruby-openssl used them in a dumb way that meant that adding extensions by OID<br>was broken until I removed some code.<br>
<br>I think that the #define/enum of NIDs should be made internal-only,<br>available as optimization to internal code only.<br>Your question then becomes, "are engines internal users", and I'd like the<br>answer to be no. I think that the openssl 3 changes suggest the same thing.<br></blockquote><div><br></div><div>The engines are _mostly_ external users. But sometimes, providing new algorithms, </div><div>there appear some parts that should go into the core part. And regulation creates similar problems.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All other users can call OBJ_obj2nid() or OBJ_txt2nid() to get a NID,<br>and we can figure out how to allocate things dynamically if this makes<br>sense. I don't know which APIs are currently NID-only.</blockquote><div><br></div><div>AFAIK, no external API, but there are some cases when external API does not cover all. </div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>