On Sat, 2016-02-20 at 23:34 +0100, Jaroslav Imrich wrote: > On 20 February 2016 at 21:40, Sander Temme <[email protected]> wrote: > > However, I’m intrigued by the notion of a PKCS#11 Engine in > > OpenSSL: it’s a standard (an OASIS standard now); it’s fairly fully > > featured; everyone in the industry supports it including Thales; > > and you can build a program that calls it without needing a vendor > > SDK, because there are standard headers and a well defined way to > > get to the entry points. If we can come up with a way to pick a > > PKCS#11 slot and log into it that makes sense (e.g. not by poking > > PINs into a system wide config file etc.) then I think we’d have a > > winner. > Let's not forget that CHIL provides one very unique feature - forked > process keeps the authentication state of its parent and can access > HSM keys if its parent was authenticated. PKCS#11 specification > prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of > that PKCS#11 based engine couldn't fully replace CHIL engine.
That's an implementation detail. As far as I know engine_pkcs11 does not require re-authentication after fork. It handles the pkcs11 peculiarities internally. regards, Nikos -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
