Dear Dr Paul, I think this change is somewhere in a gray zone.
On Mon, Feb 25, 2019 at 1:37 PM Dr Paul Dale <paul.d...@oracle.com> wrote: > 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> 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 > > > -- SY, Dmitry Belyavsky
