[openssl-project] OpenSSL 3.0 and FIPS Update

[Dr Paul Dale]

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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190225/bde0c24f/attachment-0001.html>