On Sun, 2010-12-12 at 18:30 +0100, Ludovic Rousseau wrote: > 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.
Which solution? > The driver cannot split a long APDU into two smaller ones. Correct. But with TPDU and Extended APDU level exchange the APDU is transmitted in multiple parts anyway. Everything is still implemented in the drivers (i.e. libccid). > So the application has to know the maximum size and generate correct APDU. Naturally that is 261 bytes for short APDU and 65545 bytes for extended ones. The only thing the application has to know is the level of support for extended APDU and chaining. There is nothing else the application should care about. If there is something wrong, then please explain. > 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. Regards Andre > [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 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
