[openssl-project] OpenSSL 3.0 and FIPS Update
beldmit at gmail.com
Mon Feb 25 10:51:38 UTC 2019
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 at 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
> 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 at gmail.com> wrote:
> On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <
> openssl-users at 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users