George Staikos wrote: > > Actually this is very similar to what we were doing for KDE 3.0 as well. I > was unaware of this work and we were developing a similar system using shared > libs loaded on demand for "card implementations". All in C++ using KDE > classes though. I'm wondering if maybe we should abandon that or rework it > to use this now. I am working with GPK cards and the other person is using > GSM cards. > > We wanted to implement a very abstract architecture so that KDE > applications could use smartcards without having to know the details of them. > In particular, this would be used for storage, SSL certificates, and KDM > login. > > Would it make sense for us to make a KDE friendly wrapper around this code > instead?
Depends on the card you are using. At first sight translating a GPK card to this MuscleCard client API may be problematical. Trying to translate an unerasable pre-personalised GemSAFE card is a probably a non starter. A wrapper round PKCS#11 might be better in the longer term but linux PKCS#11 implementations don't exist for all cards. There isn't one for GemSAFE cards for example. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
