[openssl-project] OpenSSL 3.0 and FIPS Update

[Dmitry Belyavsky]

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
> 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 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190225/dfca8741/attachment.html>