In T=0 there is only one Get Response TPDU required to be sent from the reader for each case 4 APDU.
7816-4:1995 App A applies, and I'm only looking at short commands and responses (A.4): Case 4S.2 the card performed the command but does not tell the reader how long the response data is - card sends 90 00. The reader may knows what length to expect (issues a Get Response asking for that length or any greater length), or it may issue a Get Response with Le = 00, and in both situations the card sends all the data. Case 4S.3 the card performed the command and sends 61 xx where xx is the length of data available. The reader shall send a Get Response asking for the minimum of the length expected in the APDU or the length from the previous 61 xx response. So if the APDU said 'expect 200 bytes' and the card says 'I have 50 bytes', the Get Response sends 'send 50 bytes'. But if the APDU said 'expect 50 bytes' and the card says 'I have 200 bytes to send', the reader is supposed to send a Get Response asking for only the 50 bytes. But 7816-4 is being rewritten, and we do not know what changes have been made (the authors refuse to produce a change list). Peter ----- Original Message ----- From: "Klauss Kirkegard" <[EMAIL PROTECTED]> To: "Peter Tomlinson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, June 01, 2004 10:55 AM Subject: Re: [OCF] TPDU/APDU > > In the ISO 7816-4 documentation in the Annex A a > 4-th case APDU is split in two TPDU. In the first TPDU > are snet the incoming data, and no expected length of > the answer. > > For this first APDU, there are two possible answers > from the card, one is the SW 90 00 , and the other the > SW 61 XX. > > As you say , the 90 00 is for agreeing with the > reader the length of the response. But in the first > TPDU, the expexcted length is not known(after the > first Get Reponse the expected length is known, and > after the second Get Response the card may agree on > the expected length). And I'm sure that the card can > return a status word of 61 XX for the first incoming > command TPDU. > > > --- Peter Tomlinson <[EMAIL PROTECTED]> wrote: > > An associate tells me that you never need to send 2 > > Get Response APDUs. He > > says you get 90 00 if you asked for a specific > > length of response and the > > card agrees with you. 61 xx is the card telling you > > what it wants to send. > > > > But there is definitely the problem that some card > > readers handle the full > > Case 4 processing, and some let the PC send the Get > > Response. Yet another > > problem with interoperability and interchangeability > > of components in this > > smart card area. > > > > Peter > > > > Peter Tomlinson > > Bristol, UK > > ----- Original Message ----- > > From: "Klauss Kirkegard" <[EMAIL PROTECTED]> > > To: "Amitabh Pastore" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Monday, May 31, 2004 1:49 PM > > Subject: Re: [OCF] TPDU/APDU > > > > > > > > > > Thank you Amitabh > > > > > > In the ISO7816-4 the 4-th case is split in two > > parts > > > as you said. The first part the command APDU , and > > > after this a GETRESPONSE. The first command APDU > > is > > > followed by an answer from the card, the answer > > can be > > > SW=90 00 or SW=61 XX. > > > > > > I don't really understand, based on which > > factors > > > the JCRE responds to the host side with one status > > > word or the other. > > > > > > I'm thinking about the Javacard APIs, for > > example > > > the suite: SetOutgoing (returns the number of > > bytes > > > that the host side expects from the card), > > > SetOutgoingLength(sets the length that the card > > wants > > > to send to the reader), and SendBytes. > > > > > > So basically , and please correct me if I'm > > wrong, > > > in the 4-th case. > > > First the incoming data are all read. The card, > > only > > > when the applet developer calls the SetOutgoing > > > function, or when the process method terminates > > > without any call to a Outgoing function, at this > > > moment the card sends back the SW 90 00. > > > After this, the host side, or the reader sends > > an > > > apropiate GET RESPONSE command, and when the > > applet > > > developer calls the SetOutgoingLength, then the > > card > > > responds with a TPDU containing a SW 61 XX. After > > this > > > the host side again sends an TPDU with another GET > > > RESPONSE and in the 5-th byte of this GET RESPONSE > > the > > > host side sets the XX received in the second > > status > > > byte from the card. > > > > > > After this second GET RESPONSE, the card > > starts > > > sending out the real bytes. > > > > > > Again in the 4-th case, if the card calls > > first > > > the SetOutgoingandSend method, with no call to the > > > SetOutgoing, SetOutgoingLength, SendBytes, then > > the > > > card answers ( this is the first answer from the > > card > > > after it has received all the incoming bytes) with > > a > > > status word like SW 61 XX, and the host side > > replyes > > > with a GET RESPONSE with the 5-th bute set to XX, > > and > > > after this the card starts sending out the data. > > > > > > Please correct me if I'm wrong. > > > > > > Do you know any place on the internet, or any > > book, > > > where I could find information like this that I'm > > > talking about in this email. > > > > > > Thank you! > > > > > > --- Amitabh Pastore <[EMAIL PROTECTED]> > > > wrote: > > > > Hi, > > > > > > > > Case 4 APDU is broken in 2 TPDUs as in this case > > > > card receives as well as > > > > well as sends out in a single command. > > > > > > > > As there is no way as per ISO 7816 to tell the > > card > > > > how many bytes are being > > > > sent in and how many bytes are expected back > > > > (remember this is in single > > > > apdu). APDU can not have both the Lc and Le > > fields. > > > > Therefore it has to be > > > > resolved at card reader end. In a case 4 APDU, > > card > > > > receives the APDU with > > > > incoming data and processes the command. It then > > > > notifies to the reader ot > > > > host, the number of bytes available as the > > response > > > > (as per ISO and EMV > > > > 61xx). This response is then retrived usinga Get > > > > Response command. > > > > > > > > Now comes the real issue. There is no standard > > way > > > > that all readers handle > > > > this situation. Some of the readers > > automatically > > > > issue the Get Response > > > > command upon receiving 61xx from card. On the > > other > > > > hand, some readers > > > > simply pass on this SW1SW2 to the external > > > > applications and it is duty of > > > > external application to issue a Get Response > > > > command. > > > > > > > > Therefore it is advisable to have built the > > logic in > > > > the application to > > > > decide whether to issue a Get Response or not > > based > > > > on the SW1SW2. > > > > > > > > There are tools to see the serial in/out > > activity > > > > but the one I have is > > > > proprietary. > > > > > > > > > > > > Thanks, > > > > Amitabh > > > > > > > > ----- Original Message ----- > > > > From: "Klauss Kirkegard" > > <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Sunday, May 30, 2004 10:58 AM > > > > Subject: [OCF] TPDU/APDU > > > > > > > > > > > > > > > > > > Hello > > > > > > > > > > I'm currently trying to understand the > > > > difference > > > > > between the TPDU and APDU protocols > > > > > > > > > > I have read some ISO materials, and I > > > > understood > > > > > that mainly the APDU 4-th case (when data are > > > > incoming > > > > > and data are outgoiong) is not mapped directly > > > > onto > > > > > the TPDU protocol. > > > > > As I have understood, the 4-th case is > > mapped > > > > into > > > > > two TPDUs, one normal Command APDU with no LE > > > > byte, > > > > > only the LC and the incoming data, and after > > this > > > > one > > > > > , a GET RESPONSE Command APDU with the LE as > > P3. > > > > > > > > > > I don't understand why this case can't be > > > > mapped > > > > > onto a singel TPDU, why the JCRE(for example) > > > > cannot > > > > > read all the incoming bytes of and 4-th case > > APDU, > > > === message truncated === > > > > > > __________________________________ > Do you Yahoo!? > Friends. Fun. Try the all-new Yahoo! Messenger. > http://messenger.yahoo.com/ > --- > Visit the OpenCard web site at http://www.opencard.org/ for more > information on OpenCard---binaries, source code, documents. > This list is being archived at http://www.opencard.org/archive/opencard/ ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email ! to ! [EMAIL PROTECTED] ! containing the word ! unsubscribe ! in the body.
