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

Reply via email to