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):
I have some comments about this behaviour but I also think that the choices about the case must be done using length of the command buffer given in the SCardTransmit.
Case 1: Cmd = CLA INS P1 P2 L(Cmd) = 4 -> Treat as APDU
Ok.
Case 1: Cmd = CLA INS P1 P2 P3 (=0) L(Cmd) = 5 -> Treat as TPDU
Ok but it is a Case 2 and not a Case 1! It is only a detail.
Case 2: Cmd = CLA INS P1 P2 Le L(Cmd) = 5 -> No difference between TPDU and APDU (T=0)
For me in the case 2S.3 the chaining (on SW=6Cxx) must also be done. And thus as for me the previous case is a Case 2, it must follow this behaviour.
Case 3: Cmd = CLA INS P1 P2 Lc Data L(Cmd) = 5 + Lc -> No difference between TPDU and APDU (T=0)
Ok for this.
Case 4: Cmd = CLA INS P1 P2 Lc Data Le L(Cmd) = 5 + Lc +1 -> APDU, perform chaining
Ok here also. I think that the chaining is important on a return of 61xx in the FIRST TPDU exchange ONLY and on a return on a 9000 in the FIRST TPDU exchange also.
After the second TPDU exchange if the SW=61xx you must forward it with the data received to the application. It is its problem if it have not request the good length of data byte.
In the PC/SC specification of the PC/SC workgroup the Case 4 cannot be used. See p19 of [2].
This imply that the application developer must knowing the underlying protocol. That goes against the APDUs that are abstraction for the application used over the TPDU (T=0 or T=1 or ...)
The IFD Handler 3 document seems want to follow the specification of the workgroup because it is now described that "it is not the responsability of the ifdhandler to do the chaining". This is the subject of this thread.
Case 4: Cmd = CLA INS P1 P2 Lc Data L(Cmd) = 5 + Lc -> TPDU, treat as Case 3 and return 61 xx.
I don't understand this? This is a Case 3 because there is no Le. Perhaps you thank about something as:
Cmd = CLA INS P1 P2 Lc Data Le
L(Cmd) = 5 + Lc where L(Cmd) is the parameter TxLength of IFDHTransmitToICC.
And in this case we are realy in a Case 3 because the application have given the L(Cmd) = 5 + Lc and have chosen to treat the GET RESPONSE itself. Thus it is normal to treat this case as a Case 3.
My only difference with JL is that I call it "Case 3" and not "Case 4" . Ofen the apdu is ofen a "byte[]" with a fixed size as big as the maximum APDU size (in order to allocate/desallocate many time) and if you take the previous Case 3 of JL after the Data field there is also a "byte" with a value but we see it. We just consider the first L(Cmd) bytes of this buffer.
Except theses details I LIKE this behaviour.
[1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx [2] http://www.pcscworkgroup.com/Specifications/p3v10_ps.gz
I hope that I have not forget something but I am hungry and I have quickly done my answer.
Regards,
Damien Sauveron
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
