[openssl-dev] Ubsec and Chil engines

Nikos Mavrogiannopoulos nmav at redhat.com
Wed Feb 24 08:00:21 UTC 2016


-------- Forwarded Message --------
From: Robert Relyea <rrelyea at redhat.
com>
To: Nikos Mavrogiannopoulos <nmav at redhat.com>
Cc: openssl-dev at openss
l.org
Subject: Re: [openssl-dev] Ubsec and Chil engines
Date: Tue, 23 Feb
2016 12:28:25 -0500 (EST)

----- Nikos Mavrogiannopoulos <nmav at 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 at 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






More information about the openssl-dev mailing list