The problem of protocol independence is a large debate which occurs also in PC/SC and the problem of conversion from APDU to TPDU and vice versa is not always a conversion one to one. I think that a CardService should have the possibility to use both APDU and TPDU but in most of the cases it would like to use only APDUs to be independent on the protocol. In PC/SC, it is kind of awkward because APDUs are sent but they are restricted to the protocol. That means that in T=1, APDU case 1, 2, 3 and 4 can be sent but with T=0 only APDUs case 1, 2 and 3 can be sent. And it is not TPDUs because for example for T=0 in case 1, only 4 bytes are sent (cla, ins, P1 and P2) and not 5 bytes as the TPDU requires. It has been like that to differentiate between receiving 256 bytes and sending 0 bytes. This implies if an API has to manage TPDUs it has to differentiate between incoming commands and outgoing commands particularly for T=0. The CardService should have only an APDU interface and therefore the same at the terminal level. However, it should be possible to provide in OCF a library to convert TPDUs to ADPUs and vice versa for the CardTerminal developer. Moreover, a protocol query method should be available in order to know for the card service if the card uses the T=0 or T=1 protocol. This way the CardService can work as PC/SC and restrict itself to send only case 1, 2 and 3 APDUs for the T=0 protocol and acts as if the APDUs were TPDUs. However, for the APDU case 2 with the automatic 7816-4 length adjustement, this functionnality should also be made configurable, turned on or off (with a flag for example in the APDU transmission). I agree that in most cases only 7816-4 APDUs should be used but when you develop for example debugging tools, development tools around smart card you might also want to use OCF and have a finer view of the protocol when developing for example JavaCard applets. The problem of conversion I was mentioning is the following: For a case 4, the APDU is "CLA INS P1 P2 Lc Data Le". In T=0, this has to be decomposed into 2 TPDUs which are an incoming command and a get response command: "CLA INS P1 P2 Lc Data" and "xx C0 00 00 Le" (Le can be modified from the SW1-SW2 of the incoming command). The problem is the determination of the class of the get response command and there is a lack in the ISO 7816-4. Some people interprets as the class should always be 0 (like in EMV) and some others like having the same class as the incoming order. And effectively, in the field, some T=0 cards have a different behavior on this particular subject. A possible implementation is to try one and if a wrong class error is returned, try the other! Christophe Colas Bull Smart Cards & Terminals Phone: 33 1 39 66 42 29 Fax: 33 1 39 66 43 51 mailto:[EMAIL PROTECTED] Visit us at http://www.cp8.bull.net. Christophe Muller <[EMAIL PROTECTED]> sur 04/15/99 06:22:40 PM Pour : [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] cc : [EMAIL PROTECTED], [EMAIL PROTECTED] (ccc : Christophe Colas/FR/BULL) Objet : [OCF-tech] Re: [OCF] Handling of T=0 Case 4 etc. in Terminals or Services ? Hello, [EMAIL PROTECTED] wrote: > Martin, > > I found your note very interesting, I think this detail of OCF is > worth some discussion. I agree. I have added the OCF Technical Committee mailing-list (tech@opencard) in the Cc line in order to maybe get feedback from other people from the TC on this subject (please leave both mailing-lists in Cc when you are replying). >>To our understanding the Card Terminal driver must hide this >>implementation totaly from the Card Service. > > I assume you mean the protocol implementation on the card, i.e. T=0, > T=1 or some kind of T=14. Hiding the card protocol completely would > be nice for card service programmers. Going this direction would > require that ALL CardTerminal implementations behave the same way, > that means all implementations which simply return the "61XX" or > "6CXX" as Jon Barber mentioned would need to be changed. That is true Thomas, OCF needs to specify to the CardTerminal implementers if they need to do the management or leave it to the upper layer. In this respect, I tend to agree with Markus and Martin that the CardTerminal layer *should* manage the TPDUs and all behaviors related to the transport protocol, freeing the CardService implementors from knowing if T=whatever is used.. :-) Dr. Martin Merck wrote: > To our understanding a good card terminal driver should also perform > the re-issuing of commands in T=0 case 2 when the card responds with > 6C xx. This is not mandatory as of ISO but should be for OpenCard to > quarantee protocol independence. Agreed. I am not an expert at all of the smarcard protocols, so I checked with Gilles, our reader drivers expert, to see what is done in the GemplusSerialCardTerminal driver. He told me that the CardTerminal is managing reissuing in case it is needed and he also believes that this is the right location for such a piece of code. What about other CardTerminal developers ? Can we get a general feeling of their position ? and maybe we could add an item to the next OCF Technical Committee meeting to be held in May about this issue.. Cheers, Christophe. = Bloody typical, they've gone back to metric without telling us. = = -- Charlie, Department of Works (Brazil) = Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for access to documentation, code, presentations, and OCF announcements. ----------------------------------------------------------------------------- To unsubscribe from the OCF Mailing list, send a mail to "[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the message.
