On 02.05.2007, at 9:25, Andreas Jellinghaus wrote: > On Tuesday 01 May 2007 23:24:00 Ville Skyttä wrote: >> Fedora uses /usr/lib(64)/pcsc/drivers and /usr/lib(64)/ctapi. FWIW, >> "readers" smells to me like a tad too generic name to use directly >> below >> /usr/lib(64). > > looks good to me, I think the "reader" term is too generic. even > "card reader" > is used by both smart cards readers and media card readers. (and > someone > had the bright idea to call some of the media cards even "smart > media cards" > adding to all the confusion.)
I agree. My long reply is a bit off topic rant: It all reminds me the similar pkcs11 case - that there should be a system pkcs11 folder where all pkcs11 modules should go and what applications should use to do some automagic stuff before starting to use one (or all?) of them (see http://wiki.cacert.org/wiki/ Pkcs11TaskForce). AFAIK the idea never really took off. Why ? I think that what applications (and thus developers) really want to use are not *modules* that provide the API but just THE API. The fact that you have to mess with different modules without prior knowledge 'which one is the one I actually want to use' you have to build some user interaction and/or configuration into your application - thus the location is really not so important - the user has to make the decision anyway. Such loadable modules are great from software development point of view but to orchestrate this software stack in a usable manner you need to do some difficult decisions. The problem (and power) of Linux is - it doesn't really provide a system wide high level API: Windows has cryptoapi and pcsc, Mac has pcsc-lite (old and broken but still a unified one) and keychain access (cdsa). Linux has: openct, pcsc-lite, ctapi, kernel modules, loadable modules, libchipcard, openssl, muscleframework, gnutls, lib11, pkcs11-helper, gnupg, engines, plugins .. the list could go on. Then we have a bunch of daemons to access some parts of the mix. A nice selection for professionals to choose from and play with and use in embedded solutions. Nightmare for users. The question every application developer should ask himself: do I want to write a certain code path through low level layers into my application or do I want to GetStuffDone and move on? Do you want to write code that deals with reader driver selection or pkcs11 module selection or do you just want to 'talk to a damn application on the card card' or 'get some signatures to this hash' (maybe from a smart card that lives inside your GSM phone?) ? I guess - and hope - that you actually want to do the latter and don't really care about the drivers that make all of this happen. OpenSC is a great example in this matter - you implement a card driver and move on. You care about the card driver not the reader access method or how it shall be used. Tokend is a great example as it brings all the opensc drivers to mac space (It has issues, yes.). A Windows basecsp plugin would be great as well (this shall happen around autumn this year for Estonian eID) as this would do the same on Windows for all cards supported by opensc. If ctapi would not be fading out (AFAIK all windows ctapi implementations wrap pcsc calls) the csp could talk to ctapi via opensc (maybe). All these developments share one common goal: implement once and integrate so that one integration would bring maximum number of possible users to your work. All applications have to make a decision - flexibility vs usability. If your application is built with such powerful capabilities of selecting drivers (multiply the decision with the number of applications) that it could use any or all of the available options (modules) - you also get the annoying and redundant configuration step. So If we are about to create a new standard (for Linux) lets make it a design standard! There was some emails on opensc-devel about ' pkcs11 application developer guidelines' - HOW applications that want (or could) use smart cards (or readers) should be built so that it would be TheRightWay from developer point of view as well as user point of view. This includes card and reader access sharing (lock_login and friends in OpenSC), relevant users and groups, issues like pinpads, relevant applicatin writing guidelines. Relevant co- operation with other projects (gnome, kde (qt-crypto?), mozilla). And so on. Having a standard where to put modules a user has to make a selection from is a good start that definitely is needed but doesn't bring the real improvements to real users. I believe that Linux, like other operating systems, have evolved enough in smart card related software from 'I want to use this reader with this application' (selecting a ctapi module) to 'I want to use a reader available to the system'. Just like average 'smart card applications' either 'want to talk to a card' (no matter how) or 'want to deal with private keys' (no matter where the key is or how it is protected) instead of 'I want to talk to THIS pkcs11 module with this PIN for this reason and THAT pkcs11 module for that reason'. So we as software developers should re-factor and provide higher level APIs (Everything in software can be and IS solved by adding a new layer of indirection :)). We should create code that would eliminate gaps and bring maximum results instead of trying to integrate yet another application with a specific reader (I really would like to use gnupg with whatever card opensc can use). Being practical - one of my big TODOs (yet TBD) has been implementing reader hotplugging in opensc. This would be the time and place to talk to all *reader* users (I hope they are mostly library creators) about requirements that a universal reader access layer should have because: Are you happy with pcsc on linux (mostly not, as we have ctapi and openct as well)? Why are you not happy ? Why do you use reader drivers directly ? Would you like the ability to talk to all available reader (openct, ctapi, pcsc)? Would you use a unified layer? What should be done in that layer? etc etc. cheers, m. -- Martin Paljak _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
