Dear Michael,
On Mon, Feb 25, 2019 at 2:41 AM Michael Richardson <mcr@xxxxxxxxxxxx> wrote:
Not sure who Matt quoted, 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.
Matt then wrote:
> The simplest solution is to submit a PR to add your OIDs to OpenSSL,
> so that no furher out of tree patches are required.
Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
> 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.
Having stubbed my toe on some NID stuff, I must question exposting NIDs.
ruby-openssl used them in a dumb way that meant that adding extensions by OID
was broken until I removed some code.
I think that the #define/enum of NIDs should be made internal-only,
available as optimization to internal code only.
Your question then becomes, "are engines internal users", and I'd like the
answer to be no. I think that the openssl 3 changes suggest the same thing.
The engines are _mostly_ external users. But sometimes, providing new algorithms,
there appear some parts that should go into the core part. And regulation creates similar problems.
All other users can call OBJ_obj2nid() or OBJ_txt2nid() to get a NID,
and we can figure out how to allocate things dynamically if this makes
sense. I don't know which APIs are currently NID-only.
AFAIK, no external API, but there are some cases when external API does not cover all.
SY, Dmitry Belyavsky
