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.
Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 25 Feb 2019, at 5:02 pm, Dmitry Belyavsky <beld...@gmail.com> wrote: > > > > On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <openssl-us...@dukhovni.org > <mailto:openssl-us...@dukhovni.org>> wrote: > On Thu, Feb 21, 2019 at 04:20:53PM +0000, Matt Caswell wrote: > > > > 2. Can we do something with a bunch of hard-linked non-extendable lists of > > > internal NIDs? > > > > > For example, providing GOST algorithms always requires a patch to extend > > > 3-5 > > > internal lists. > > > If it could be done dynamically, it will be great. > > The simplest solution is to submit a PR to add your OIDs to OpenSSL, > so that no furher out of tree patches are required. > > This is a way we go here and now. It is inevitable for libssl, but can be > significantly reduced for libcrypto. > Some examples are available in my response to Richard. > > And here we get a second problem, relatively small. If I remember correctly, > adding new OIDs/NIDs is treated as breaking the binary compatibility so we > have to wait for a major release. > > Dynamic NIDs don't fit very well into the design, because NIDs are > expected to be stable compile-time constants. We could perhaps > reserve a range for "private-use", and "engines" could allocate new > NIDs in the private space at runtime. The key question is whether > such NIDs are global or valid only if returned to the same engine > (provider, ...). If not global, the allocation might be static > within the engine, and not require any locks. > > Totally agree. OBJ_create() and similar functions exist, but do not solve our > problems. > > -- > SY, Dmitry Belyavsky
