Peaceful coexistence of GnuPG and other smart card software

[Martin Paljak]

Hello,

On Thu, Aug 11, 2011 at 10:28, Werner Koch <wk at gnupg.org> wrote:
> On Wed, 10 Aug 2011 18:24, martin at martinpaljak.net said:
>
>>  - removing exclusive mode and relying on transactions(SCardBeginTransaction/SCardEndTransaction) for smart card access (at least making it *easily* configurable)
>
> That is not possible because scdaemon caches most card informtaion.
> Thus we need exclusive access or a way to know if other applications
> changes the card data.

Well. scdaemon can assume that other applications talk to the same
application on the card and do not change *information* but only
application state, or start from a "known good state" on every
transaction. I have not investigated the normal usage pattern with
scdaemon, but I guess it should be feasible.


>>  - support for multiple readers, where the OpenPGP card/token is not the first reader
>
> There is support for multiple readers and it has been tested and used in
> an actual product many years ago.  See --reader-port for a starter.
> There are likely bugs in it.

Readers often change dynamically, especially with laptops. The logical
solution would be location a suitable card from all present readers,
not changing scdaemon.conf on every invocation. To be honest, I'm
using OpenPGP through gpg2, where the only options are --card-edit and
--card-status. I don't know if I would want to know the presence and
internals of gpg2/gpg-agent/scdaemon if I don't *have* to.


>>  - maybe some better error messages (though I doubt I can/want bite through the scdaemon/assuan/gpg-agent microsystems)
>
> You mean that it is easier to see things like EEPROM FAILURE?  This can
> be done and is not very complicated.

I mean meaningful errors that would help me to locate the problem,
like "no readers present" or "agent is faulty" instead of "Card error"
or "Unsupported certificate".


>> Would such changes be of interest and be included with GnuPG?
>
> I would be more interested in an pcsc driver making use of scdaemon's
> APDU command.  That is using scdaemon as the low-level driver and put
> pcsc on top of it.

That's more like a chicken and egg problem. Rest of the world uses
PC/SC and manages to get things done. It is far from a perfect
solution (the same for PKCS#11) but it works and is something people
from several sectors have managed to work with and build upon.

If there was a greedy application stack to allocate a device, it
should be the most appropriate and standard piece of the system. IMHO
PC/SC is that.

Best,
Martin