From: Damien Sauveron (sauveronlabri.fr)
Date: Wed Aug 06 2003 - 06:22:29 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In order that always may follow the thread you can find the iso7816-4
here [1].

> 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
Musclelists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]