On Tue, 2010-08-17 at 10:08 +0300, Martin Paljak wrote: > Helo, > > On Aug 17, 2010, at 1:59 AM, Andre Zepezauer wrote: > > On Mon, 2010-08-16 at 21:10 +0200, Emanuele Pucciarelli wrote: > >>> @martin: When you are interested in improving iso7816.c, then rewrite > >>> the select_file function. It is not very generic. For example it won't > >>> work for my german debit card, which is of course iso-compliant. Also > >>> get_data/put_data could be implemented. > >> > >> Speaking for myself here – examples and/or log traces would be > >> helpful, I think. What doesn't work with your card, and you'd like to > >> see improved? > > > > This particular card isn't important at all. But it shows, that the > > select_file function doesn't work for an iso card. I had to write code, > > to read the contents of this one. But I really would like to use > > opensc-explorer for such a task. For example: > > cat 2F00 > > cat 2F01 > > Do you have a patch?
I don't have one, because the apdus are assembled right in the main function of my little custom app. > >>> @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I > >>> guess that this was an accident. > >> > >> It isn't, to tell the truth; as the comment states, that APDU is not > >> from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you > >> wish). > >> > >> The driver isn't using it any longer (as I'm looking at SM separately, > >> following Viktor's work), so I don't "need" it. It may make sense to > >> leave it there, though, as it is clearly marked not to be from ISO > >> 7816 but from a different standard. > > > > There is still the question, if this is the right place for a command > > not defined by iso. My answer is clearly not, because: > > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > > can code it's own proprietary commands in this class. Which in turn > > leaves the possibility, that two different vendors define the same apdu > > command in two completely different ways. > > 2. Not even a single card driver overrides iso_ops->give_random. So > > every driver would send this command down to the card. Which is not a > > good idea (see point one). > > Don't take the iso7816.c as a strict ISO-7816-X driver but more like a > "generic standards based driver other cards can extend". To bring this in > action, some code needs to use the function and that code would expect this > function to either work for a card or be overriden by the card driver. > > As long as it is not used currently, it can as well be removed for you peace > of mind for now. As long as card options is arbitrarily extended with the > function when needed, I don't see why it could not be in iso7816.c with a > nice "warning" in the source code. > > For example, try to explain why the ISO GET CHALLENGE code from year 2001 > reads the random from the card in 8 byte chunks? Because it's the most generic solution, that will work on every card. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel