On 12/7/06, Joe Orton <[EMAIL PROTECTED]> wrote:
Sorry for the slow reply Alon, a busy month here. Thanks for explaining a bit more about the problem.
Thanks for your reply.
On Thu, Nov 30, 2006 at 07:00:50PM +0200, Alon Bar-Lev wrote: 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.
No it will not... You will still have to register global ask-pin callback...
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. :(
I discussed this with several people... This daemon will likeley have PKCS#11 interface... PKCS#11 is the standard interface for crypto device, reinventing interfaces such as the one ssh-agent uses or the one that gpg-agent will only make the life of users very difficult. The problem with ssh-agent is that it does not handle smartcards in a dynamic manner... It does not ask for PIN when card is removed, it does not ask for card insert when required... I support external patch for ssh-agent to use PKCS#11, but it require forking a GUI ask-pin program... ssh should be modified to receive not-authenticated response from the ssh-agent and prompt the user. The problem with gpg-agent/scdaemon is that it does not support several cards at the same time, it also have many problem regarding its usage and protected authentication, so we wrote an alternative gnupg-pkcs11-scd which is PKCS#11 enabled scdaemon for users to use.... So now people can use KMail with their smartcards. I prefer projects whose developers understand what smartcard is, and woking together to create a proper support. OpenVPN and QCA are samples of this approach, as a result they have very good integration with file based keys and hardware based keys. I am interesting to help you achieve the same level of integration.
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?
No. I sent you some code examples, please review them. I totally do not agree that there is a problem. The only two callbacks are "Crypto layer needs token which is not present" and "Crypto layer needs PIN for a token". Both receive a pointer to global context you provide at registration. It worked well in any applications. I don't understand why neon is so special. Can you please explain further? Best Regards, Alon Bar-Lev. _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
