Peaceful coexistence of GnuPG and other smart card software
wk at gnupg.org
Tue Aug 30 18:17:35 CEST 2011
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
> 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
> 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" .
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
> 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
> - locking the reader only when it is in fact used (for
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.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel