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.
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]).
Other thing a colleage mentioned was that we may want to expand the list
of URI schemes accepted here from just pkcs11://.
[1] https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti
> 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.
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]).
Other thing a colleage mentioned was that we may want to expand the list
of URI schemes accepted here from just pkcs11://.
[1] https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti