[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?

[Francois Grieu]

On 2022-02-08 at 23:53, s.ferey  wrote :
 > When T=0 protocol is used a case-4 can NOT contain a Le.

The definition of Case 4 is given by ISO/IEC 7816-3:2006 section 12:
] In case 4, Nc ≠ 0 and Nr ≠ 0. The command APDU consists of the header, the Lc 
field, the command data field and the Le field. The response APDU consists of 
the response data field and the trailer.

Therefore, independently of the protocol, Le is present in a case 4 APDU, and in 
the corresponding Command APDU. Under T=0, Le must not be present in the first 
C-TPDU, nor physically sent to the card as part of that (only later on, 
conditionally). That does not tell if Le can/should be passed to ScardTransmit; 
or in other words if ScardTransmit is passed a C-APDU or a C-TPDU.

Under T=0 case 1, the specification of ScardTransmit REQUIRES passing to 
ScardTransmit the 4-byte C-APDU, not the 5-byte C-TPDU. Quoting 
https://docs.microsoft.com/en-us/windows/win32/api/winscard/nf-winscard-scardtransmit
} For T=0, in the special case where no data is sent to the card and no data 
expected in return, this length [of the data passed to ScardTransmit] must 
reflect that the bP3 member is not being sent; the length should be 
sizeof(CmdBytes) - sizeof(BYTE) [that is 4]

I'm ready to admit ScardTransmit is supposed to be passed a C-TPDU except as 
stated by the above quote. I just wish some reference stating that, before 
rejecting the alternative: ScardTransmit is supposed to receive the C-TPDU in 
all short cases and all protocols.

Perhaps useful to settle that debate: under T=1, even in short cases, it can be 
necessary to break the C-APDU into several C-TPDUs. Is that the job of 
ScardTransmit+driver, or is that the job of the application ?
In the first alternative, the logical input of ScardTransmit is a C-APDU. In the 
second, it's a C-TPDU with an exception for case 1 and T=0.
I hope that does not depend on if the reader is APDU-level or TPDU-level, 
because I know no portable way to tell which kind the reader is, and I expect 
ScardTransmit+driver to handle that particular mess.

   Francois Grieu