The statment by Thomas Schaeck is clearly not representing what ISO is
defining as an APDU (He refers clearly only to the transport layer).
To our understanding the Card Terminal driver must hide this
implementation totaly from the Card Service. It is anyhow unclear who
is talking in T=0 to whom. The communication between card and terminal
may be in T=0 but the Terminal will talk with the Host in T=1 (in this
case the Terminal may already handle the 61 XX by itself) or
viceversa.
The nice feature of the OpenCard Framework is that you can write Card
Services which will work without having to deal with implementatiomn
details. The APDUs (C-APDU and R-APDU) are protocol independent and
the mapping of TPDUs to APDUs for T=0 is defined in ISO/IEC 7816-3 and
7816-4:
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.
The statement by Schaeck that this behaviour is needed to handle
wrongly programmed T=1 cards is totally ununderstandable. The Terminal
Driver should know in which protocol he is talking to the Terminal and
behaive accordingly (Ignore 61 XX in case of T=1).
Also we feel that the OpenCard Framework should be a user interface to
talk to SmartCards from JAVA and is not needed nor usable as a debug
tool to develop and test transport protocol implementations on
SmartCards.
If the philosophy of OpenCard is not to be a transparent API layer for
communication with a SmartCard we feel that it is unusable and should
be replaced.
Regards
Dr. Martin Merck
Giesecke & Devrient GmbH
____________________________ Antwort-Abtrennung ________________________________
Betreff: Re: [OCF] Card Terminal behaviour when SW1=0x6c
Autor: MIME:[EMAIL PROTECTED] bei INTERNET
Datum: 14.04.99 10:12
Recently, there was some discussion about how to handle the T=0 protocol in
OpenCard, or to be more exact, how to handle T=0 Case 4. This is the case
where the card indicates that its result has to be obtained by sending a
subsequent GetResponse command. The return code indicating this case is
0x61 XX, where XX is the length of the response to be retreived.
When designing the OpenCard Framework, we defined the card terminal layer
role in communication with cards as follows: The card terminal layer
transparently sends command APDUs to smart cards and returns the response
APDUs. It does not interpret or modify the transmitted APDUs in any way.
It is important to have such a transparent communication path. Only some
examples: How would a card applet programmer be able to test how a T=0 card
reacts if a wrong GetResponse command is sent to the card after obtaining
61 XX if the card terminal driver handles this automatically ? What if
someone wrote an Applet for a T=1 JavaCard that returns 61 XX due to a
programming error ?
All interpretation of APDUs is the task of the card service layer. Card
services have the responsibility of handling the application protocol
required by the card - even if the application protocol has a special case
due to the missing support for two way flow in T=0.
Best Regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division - Smart Card Solutions
E-mail: [EMAIL PROTECTED] Tel.: ++49-7031-16-3479 Fax.:
++49-7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
[EMAIL PROTECTED] on 14.04.99 05:24:43
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Thomas Schaeck/Germany/IBM)
Subject: Re: [OCF] Card Terminal behaviour when SW1=0x6c
In einer eMail vom 13.04.99 17:15:10 MEZ, schreiben Sie:
<< Thema: [OCF] Card Terminal behaviour when SW1=0x6c >>
Hi,
in my eyes, the transport layer of the CardTerminal implementation
- i.e. the clases that manage the exchange of APDUs according to an
ISO-7816 protocol T=x - is responsible for handling the '0x6C 0xLe' case,
where 0xLe gives the correct number of bytes generated by a card command.
A CardServivce (running somewhere between OSI presentation and application
layer) should be isolated as much as possible from protocol specific tasks.
In general, it must work with every card 'understanding' the command APDUs
transmitted, whether speaking T=0 or T=1.
Best regards.
----------------------------------------------------------------------
Markus A. Stulle - Schlei�heimer Stra�e 70 [EMAIL PROTECTED]
D-80797 Muenchen - Germany
Tel./FAX: (+89) 520 59 001, GSM: (+171) 213 - 70 84
GSM-FAX: (+171) 214 - 84 74, GSM-Data: - 86 74
AOL-FAX: (+40) 36 03 - 02 00 16
'Java Madman' Current Java version is: Java 2
Available at: http://java.sun.com/products/jdk/1.2
-----------+===+------------------------------------------------------
> press |ESC| key once to abort program or twice to continue! <
-----------+===+------------------------------------------------------
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.
{\rtf1\ansi \deff0\deflang1024{\fonttbl{\f0\froman Tms Rmn;}{\f1\froman Symbol;}{\f2\fswiss Helv;}}
{\colortbl;\red0\green0\blue127;\red0\green127\blue0;\red0\green127\blue127;\red127\green0\blue0;
\red127\green0\blue127;\red127\green127\blue0;\red127\green127\blue127;;\red0\green0\blue255;
\red0\green255\blue0;\red0\green255\blue255;\red255\green0\blue0;\red255\green0\blue255;
\red255\green255\blue0;\red255\green255\blue255;}\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440
\gutter0 \defformat\sectd \pard\plain {\plain \f0 \cb7 \cf0 \cb1 \cf7 \
\cb1 \cf7 \cb1 \cf14 The statment by Thomas Schaeck is clearly not representing what ISO is \
\cb1 \cf7 \cb1 \cf14 defining as an APDU (He refers clearly only to the transport layer).\
\cb1 \cf7 \cb1 \cf14 To our understanding the Card Terminal driver must hide this \
\cb1 \cf7 \cb1 \cf14 implementation totaly from the Card Service. It is anyhow unclear who \
\cb1 \cf7 \cb1 \cf14 is talking in T=0 to whom. The communication between card and terminal \
\cb1 \cf7 \cb1 \cf14 may be in T=0 but the Terminal will talk with the Host in T=1 (in this \
\cb1 \cf7 \cb1 \cf14 case the Terminal may already handle the 61 XX by itself) or \
\cb1 \cf7 \cb1 \cf14 viceversa.\
\cb1 \cf7 \
\cb1 \cf7 \cb1 \cf14 The nice feature of the OpenCard Framework is that you can write Card \
\cb1 \cf7 \cb1 \cf14 Services which will work without having to deal with implementatiomn \
\cb1 \cf7 \cb1 \cf14 details. The APDUs (C-APDU and R-APDU) are protocol independent and \
\cb1 \cf7 \cb1 \cf14 the mapping of TPDUs to APDUs for T=0 is defined in ISO/IEC 7816-3 and \
\cb1 \cf7 \cb1 \cf14 7816-4:\
\cb1 \cf7 \cb1 \cf14 To our understanding a good card terminal driver should also perform \
\cb1 \cf7 \cb1 \cf14 the re-issuing of commands in T=0 case 2 when the card responds with \cb1 \cf7 \
61 \cb1 \cf14 XX if the card terminal driver handles this automatically ? What if \
\cb1 \cf7 someo\cb1 \cf14 ne wrote an Applet for a T=1 Jav\cb1 \cf7 aCard\cb1 \cf7 that\cb1 \cf14 returns 61 XX due to a \
programming error ?\
\
All interpr\cb1 \cf7 etati\cb1 \cf14 on of APDUs is the task of the card service layer. Card \
services have\cb1 \cf7 the \cb1 \cf14 responsibility of handling the application protocol \
required by the c\cb1 \cf7 ard -\cb1 \cf14 even if the application protocol has a special cas\cb1 \cf7 e \
d\cb1 \cf14 ue to the missing support for two way flow in T=0.\
\
Best Regards\cb1 \cf7 ,\
\cb1 \cf14 \
Thomas\
\
Thomas Schaeck\
IBM Pervasive Computing Division \cb1 \cf7 - Sma\cb1 \cf14 rt Card Solutions\
E-mail: [EMAIL PROTECTED] Tel.: ++49-\cb1 \cf7 7031-\cb1 \cf14 16-3479 \cb1 \cf7 Fa\cb1 \cf7 x.: \
\cb1 \cf14 ++49-7031-16-4888\
Address: IBM Deutschland Entwicklung GmbH, Schoenaic\cb1 \cf7 her S\cb1 \cf14 tr. 220, 71032 \
Boeblingen, Germany\
\
\
\
MarkStulle@\cb1 \cf7 aol.c\cb1 \cf14 om on 14.04.\cb1 \cf7 99 05\cb1 \cf7 :24:4\cb1 \cf14 3\
\cb1 \cf7 \
Pl\cb1 \cf14 ease respond to \cb1 \cf7 MarkS\cb1 \cf14 [EMAIL PROTECTED]\
\
To\cb1 \cf7 : [EMAIL PROTECTED]\
cc: [EMAIL PROTECTED] (bcc: Thomas Schaeck\cb1 \cf7 /Germany/IBM) \
Subject: Re: [OCF] Card Terminal behavi\cb1 \cf7 our when SW1=0x6c\
\
\
\
\cb1 \cf7 \
\
\
In eine\cb1 \cf7 r eMa\cb1 \cf7 il vo\cb1 \cf7 m 13.04.99 17:15:10 MEZ, schreiben Sie:\
\
<< Thema: [OCF] Card Termin\cb1 \cf7 al behaviour when SW1=0x6c >>\
\
\
Hi,\
\
in my eyes, the t\cb1 \cf7 ransport layer of the CardTerminal implementation \
- i.e. the clases tha\cb1 \cf7 t manage the exchange of APDUs according to an\
ISO-7816 protocol T=x - \cb1 \cf7 is responsible for handling the '0x6C 0xLe' case, \
where 0xLe g\cb1 \cf7 ives \cb1 \cf7 the correct number of bytes generated by a card command.\
\
A CardSer\cb1 \cf7 vivce (running somewhere between OSI presentation and application \
l\cb1 \cf7 ayer) should be isolated as much as possible from protocol specific tasks.\cb1 \cf7 \
In general, it must work with every card 'understanding' the command \cb1 \cf7 APDUs\cb1 \cf7 \
transmitted, whether speaking T=0 or T=1.\
\
Best regards.\
\
\cb1 \cf7 ---------------------------------------------------------------------- \
Mar\cb1 \cf7 kus A. Stulle - Schlei\'e1heimer Stra\'e1e 70 [EMAIL PROTECTED]\
\cb1 \cf7 D-80797 Muenchen - Germany\
Tel./FAX: \cb1 \cf7 (+89) 520 59 001, GSM: (+171) 213 - 70 84 \
GSM-FAX:\cb1 \cf7 (+171) 214 - 84 74\cb1 \cf7 , GSM\cb1 \cf7 -Data: - 86 74 \
AOL-FAX: (+40) 36 03 - 02 00 16\
\cb1 \cf7 'Java Madman' Current Java version is: Java 2\
A\cb1 \cf7 vailable at: http://java.sun.com/products/jdk/1.2\
-----------+===+-------\cb1 \cf7 -----------------------------------------------\
\cb1 \cf7 > pr\cb1 \cf7 ess |ESC| key\cb1 \cf7 once\cb1 \cf7 to ab\cb1 \cf7 ort p\cb1 \cf7 rogram or twic\cb1 \cf7 e to continue! <\
-----------+===+---------------------\cb1 \cf7 ---------------------------------\
\
Visit the OpenCard Framewor\cb1 \cf7 k's WWW site at h\cb1 \cf7 ttp://www.opencard.org/ for \
access to documentation, code, presentatio\cb1 \cf7 ns, and OCF announc\cb1 \cf7 ement\cb1 \cf7 s. \
\cb1 \cf7 -----\cb1 \cf7 ---------------------------------------\cb1 \cf7 -----\cb1 \cf7 -------------------------- \
--\
To \cb1 \cf7 unsub\cb1 \cf7 scribe from the OCF Mailing\cb1 \cf7 list, send a mail to \
"[EMAIL PROTECTED]" with the wo\cb1 \cf7 rd "unsubscribe" in the BODY of \
the\
message.\
\
\cb1 \cf7 \
\cb1 \cf7 o abo\cb1 \cf7 rt pr\cb1 \cf7 ogram\cb1 \cf7 or t\cb1 \cf7 wice \cb1 \cf7 to continue! <\
-----------+===+------------------------\cb1 \cf7 -----\cb1 \cf7 -------------------------\
\
Visit the OpenCard Fram\cb1 \cf7 ework\cb1 \cf7 's WW\cb1 \cf7 W s\cb1 \cf7 ite a\cb1 \cf7 t http://www.opencard.org/ for \
access to documentation, code, pre\cb1 \cf7 sentations, and OCF announcements. \
------------------------------\cb1 \cf7 --------------------------------------------- \
--\
To unsubscribe from th\cb1 \cf7 e OCF Mailing list, send a mail to \
"[EMAIL PROTECTED]" with\cb1 \cf7 the \cb1 \cf7 word "unsubscribe" in the BODY of \
the\
message.\
\
\
o abort pr\cb1 \cf7 ogram or twice to continue! <\
-----------+===+-----------------------------\cb1 \cf7 -------------------------\
\
Visit the OpenCard Framework's WWW site a\cb1 \cf7 t http://www.opencard.org/ for \
access t\cb1 \cf7 o doc\cb1 \cf7 umentation, c\cb1 \cf7 ode, \cb1 \cf7 presentations, and OCF announcements. \
-------------------------------\cb1 \cf7 -------------------------------------------- \
--\
To unsubscribe from\cb1 \cf7 the OCF Mailing li\cb1 \cf7 st, send a mail to \
"open\cb1 \cf7 card-request@openca\cb1 \cf7 rd.org" with the word "unsubscribe" in the BODY of \
\cb1 \cf7 the\
message.\
\cb1 \cf7 \
\
o abort program or twice to continue!\cb1 \cf7 <\
-----------+===\cb1 \cf7 +------------------------------\cb1 \cf7 ----\cb1 \cf7 --------------------\
\
Visit the OpenCard\cb1 \cf7 Framework's WWW si\cb1 \cf7 te at http://www.opencard.org/ for \
access to docu\cb1 \cf7 mentation, code, presentations, and OCF announcements. \
-------------\cb1 \cf7 ---\cb1 \cf7 ----------------------------------------------------------- \
-\cb1 \cf7 -\
To unsubscribe from the OCF Mailing list, send a mail to \
"opencar\cb1 \cf7 d-req\cb1 \cf7 [EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of \
the\
mes\cb1 \cf7 sage.\
\
\
o abort program or twice to continue! <\
-------\cb1 \cf7 ----+===+------------------------------------------------------\
\
Visi\cb1 \cf7 t \cb1 \cf7 the OpenCard Framework's WWW site at http://www.opencard.\cb1 \cf7 org/ for \
access to documentation, code, presentations, and OCF announceme\cb1 \cf7 nts\cb1 \cf7 . \
----\cb1 \cf7 -----\cb1 \cf7 -----\par }}m
