Peaceful coexistence of GnuPG and other smart card software
wk at gnupg.org
Fri Aug 26 15:52:29 CEST 2011
On Thu, 11 Aug 2011 15:53, martin at martinpaljak.net said:
> Even though "assumption is the mother of all screw ups", the card is
> mostly used to access cryptographic keys. Verifying the cryptographic
> integrity if the response from the card is far better and meaningful
> than tracking "card state".
It is not about integrity but about user experience. For example if we
know that we did a verify we don't need to ask the user for the a PIN.
Sure we could also try to do it without a a verify and only ask for the
PIN if the operation failed. It turned out that the way we do it now is
much more user friendly.
> Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I know
> that this is probably not what you mean, but still.
> Also, I don't know how GnuPG works on Windows, but I doubt it is easy
> or even possible to change the way Windows PC/SC service works.
PC/SC under Windows does the same as pcsclite - no problem at all.
> OpenSC also used to have "static numbering of connected readers" but
> this has proven to be inefficient in current environments as (well,
> mostly for PKCS#11 based applications, more established platforms
> (Windows, OS X) have their own frameworks)
We do this for years without any problems (at least for the few who use
more than one reader); we merely did not implement the list feature.
>> I have no problems with PC/SC; I merely suggest to loop PC/SC access
>> through scdaemon ;-)
> You mean using scdaemon+its CCID driver instead of libccid? Why? Any
No, I mean using pc/sc - it is actually what GnuPG does on Windows and
on Unix if it is not possible to use the internal driver. As said
before: the internal CCID driver was needed because we had CCID readers
but no support for them in pcsclite. I like to keep it because it
removes an unnecessary library and daemon dependency and actually allow
the use of readers which are not supported by libccid (old SCR335).
> Accessing smart cards is a low level thing. Much like accessing USB
> devices. Or PCI cards. Or other external hardware.
USB and PCI are different things. USB is for large parts a replacement
of RS232 which has always been used directly from userland. Thus using
an USB port directly from userland is a clean way of engineering.
> Yes, one of the things missing in Linux is a "central service" (a
> daemon) that manages the "more meaningful" higher level access to
> smart cards (Tokend on OS X/Minidriver in Windows) and it stems from
> the lack of an agreed-upon framework in Linux. There would be
I am not talking about a certain operating system kernel. GnuPG is not
related to Linux; I for example use it with *BSD all the time. You may
view scdaemon/gpg-agent as this central service.
> The same way it would make sense to support PKCS#11 and let the user
> decide what he/she wants to risk with - either using his keys with a
> proprietary (or free!) PKCS#11 stack with GnuPG or being forced to the
pkcs#11 does not make any sense at all. It is a kludge to support the
ugluy NSS based applications.
> While I feel your concern for open specs (OpenSC has many open source
> drivers with no public docs at the same time), but there's a
Most of the core OpenSC code is (was?) about creating card applications
and not about accessing cards. The whole pkcs#15 business in OpenSC is
way to complicated for accessing pkcs#15 cards; you don't need all the
additional layers and the often unconsciously changed ABI. PKCS#15 was
once established with the idea to make card access easy and uniform. It
does not work, but that's a different story.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel