On Thu, Dec 07, 2006 at 04:29:48PM +0200, Alon Bar-Lev wrote:
> 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...
The idea with that kind of scheme is to marshal the RSA key operations
over a socket to a daemon as ssh-agent does. So you can do some
desktop-global GUI popup in your desktop-global daemon, or whatever; or
even if the pass phrase is requested over the socket too, the neon
library wouldn't have to necessarily have to maintain any process-global
state.
(modulo any problems with how you'd actually *implement* such a scheme
as I mentioned w.r.t. the OpenSSL ENGINE thing)
> >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.
Those looked like plugins or applications - neon is a library, libraries
have different constraints and can make different assumptions.
> 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.
The point is that there's nothing *neon* can do with this callback. It
must always be entirely specific to the application. Say that the call
to your library is:
void pkcs11h_set_token_callback(some_callback_fn_t fn, void *userdata);
Now imagine that you are using say a PKCS#11-ified neon to do some HTTP
work and a PKCS#11-ified OpenLDAP to do some LDAP work in one
application.
Clearly we could add to neon:
void ne_set_token_callback(some_callback_fn_t fn, void *userdata) {
pkcs11h_set_token_callback(fn, userdata);
}
and the OpenLDAP guys could add:
void LDAP_set_token_callback(some_callback_fn_t fn, void *userdata) {
pkcs11h_set_token_callback(fn, userdata);
}
but then you can see there is no value in the application calling all
these wrappers. It might as well just call pkcs11h_set_token_callback
directly itself; it is functionally equivalent, and requires less code
to be written and maintained overall.
Regards,
joe
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon
