Hello Alon!
On Mittwoch, 9. Mai 2007, Alon Bar-Lev wrote:
> Yes... Some thoughts:
>
> 1. The daemon will expose PKCS#11 interface as protected
> authentication path, so that applications will not require to set PIN.
> This will allow PKCS#11 single sign-on throughout several
> applications.
>
> 2. Minimal and secure client side implementation, so that the client
> will not cause security issues in client process.
>
> 3. Implement (1) using unix sockets.
>
> 4. Have an option to work using TCP/TLS, have now idea how to
> authenticate client to server yet.
>
> 5. Allow the server to load several providers, but still expose them
> as one provider to the client, this will allow applications that
> support only one provider to work with more than one provider.
>
> This will be implemented as different slot names.
>
> 6. Haven't thoughts about slot events yet, don't know if I want to
> support these in first version.
Well, your thoughts are obviously much more detailed than mine ...
My points - which are more or less just brainstorming - :
7) The "server" should be implemented as a shared library, so that it can be
applied to any running process that opens a pkcs#11 session (see your SSO in
point 1).
I'd imagine some interface like
int makeThreadAndConnect(int connection, CK_FUNCTION_LIST *list);
which creates a new thread, receives and sends messages on the given
connection, using the given PKCS#11 functions.
Although we might need to split that interface into something like
int blob2functioncall(CK_FUNCTION_LIST *list,
char *indata, int in_len, int *in_used_len,
char *outdata, int out_len, int *out_used_len);
so that ssl_* functions may be used.
in_used_len would be used in this example for "pipelining" - if that makes
sense at all?? Most probably not.
The different fields in the blob can be asn.1 encoded ... but how do we signal
an end-of-message? TCP is a "stream", without block-boundaries ...
8) Cross-plattform. I'd surely need win32/linux server/client.
That should be no problem - we just have to en/decode the various data into
packets and back.
8a) For win32 named pipes instead of unix sockets would be needed, I think.
Does any of that make sense?
Regards,
Phil
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
