Peaceful coexistence of GnuPG and other smart card software

Werner Koch wk at gnupg.org
Thu Aug 11 14:51:45 CEST 2011


On Thu, 11 Aug 2011 11:09, martin at martinpaljak.net said:

> Well. scdaemon can assume that other applications talk to the same
> application on the card and do not change *information* but only

Assuming something is not a good operation mode for a security
application.

An easy way out of the exclusive access scheme would be a notification
from pcscd when an application has changed the card's state so that
scdaemon may flush its cache.


> 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

Scdaemon uses a reader id made up from the USB vendorid, productid and the
serialnumber.  For PC/SC access the PC/SC reader name is used.
Configuration utilities may use:

  $ gpg-connect-agent 'scd getinfo reader_list' /bye
  D 04E6:5116:21120804208192:0%0A
  OK

(this command does not yet list PC/SC reader).  

> 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".

One problem hese is that we try to use the same code for GnuPG-1 and
GnuPG-2.  We could get better error messages for the GnuPG-2 only case.

> 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

I have no problems with PC/SC; I merely suggest to loop PC/SC access
through scdaemon ;-)

> 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.

This is low-level and can't do the things a high-level application like
scdaemon is able to do.  Did you ever try to use X.509 card with several
applications - it takes ages do anything because card I/O is slow and
X.509 requires you to read a lot of stuff.  Well, unless the application
"assumes" a certain state of the card.  Ask some tester of the German
Health Card prototypes about their experience with the speed of the
applications (and that is mostly card I/O and not network bounded).

Scdaemon might not be the best design around as it is now a decade old
but it has advantages over other solutions.  The Free Software community
should at least demand free card specs to allow the implementation of
the card's host part using Free Software.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gnupg-devel mailing list