Mailing List Archive

On 13.12.2023 10:55, Joe Orton wrote:
> On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote:
>> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice
>> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path.
>> Sorry for the noise.
>
> Yes it should remain compatible like that, though you prompted me to
> re-read that and it would break for a no-engine build: r1914622.
Good catch!
How would one compile without OpenSSL having the engine API ?
At least currently, any supported OpenSSL version still does have the Engine API.
>
> I am not sure but we might want to add a new directive (yay) which loads
> a named provider, or we could rely on users doing that in openssl.cnf
> since configuring providers may be non-trivial (e.g. [1]).
I would not try to load a named provider. While loading a named provider can be done using the OpenSSL provider API,
it is not possible to supply configuration parameters to that provider after loading it.
Most provider I know do need specific configuration settings, they won't work without them, especially the PKCS#11 providers.
So we must rely on users doing that in openssl.cnf.
>
> Other thing a colleage mentioned was that we may want to expand the list
> of URI schemes accepted here from just pkcs11://.
Sure, the provider code in general should work for any kind of URIs, not only 'pkcs11:'.
It would even work for the 'file:' URI, loading the keys/certs from PEM files (like the non-provider/non-engine code is doing already).
Actually it would even work for file names without a scheme at all, since the default scheme is 'file:' anyway.
So it could theoretically replace the non-provider/non-engine load key/cert code (not that I would suggests to change that as of today....).
>
> [1] https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti
>

--
Ingo Franzki
eMail: ifranzki@linux.ibm.com
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

On Wed, Dec 13, 2023 at 11:33:16AM +0100, Ingo Franzki wrote:
> On 13.12.2023 10:55, Joe Orton wrote:
> > On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote:
> >> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice
> >> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path.
> >> Sorry for the noise.
> >
> > Yes it should remain compatible like that, though you prompted me to
> > re-read that and it would break for a no-engine build: r1914622.
> Good catch!
> How would one compile without OpenSSL having the engine API ?
> At least currently, any supported OpenSSL version still does have the Engine API.

If you configure OpenSSL with the "no-engine" flag, you get
OPENSSL_NO_ENGINE #define'd in the OpenSSL headers, and the engine API
is not available.

Looks like a few more places which assume ->szCryptoDevice is always
there, so there may be other build issues. We need a CI config for this.

> > I am not sure but we might want to add a new directive (yay) which loads
> > a named provider, or we could rely on users doing that in openssl.cnf
> > since configuring providers may be non-trivial (e.g. [1]).
> I would not try to load a named provider. While loading a named provider can be done using the OpenSSL provider API,
> it is not possible to supply configuration parameters to that provider after loading it.
> Most provider I know do need specific configuration settings, they won't work without them, especially the PKCS#11 providers.
> So we must rely on users doing that in openssl.cnf.

That makes sense to me, thank you.

> > Other thing a colleage mentioned was that we may want to expand the list
> > of URI schemes accepted here from just pkcs11://.
> Sure, the provider code in general should work for any kind of URIs, not only 'pkcs11:'.
> It would even work for the 'file:' URI, loading the keys/certs from PEM files (like the non-provider/non-engine code is doing already).
> Actually it would even work for file names without a scheme at all, since the default scheme is 'file:' anyway.
> So it could theoretically replace the non-provider/non-engine load key/cert code (not that I would suggests to change that as of today....).

Yup. We would have to be careful to make the logic around loading the
chain from the file would work exactly the same if a file:// URI was
used. I'm not sure what the best approach is - try loading everything
via a store and then fallback to the old way, or again add a new config
option(s?) SSLBlahURI.

Regards, Joe