Damien: Thanks for the help on T0, host side.
I am interfacing to muscle-enabled ICCs using a TLP224 socket service: no UART, no
USB, and no RF: the client proxy does not happen to T0.retry, or T0.GetResponse. Rather,
the TLP224 provider supplies a somewhat end-end comms service, with some client access
point processing of outgoing C-ADPUs.
Normally, my transport access point delivers good and error TPDU responses requiring further
processing to the host. However, it also locally processes certain C-APDUs which, on the
last protocol run produced a "6c <n>". IN this case, when the next C-APDU repeats the
same APDU that caused this 6c response, the local access point will simply repeat the 6c <n>
response, without communicating with the ICC.
When does this happen in muscle? and what is is the issue?
It happens on muscleAPI's/Tool's ListKeys, when you repeat the command. Muscle may have
a protocol design flaw in this facility of the CardEdge wire protocol: it normally
indicates the end of a polling sequence (for n keys) by issuing a 6c <n>. Muscle
framework assumes this positive response means stop polling for keys. Should an application
then repeat the listKeys command, the same C-APDU
is sent as in the last run, causing the cited local access point processing. The result
is - one cannot repeat the listKeys, without doing a release/connect to reset my
proxy. This affects practical application sequences such as -> listKeys -> Crypt ->, where
crypt first does a listKeys behind the scenes, so help to determine key capabilities and
determine C-APDU formating option.
The hack is for the client to do "listKeys -> release -> connect -> crypt" - with
an unacceptable N-Connect (i.e. TCP) overhead, however. The real solution is less clear,
and begs a wider question: what are we really doing with T0 at the host? This is the
right question to ask ultimately, as I note that the host sometimes does infact do some
T0 processing already: muscleTool - the host - is already programmed to recognize and
process T0's 61 <n> response, doing one (and unfortunately only one) poll for the
indicated number of response bytes.
Its not clear to me from the CardEdge protocol spec what the host *must* do (re T0), and
I'm not convinced the ListKey procedure is fully specified. An explicit end-of-sequence
message may be appropriate.
Peter.
I note the following:
Check out the new MSN 9 Dial-up � fast & reliable Internet access with prime features! _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
