-------- Forwarded Message -------- From: Robert Relyea <rrelyea@redhat. com> To: Nikos Mavrogiannopoulos <n...@redhat.com> Cc: openssl-dev@openss l.org Subject: Re: [openssl-dev] Ubsec and Chil engines Date: Tue, 23 Feb 2016 12:28:25 -0500 (EST)
----- Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote: > > On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos <nmav@redhat. > > co > > 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. The osasis pkcs 11 group is already planning on updating the semantic in a future pkcs 11 release. You can track the technicial committee work here https://www.oasis-open.org/apps/org/workgroup/pkcs11 If you have fully formed proposals for PKCS 11 let me know and we can look at adding it to the spec. Bob -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev