Sorry for the slow reply Alon, a busy month here. Thanks for explaining a bit more about the problem.
On Thu, Nov 30, 2006 at 07:00:50PM +0200, Alon Bar-Lev wrote: > Well... That's correct, but in case of smartcards, you really don't > want to create a separate instance of data to each instance. For > example, if the user authenticate to the smartcard, you want all > instances to be authentication, and there is an issue with object > caching, smartcards are slow devices, without a global context you end > up with none responsive system. So really it sounds to me like you only want to be using the PKCS#11 interface from a specific process (a daemon) and marshalling all application/library access via that process. That would make this global context issue go away: you could configure per-session whether to use such a daemon or not. That would actually fit in quite well with an idea which has been floated a few times: of an "ssh-agent"-like daemon for use with OpenSSL. But of course, with OpenSSL, the only way to implement this is using an ENGINE and then I believe you're stuck back again with global context issues. :( > >But either way, in this case, I don't think there is much value in neon > >wrapping such interfaces. neon could probably somehow expose an > >interface like: > > I don't understand why. Can you please explain... Well, imagine you have five separate libraries which support your PKCS#11 interface linked into a given application. If the app is going to have to register process-global callbacks to be able to use PKCS#11, there is no value in having each separate library provide an abstraction layer *on top of your PKCS#11 interface*. The application might as well just call your code directly. Does that make sense? Regards, joe _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
