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 <[email protected]> wrote: > > > > On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <[email protected] > <mailto:[email protected]>> 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
