libp11
libp11 copied to clipboard
OpenSC
Implement new PKCS #11 3.0 features (ed25519, curve25519)
OpenSC has some of the PKCS#11 features in the pipeline to get merged (OpenSC/OpenSC#2096, OpenSC/OpenSC#1854). Once they are in, it would be great if libp11 could use the new interfaces and the new key types and mechanisms.
Opening one issue for several features makes tracking their implementation hard. Which new PKCS#11 3.0 features were actually implemented in OpenSC? Which of them do you consider useful for libp11?
I think for libp11, it should be significantly easier as it should be enough to add definitions for new PKCS#11 3.0 API, try to use it (and fallback to 2.x API if not available) and support new key types ed25519, curve25519 so far.
add definitions for new PKCS#11 3.0 API, try to use it (and fallback to 2.x API if not available)
Does support for new key types depend on it?
Technically not, but the new key types are specified only in the 3.0 standard.
I believe the main issue which needs to be addresses is: 1.6 Engines and "METHOD" APIs " "METHODS" (for example EVP_MD_meth_new, EVP_CIPHER_meth_new, EVP_PKEY_meth_new, RSA_meth_new, EC_KEY_METHOD_new, etc.). These functions are being deprecated in OpenSSL 3.0 ... Authors and maintainers of external engines are strongly encouraged to refactor their code transforming engines into providers using the new Provider API and avoiding deprecated methods."
The way I read it, libp11 will need a provider interface in addition to the engine. Eventually OpenSSL will stop upgrading the engine and will finally drop it. Now is the time to get started. It will be easier to get changes included earlier rather than later.
This may also eliminate circular reference problems as listed in #294
These functions are being deprecated in OpenSSL 3.0
@dengert What does OpenSSL 3.0 have to do with PKCS#11 3.0 (besides the version number)?
Yes they are deprecated in 3.0, but can still be used for some time if application is compiled with -DOPENSSL_USE_DEPRECATED -DOPENSSL_API_COMPAT=0x10101000L
So that gives us time to create a provider and control its use using the above two defines.
Your right # 294 does not deal with OpenSSL 3.0 But it does deal with the way engines are loaded. Hopefully OpenSSL 3.0 providers will not have these same issues when loading a provider.