Andreas Jellinghaus wrote:
...
I guess we will need to move the loop logic into the iso function, so
each card can have it's own loop logic. now what I don't know what the
common case should be.
I think we should keep it in apdu.c. If an APDU returns 0x61xy
we should try to read at least xy more bytes regardless if the
card returns 0x9000 inbetween (if the card tells you that it has
n bytes available and is only capable of returning m < n bytes
then I would consider this a bug). This should help the
cryptoflex card and it should not hurt the piv card (as long
as it doesn't make any false promises about the amount of
bytes still avaiable ;-) ).
If this sounds reasonable I will prepare a patch.
is the cryptoflex behaving right? the piv card?
IMHO both are right ;-) the piv card is right because a 0x6100
response simply means that there are 256 bytes available, but
doesn't mean that there are at most 256 bytes to available. The
cryptoflex card returns 0x61xx once with the number of bytes
available and 0x9000 after the GET RESPONSE calls. As 0x9000
simply means "normal processing" and not that no more data is
available the behaviour of the cryptoflex card might appear
strange but it should be in accordance with iso7816-4.
maybe we should abandon the iso driver as "driver" at all, and instead
offer a set of generic functions each driver can use.
hmm, the iso driver is this collection of generic functions ...
so we provide have
two or three get_response implementations, and each driver can choose
the right one. still less code, if several cards need their own
implementation.
Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
