On Thursday, July 24, 2003, at 08:18 PM, Michael Bender wrote:
I have run into this same situation writing T=0 firmware for a reader. I have asked around to other smartcard groups, experts, reader firmware writers and even my guru :-) and there is absolutely no consensus on whether or not the reader or the application (or somebody in the middle somehwere) must handle GetResponse.
In my case, I handle it in the reader, but I have complaints from some smartcard application developers that tell me that their apps break because they *expect* to handle the GetResponse processing after a specific APDU - to me, that's just bogus programming, but what can you do?
One way to do it (it is the way it is done in the GemPC410/430 driver) is to check the length of the command buffer given in the SCardTransmit (works only for T=0 TPDU):
Case 1: Cmd = CLA INS P1 P2 L(Cmd) = 4 -> Treat as APDU
Case 1: Cmd = CLA INS P1 P2 P3 (=0) L(Cmd) = 5 -> Treat as TPDU
Case 2: Cmd = CLA INS P1 P2 Le L(Cmd) = 5 -> No difference between TPDU and APDU (T=0)
Case 3: Cmd = CLA INS P1 P2 Lc Data L(Cmd) = 5 + Lc -> No difference between TPDU and APDU (T=0)
Case 4: Cmd = CLA INS P1 P2 Lc Data Le L(Cmd) = 5 + Lc +1 -> APDU, perform chaining
Case 4: Cmd = CLA INS P1 P2 Lc Data L(Cmd) = 5 + Lc -> TPDU, treat as Case 3 and return 61 xx.
Any comments?
Cheers, JLuc.
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
