Peaceful coexistence of GnuPG and other smart card software

[Werner Koch]

On Tue, 30 Aug 2011 14:04, martin at martinpaljak.net said:

> User friendly would be if me as a user could use the card with the
> applications I chose, instead of being locked out totally for reasons

Card applications or host applications? For the former you merely need
to write an app-foo module to scdaemon.  For the latter you may use the
provided api or if you want pkcs#11, use scute.

> You asked for "notification from pcscd when an application has changed
> the card's state". PC/SC defines SCARD_W_RESET_CARD, is this what you

No, any write/put/verify/etc operation.  Right this means that pc/sc
would need to interpret the APDUs; thus it is likely that it needs to
send notify us most of the time.

> See above. I think what you have in mind is signalling on another
> level than PC/SC is designed to operate. PC/SC can not (SHOULD NOT)
> know which APDU-s change the logical card state, that is meaningful to

Agreed.

> which deals with more higher level "smart card mangling" with card
> groups and files and whatnot. I don't have strong belief in the

Well, we agree here.  Microsoft uses mini drivers, GnuPG uses scdaemon.

> Probably you then have quite static setups, even if you use multiple
> readers. Right now what I have to do is plug out all "non-permanent"

No problem as long as all readers have different names.  Beware of bugs
- it is probably not well tested because I always suggest the use of the
internal driver.

> For the rest of scenarios, there should be enough reasons for allowing
> multiple consumers to access a single hardware device (reader and/or
> card) in a multi-application desktop environment. Through PC/SC, as

Just configure the timeout value and it works.

> Disregard Linux and read it as "popular open source Unices".

GnuPG is also used on proprietary Unices.

> Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent,
> gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ...

You are mixing something:

- NSS and GnuPG are systems with very similar goals.  In particular they
  their usual use cases require a user interface.
- GNUTLS is a high level TLS library 
- Pcscd is a low-evel hardware abstraction library.
- OpenSC is a high level card application abstraction library.
- PKCS#11 is an API
- ssh-agent and gpg-agent are parts of larger systems (GnuPG and SSH)

> Fedora folks think that "NSS should be the central service for
> everything crypto" and have the "crypto consolidation effort" [1].

Because Redhat needs FIPS 140 validation for RHEL and once they decided
that the easiest way to do this is by using the already FIPS validated
NSS.

> Claiming any single vendor-defined interface with a single
> implementation to be the de facto "central service" in an open
> environment is not a smart move. Microsoft can do it and Apple can do

It is about free software and not about vendors.  At least for the GNU
project using GnuPG seems to be a very good choice.

> though it can use PKCS#11 which should be a good sign), gpg-agent
> fails and ssh-agent fails. And PKCS#11 wins IMHO.

Sorry, you can't compare gpg-agent and ssh-agent - see above.

> like K vs G or PGP vs X509 debate. I don't want to be forced
> G-everything or K-everything stack to get a meaningful experience, I'd
> like to choose what I want to use.

So what is the problem?  After all it is Free Software and nobody will
tell you what you are supposed to do with it.  This is freedom #0.

> Sorry, I don't buy that. PKCS#11 makes *much* sense in *many*
> applications having zero need for or knowledge of NSS.
> Take OpenSSH - last time I checked could use PKCS#11 without requiring

Right, it makes a lot of sense to them.  A stated goal of OpenSSH is to
allow the use by proprietary systems.  Thus they do everything to make
proprietary software vendors happy; i.e. use an pkcs#11 interface.
Checkout who works on OpenSSH and what they do for a living.

> PKCS#11 is far from perfect, but it is the only cross-platform,
> "stable" API which developers on Unices can use wihout falling for the

Well, Microsoft doesn't use it anymore.

> "K" vs "G" debate common in Linux. Which is much less productive than

I am not using any of these desktops.  I would never tie software I
maintain to one specific desktop GUI.

> About ABI: libopensc as a library has been deprecated for the reasons
> of not having a well designed API with the right level of abstraction
> and documentation in the first place and because there is a better

The reasons was more that OpenSC used to be a collection of smart card
related code with no common idea what to build.  I participated in the
early OpenSC development but turned away for this reason and because of
bad software maintenance style (API and ABIs changes at will).

>  * How could I help to debug the the problem, so that I could use gpg2
> for decryption. Would a debug log with max verbose settings help?

So what was the problem?  The card code in master needs some work; there
are some things which have not yet been implemented and we have not
ported changes from 2.0.

>  * If I was to "fix" (in my terms) the problems with scdaemon:
>   - selecting a suitable reader automagically without configuration
> file/command line changes

You mean the default reader should be the reader which most likely
supports most cards.  I.e. kick out all Omnicard and possible cheap
internal readers?

>   - locking the reader only when it is in fact used (for
> encryption/decryption)

Better use the timeout option.  If the timeout option should be enabled
by default we should discuss this.  If it works for more users better
than we should enable it. 

>  how should I continue? Should I fix gpg or gpg2? Or both? What is the
> relation between gpg1 and gpg2 codebases?

Forget about gpg1 and cards - after all it uses an installed gpg-agent
anyway before it falls back to the included code.  Thus without a
running gpg-agent it is does not grab the reader.  We source copy files
from 2.0 to 1.4; thus don't develop on the 1.4 branch.

If you want to fix something card related you better look at the stable
2.0 branch for now.

> Some general pointers would suffice, I've done some homework but
> probably not enough to succeed at once.

If you have problems feel free to ask; you may also jabber me (I use
guug.de jabber address).  If you want to write code, we need a copyright
assignments to the FSF.


Shalom-Salam,

   Werner

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