Smart card interface, OpenSC and OpenCT

[Laurent Pinchart]

> * OpenSC is a huge and complex library with an ever changing API and
>   often hidden ABI changes. It just makes too much trouble.

I understand that. Floating APIs/ABIs are very painful.

> * It requires your application to use pthreads which conflicts with
>   the use of another threading library; GNU Pth in our case.  This is
>   the actual show stopper.

Now, that's bad. How are applications/libraries supposed to cooperate when 
different threading libraries are used ?

> * We only need to _read_ PKCS#15 structures and not to _create_ them.
>   This was actually pretty easy to implement and took me only a few
>   days.  Still not complete due to the lack of test cards (aside of a
>   self-created pkcs15 card I do have only one other card
>   (Dienstausweis des BMI).

So we only need a small subset of what OpenSC provides. Ok.

> * OpenSC may only be used by LGPL software because it makes use of
>   OpenSSL.  It is possible to disable this by losing some
>   functionality; no distribution does it.

Right. libopensc only requires OpenSSL for the GPK-4000 and Oberthur cards. It 
can be disabled at compile time, in which case sc_pkcs15_wrap_data and 
sc_pkcs15_unwrap_data won't be available.

> > prefered way to interface a smart card reader in GnuPG ? Is it PC/SC ?
> > What about readers with a pin pad ?
>
> Either direct access via the interanl CCID driver or by PC/SC or
> ctAPI.  Adding OpenCT support won't be a problem.

OpenCT is (in my opinion) a cleaner API than PC/SC (which was designed for 
Microsoft Windows). I'd rather see the CCID readers supported through OpenCT 
and/or PC/SC than directly by GnuPG, as OpenCT and PC/SC can share a reader 
between separate applications. Any opinion about that ?

> > Zetes (the company that developped the Belgian eID software) contributed
> > LGPLed code to OpenSC to support the eID card. Should this code be ported
> > to GnuPG ?
>
> AFAIK, the card is a PKCS#15 one so in theory signing should already
> work with gpgsm. A textcard would definitley be helpful.

The card is a PKCS#15 with a few differences:

* The SELECT FILE doesn't return any FCI, so the file size isn't know. This 
doesn't seem to matter as GnuPG doesn't use the FCI. On a side note, 
iso7816_read_binary doesn't handle status bytes 6Cxx (Wrong Le field). 
Shouldn't it reissue the READ BINARY command with Le=xx ?

* The NonRep key needs a VERIFY PIN before each time it is used for a 
signature. Zetes enforced that by popping a GUI window up every time a 
signature was made. I don't like that solution, and it seems that GnuPG 
performs the VERIFY command before every signature anyway. Could anyone 
confirm that ?

My main concern here is to make sure that distributions can integrate smart 
card support in an easy and flexible way. This means that smart card readers 
must be managed by a single application/framework/daemon/whatever, namely 
PC/SC or OpenCT. Different applications can then communicate with the card, 
either directly (like GnuPG) or using a library (libopensc) with a 
higher-level API.

Comments are appreciate. Feel free to prove me wrong where I'm wrong :-)

Laurent Pinchart