<div dir="ltr"><div dir="ltr">Dear Dr Paul,</div><div dir="ltr"><br></div><div>I think this change is somewhere in a gray zone. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 1:37 PM Dr Paul Dale <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</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"><div style="overflow-wrap: break-word;">I don’t think that that new OIDs or NIDs are considering breaking.  Changing existing ones definitely is, but that’s an entirely different proposition.<div><br></div><div><br></div><div>Pauli<br><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">-- <br>Dr Paul Dale | Cryptographer | Network Security & Encryption <br>Phone +61 7 3031 7217<br>Oracle Australia</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><br class="gmail-m_7177905700595543375Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On 25 Feb 2019, at 5:02 pm, Dmitry Belyavsky <<a href="mailto:beldmit@gmail.com" target="_blank">beldmit@gmail.com</a>> wrote:</div><br class="gmail-m_7177905700595543375Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</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">On Thu, Feb 21, 2019 at 04:20:53PM +0000, Matt Caswell wrote:<br>
<br>> > 2. Can we do something with a bunch of hard-linked non-extendable lists of<br>> > internal NIDs?<br>><br>> > For example, providing GOST algorithms always requires a patch to extend 3-5<br>> > internal lists.<br>> > If it could be done dynamically, it will be great.<br>
<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></blockquote><div><br></div><div>This is a way we go here and now. It is inevitable for libssl, but can be significantly reduced for libcrypto.</div><div>Some examples are available in my response to Richard.</div><div><br></div><div>And here we get a second problem, relatively small. If I remember correctly, </div><div>adding new OIDs/NIDs is treated as breaking the binary compatibility so we have to wait for a major release.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>Totally agree. OBJ_create() and similar functions exist, but do not solve our problems. </div></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_7177905700595543375gmail_signature">SY, Dmitry Belyavsky</div></div>
</div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>