<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>