Are you aware of alternative provider?

[pemensik]

There is also another implementation, which seems to be somehow further:
https://github.com/latchset/pkcs11-provider

Are you aware of it? Is this provider different in what it offers? Should they be merged eventually?

[holger-dengler]

(first of all: Petr, sorry for my late response!)

Yes, I'm aware of the pkcs11-provider and also check from time to time, if there is something I can contribute to it. On the other hand, there are a few aspects, which led to the decision, to implement this pkcs11-sign-provider.

PKCS#11 was designed for accessing crypto hardware. Fortunately, it is more and more used for software-based tokes as well. But there are still hardware-based tokens around... If you're working in such a hardware-token-based environment, it is important, with respect to the performance, that only the really necessary operations are processed in the token. E.g. in asymmetric use cases, you would like to do only the private key related operations (decrypt/sign) in the token, while all operations with the public key (encrypt/verify) should be processed in SW. AFAIK, it is currently not possible in OpenSSL3, to implement operations for the private keys only or write properties, so that a certain provider is only used for private key operations. There are currently some discussions in the openssl community to address these issues, but all potential solutions will be usable only in future openssl-versions.

So this pkcs11-sign-provider will be a (more or less) interims-solution, which may be replaced by other solutions in 2-3 years. For current distributions with (mostly) opessl3.0, this pkcs11-sign-provider could be a way to e.g. setup a HTTPS-server, which protects its private server-identity key in a hardware-based crypto token. This would make much harder for an attacker to steal the server identity(*), than in a pure software-based solution.

(*) assumed, the private key in the token is non-extractable