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.dale@xxxxxxxxxx> 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 <beldmit@xxxxxxxxx> wrote:On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> 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
