Provide ibmca provider drop-in config snippet

[sharkcz]

Cloning a downstream ticket (https://issues.redhat.com/browse/RHEL-78400) here:

Some time ago we added a .include /etc/pki/tls/openssl.d line to openssl configuration file in RHEL-10. This is a folder containing drop-in provider configurations used , for example, by PKCS#11 provider and some others.

This change would let avoid editing main OpenSSL configuration file for enabling IBMCA.

[ifranzki]

In general a good idea, but probably distro specific?

Also, I am not sure if we really always want to enable/configure the IBMCA provider system wide when the package is installed? Maybe one wants to enable it only for a specific application (i.e. in an application specific openssl config file)? With the drop-in it would always be enabled system wide once the package is installed.

Furthermore, the use of the IBMCA provider requires the following to be used:

[evp_properties]
default_properties = ?provider=ibmca

I fear that when multiple snippets include such a thing, then it is creating a mess, and probably a non-working OpenSSL config.

[beldmit]

Yes, it's a sort of distro-specific solution now but the include syntax is the upstream one.

You can comment out all the content of your file by default so it will not be activated.

OTOH I'd NOT recommend setting the default properties in such snippets, exactly for the reasons you provided

[ifranzki]

Having a snippet without the default properties and/or commented out IBMCA provider settings is of little (or even no) use. Users would then still have to manually change things to actually be able to make use of IBMCA.

IBMCA is a provider that accelerates certain algorithms that are otherwise provided by the OpenSSL default provider. So just loading the IBMCA provider, but not preferring it using default_properties = ?provider=ibmca is of no use. It would just not get used, but applications would continue the use the default provider.

This is different for like the PKCS#11 provider for example. The PKCS#11 provider is normally not preferred by means of default properties, but it comes to play when a key is loaded through a PKCS#11 URI or a URI-PEM. So the PKCS#ä11 provider can easily just be loaded and is perfectly useful that way anyway.

Besides that, we really want that users carefully think about if and what they want to accelerate with the IBMCA provider. OpenSSL has lots of built-in support for accelerating certain algorithms on the s390x platform, see https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-openssl-ibmz. However, there are a few overlaps between the IBMCA provider and OpenSSL's built-in acceleration, especially for EC. So dependent on the system model available, a user may benefit from IBMCA or not. See figure 1 on https://www.ibm.com/docs/en/linux-on-systems?topic=linuxone-quick-decision about how to decide.

So bottom line, in my opinion, we want that users carefully think about the use of the IBMCA provider, and also which algorithms to enable. So if we have them to add the configuration statements to the OpenSSL config file themselves, there is a good chance that they actually think about it :-)

Still users can of course utilize snippets to enable the IBMCA provider if they like to.

[beldmit]

OK, thanks for clarification!

I'm looking from the perspective of system upgrade. If we modify the default OpenSSL configuration file, the upgrade has to analyze it. If we modify the provider-specific snippet, the system-wide settings will be applied on upgrade.

[ifranzki]

Yes I get that point.

Still, if the user needs to edit the default OpenSSL configuration file to add the default properties, then an upgrade would still have to analyze it....

[beldmit]

I agree that in your case having the [evp_properties] in the provider snippet is reasonable.
Also I agree with your point that it can cause mess when several providers are configured

[ifranzki]

I wonder how exactly the snippet is to be used. There are 2 (3) places in the OpenSSL config that needs to be changed for adding a provider:

1. Add your own provider section:

[myprovider_sect]
whatever...

2. Add your provider to the [provider_sect]

[provider_sect]
...
myprovider = myprovider_sect 

3. Optional: Add/set default_properties:

[evp_properties]
default_properties = ?provider=myprovider

So which of these 2 (3) parts go into the snippets? I would assume part 1 only. But then one still needs to edit the OpenSSL config file to add part 2 (and possibly part 3).

So I guess we would need 2 kind of snippets, one for part 1, and another one for part 2.
Kind of like the following:

openssl_conf = openssl_def

[openssl_def]
providers = provider_sect
#alg_section = evp_properties

[provider_sect]
default = default_sect
.include /etc/pki/tls/openssl-1.d    <--- snippets that contains `my_provider = myprovider_sect`

[default_sect]
activate = 1

.include /etc/pki/tls/openssl-2.d    <--- snippets that define the `myprovider_sect` sections

#[evp_properties]
# default_properties = whatever

The default_properties setup could go into the snippet in /etc/pki/tls/openssl-2.d, but it requires that the openssl_def section already defines alg_section = evp_properties...

[beldmit]

The default_properties setup could go into the snippet in /etc/pki/tls/openssl-2.d, but it requires that the openssl_def section already defines alg_section = evp_properties...

This part is distro specific (RH-based distros provide this definition)

Regarding (1) and (2) you can provide the same section several times.

e.g. oqsprovider.conf snippet (tested, working) is

[provider_sect]
oqsprovider = oqs_sect

[oqs_sect]
activate = 1

combining your (1) and (2)

[ifranzki]

you can provide the same section several times.

I didn't know this. But good to know.