From: Martin Preuss (aquamaniacgmx.de)
Date: Wed May 02 2007 - 17:36:29 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wednesday 02 May 2007 23:52, Martin Paljak wrote:
> On 03.05.2007, at 0:38, Martin Preuss wrote:
[...]
> > In general I don't have problems with having a variety of APIs
> > (although one
> > single API would greatly simplify the application programmers work)
> > as long
> > as none of them tries to bind the readers exclusively.
>
> Please describe the situation and motivation behind this.
> Why does it matter if pcscd grabs the readers ? Because existing
> CTAPI drivers (needed for
> secure communication with the reader) are then blocked out ?
>
> Why not bomb reader companies to deal with the driver (and thus API)
> problem ?
[...]
I don't think that reader manufacturers care that much about Linux (some do,
but the majority doesn't). Meanwhile we have to deal with the situation as it
is.

[...]
> What should be done differently (except for the design decision 'grab
> or not to grab')
> so that there could be only one reader access layer/api/library on
> Linux that would focus on
> 'card communication via whatever channel' ?
[...]
On the lowest layer I need at least:
- support for different driver types (especially IFD and CTAPI, since there
still are drivers for both interfaces)
- commands:
  - look for a card, wait for insertion if necessary
  - lock/unlock a card
  - send commands
  - release card
- information: Manufacturer of the reader, driver/firmware version if possible
etc. This is needed for abstraction of differences in APDU's on different
readers.
- access to both processor *and* memory cards

In addition I'd like to have (and therefore implemented it in Libchipcard):
- secure access to readers at remote hosts (not as remote as via internet but
within an intranet)
- the master-slave model described in the document Micha linked to in his
mail), this is needed for thin-client support provided for Gnumed

[...]
> Libchipcard works on Windows (partially). This means it SHOULD work
> on linux/mac via pcsclite as well
> (given my assumption that most ctapi drivers are implemented on top
> of pcsc is correct).
[...]
It *does* work over PC/SC, but that interface doesn't let me use CTAPI drivers
so it excludes those readers for which there only are CTAPI drivers (which
could of course be circumvented by adding an IFD-CTAPI wrapper).

Also, currently there is no standard way how to use memory cards on every
PC/SC implementation: pcsclite allows me to connect such cards by specifying
the protocol "raw" but that doesn't work on Windows and it also doesn't work
with some proprietary (binary-only) readers.

And last, but certainly not least, is the issue with the definitions of DWORD
etc which prevents mixing of 32- and 64 bit clients with one pcscd (or have
this meanwhile been solved? And what about the byteorder stuff? Is that
solved?)

Regards
Martin

--
"Things are only impossible until they're not"

AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]