Hi Thomas,
I guess we will sooner or later need card specific get_response
commands. but that also means an architecture change: currently the
loop is done in the generic apdu.c code, and I guess it would need
to move into the card specific get_response code.
This change breaks PIV chaining.
sorry about that. I feared something like this would happen, but
commiting the change is the best way to find out. now we can revert
it or replace it with better code.
PIV Cards keep on returning 6100 until all of the data is read.
so how do you know how much data is there to read in total?
with cryptoflex cards and a 256 byte signature I could read
two times 248 bytes, but that result does not make sence.
Attached is a patch to the current svn (-r3097) to fix the previous
patch to work with PIV. It reverts some of the changes, but sets a cap
on the data received.
but will break cryptoflex.c again, I think.
with cryptoflex I get this:
- send signature apdu (2048 bit rsa), return 61 00
- get 256 bytes - reduced to 248 bytes - return 90 00
- get 8 bytes - return 90 00
if I try to get 248 bytes twice that also works, but the result
is broken.
how does the piv apdu chain look like?
After looking through things... it looks like this code does belong in
the ISO get_response, since it should be expected that get_response gets
_ALL_ of the response that it was expecting... though I suppose this
train of thought could be placed on apdu.c as well.
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. is the cryptoflex behaving right? the piv card?
maybe we should abandon the iso driver as "driver" at all, and instead
offer a set of generic functions each driver can use. 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.
comments?
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
