Andreas, my idea is to support PKCS#11 interface on both sides... Thus nothing actually gets simpler... Just keep standard while providing singe sign-on and more secure environment.
I am strongly against developing a new API for application to use... "full feature store". The application will load proxy PKCS#11 which will forward all requests to a daemon. The daemon will load several PKCS#11 provider and expose them to the application as if they were a single provider. The only functionality the daemon will use is PIN management. This way application will be required to support PKCS#11 and only PKCS#11. If the user chooses he can load the smartcard provider into application or he can use the daemon in order to provide SSO. For CAPI... I've seen implementations of PKCS#11 which can access CAPI stores... And it this will be the problem, I can develop one too... Best Regards, Alon Bar-Lev. On 4/24/07, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
Hi Clizio, I think spliting client and server is the right thing to go. While I share Alons reservations when it comes to using tcp/ip, I don't see a reason to not do that, if someone wants to do that. might work well in thinclient environments etc. currently we have a big fat library loading other libraries into an application. a small module talking to a daemon looks much nicer, can implement single sign on like alon mentioned, and solves a number of problem - e.g. makes it much easier and cleaner to implement gui popups (e.g. for lawful digital signatures, letting the user know he has to enter a pin (on the reader with pinpad) and so on). also it might be interesting to have a full featured store - one that contains the local file based certificates and keys etc. as well as the smart card stuff. one interface for all applications. ms crypto api is the right idea I guess - much better if you have one interface for all apps, than have every app manage certficates and all that on their own. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
