On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote: > On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos <[email protected] > m> wrote: > > 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. > AFAIK this works by caching the PIN in engine_pkcs11 internally and > is OK for most of the use cases with smartcards. However HSMs usually > use more complex authentication schemes where this approach does not > work i.e. in order to login there must be N of M physical > tokens/cards with passwords presented in a sequence (requires vendor > specific extensions when used via PKCS#11). CHIL engine already > handles such schemes very well and does not need to reauthenticate > after fork.
I find that discussion more suitable to the PKCS #11 working group than here. It cannot be solved by openssl devevlopers. In any case, I don't find the solution to any problem in a standardized API is "let's make our own better API". Why not work towards fixing the PKCS #11 spec? In any case, there _are_ PKCS #11 modules which continue working after fork (opendnssec's softhsm for example). So the issue is not something that cannot be addressed within PKCS #11. regards, Nikos -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
