2010/12/12 Andre Zepezauer <andre.zepeza...@student.uni-halle.de>: > On Sun, 2010-12-12 at 11:13 +0100, Andreas Jellinghaus wrote: >> hmm. for details on using ccid readers ludovic knows this stuff >> much better than I do. >> >> for some other readers, I remember one token where the chip card >> inside has a maxIFSCD of 255 in the atr, so we could send quite >> big t=1 frames. but the reader chip in that token would only work >> with smaller commands. >> >> not sure if I could work around that in openct, or needed opensc >> to generate smaller apdus in the first place. >> >> but stuff like this might happen all the time - most tokens are sold >> as solution with chip/reader/token device plus software as a bundle, >> so any alternative software like opensc is exploring unknown seas >> and might find bugs... >> >> so in general I think it would be good to have a few knobs to tweak, >> preferable without recompiling, if we run into problems with some >> tokens. > > Then the question is: where is the right place for such tweaks. Our > current approach would translate to a configuration option in a > web-browser, that limits the size of web-pages. And of cause all the > other network applications must be configured separately in similar way. > Fortunately that's not the case. > > So it's better to have a common place for such tweaks. In the smart card > world this should be preferable the read driver. Applications should > only care about capabilities of cards. Especially support for extended > APDU and chaining. How these APDU:s are transmitted is left to the read > driver. Additionally the driver has better knowledge of readers and > therefore is able to implement more advanced tweaks.
Your solution can't work. The driver cannot split a long APDU into two smaller ones. So the application has to know the maximum size and generate correct APDU. A few years ago I proposed a solution [1] for the application to know the maximum usable size using SCARD_ATTR_MAXINPUT [2]. But this is not PC/SC standard. I proposed something similar to the PC/SC workgroup. I don't know yet if the idea has been accepted. Bye [1] http://www.opensc-project.org/pipermail/opensc-devel/2006-November/009199.html [2] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/SCARDGETATTRIB.txt -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
