[openssl-project] OpenSSL 3.0 and FIPS Update

Michael Richardson mcr at sandelman.ca
Sun Feb 24 23:40:51 UTC 2019


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 at dukhovni.org> 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.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190224/bd515b31/attachment.sig>


More information about the openssl-users mailing list