Re: [Muscle] SCARD_CTL_CODE macro introduction

[Peter Williams]

----- Original Message ----- 
From: <[EMAIL PROTECTED]>
To: "MUSCLE" <muscle@lists.musclecard.com>
Sent: Tuesday, March 15, 2005 1:31 AM
Subject: Re: [Muscle] SCARD_CTL_CODE macro introduction

If we think about the DSP in modern readers, with match on board 
capabilities within the reader for pin/userid, we recognise that these DSP 
chips themselves also have communciation periperhals. One such peripheral 
is a USB OTG port, another is a bus mastering I2C hardware block. A third 
is a near field enumerator for peers. The ioctl() feature procedure might 
enumerate these capabilities to the driver, which reports them through to 
the PC/SC application.

There are really two or more layers of feature enumeration: (1) enumerating 
the features to access the most local reader access point, and then (2) 
enumerating the capabilities of the reader. Obviously the process repeats, 
for n links in the transport chain.What appears at a local access point, 
may in reality be n links away.

If we take an example, we see that a PC box enumerates its readers on the 
USB, one of which is a virtual port to a remote PCSC device, over an 
Citrix/RDP session, which enumerates the capabilities of a DSP, which has a 
number of peripherals, such as 6 I2C ports, two mifare blocks, and 4 near 
field functional units. One of the near field "slots" reports that there is 
a peer in range, and is mifare2k mode. Another reports that another peer is 
publishing the fact that one must (remotely) activate the (remote) 
match-on-board capabilities via the finger reader built into the dongle (n 
steps removed), before its willing to act (locally) as a T=CL device, 
tunneled within a near field transport tunnel.

Ok. its a convoluted example. But, is this really the kind of enumeration 
which we are expecting the meager unix ioctl() feature enumerator to 
handle? And we expect the PC/SC application to do something with this, 
detail?

Surely we are in the classic case of designing the intelligence either into 
the network security interface device (the IPSEC way) or the socket (the 
SSL way).  If we really are focusing on designing a scalable and 
infrastructure grade communications feature design pattern, we have to 
emulate the dynamics of winsock socket enumerations and sub-layering, not 
the meager-minded, highly localized ioctl()s?

I suspect I'm missing the point of the teletrust architecture. Perhaps some 
context discussion would help? Is it just attempting to determine whether a 
very local reader has a trusted pinpad, or bio DSP? 
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle