Do we really want to have the legacy provider as opt-in only?

[Matt Caswell]

On 15/07/2019 13:58, Tomas Mraz wrote:
> Hi everyone,
> 
> if the Subject was already fully discussed and thought through then
> please disregard this but otherwise I'd like this e-mail to be a
> starting point for discussion.
> 
> I suppose the current intention is to make the legacy provider as opt-
> in only by either application explicitly loading it or by having it
> added to the default configuration file.

The current plan is that if no provider is loaded by the time the first "fetch"
is done, then then "default" provider gets loaded automatically. In other words
the "legacy" provider won't get loaded automatically *unless* it is loaded by
the default configuration file.

I don't recall any discussion about what will be in the default configuration
file. My assumption has always been that the legacy provider would not be
automatically loaded.

> 
> Is there anywhere any document which categorizes the current set of
> algorithms with which are considered legacy and which not?

The algorithms planned to be moved to the legacy provider are:

Blowfish
CAST
DES (but not 3DES)
DSA
IDEA
MD2
MD4
MDC2
RC2
RC4
RC5
RIPEMD160
SEED
Whirlpool

This is documented in the "Legacy Provider Module" section of the Design Document:

https://www.openssl.org/docs/OpenSSL300Design.html

Note the following caveat that document has about the above list:

"this is not meant to be an exhaustive list, even though fairly complete for the
moment"

> 
> I understand that for the current digest algos implemented in the
> legacy provider the problem might not be as pressing as these
> algorithms are not widely used however which other algorithms are going
> to be moved into the legacy provider?

My guess is that the ones likely to give us the most problems would be DES, DSA
and RC4

> 
> Wouldn't it be better to make the legacy provider opt-out? I.E. require
> explicit configuration or explicit API call to not load the legacy
> provider.
> 

IMO this is a major release and therefore we should be taking the opportunity to
encourage applications to move away from these legacy algorithms. That's kind of
the point of having a legacy provider in the first place. Most applications
should not need to use these legacy algos so in my mind it is a sensible default
to not have them available. Only if you *really* need them should you load the
legacy provider.

Matt