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. Regards Andre _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
