Peaceful coexistence of GnuPG and other smart card software

[Werner Koch]

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

See above.

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


Shalom-Salam,

   Werner


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