[pkg-gnupg-maint] slides for tomorrow's report

[NIIBE Yutaka]

Hello,

It was good session.  I'm afraid I didn't answer well to the question
of scdaemon/pcscd thing.  So, I am writing some information now.

I think that the person who asked assumes something like common API so
that smartcard access can be more reliable.  PKCS #11 was considered
the one, and some still believe so, but I don't share this perspective.

(If it were true, I didn't need to develop Gnuk.)

I think that there are two different things:

  (1) card reader support (specifically, CCID reader support)
  (2) smartcard support (how we can support more smartcards).

For (1), scdaemon supports two method; (a) its internal CCID drive and
(b) PC/SC service.  On GNU/Linux (b) is used for most readers, while (b)
is used on Windows and MacOS X.


In GnuPG 2.0.x, scdaemon implementation was complicated.  Its internal
CCID driver was not good enough to support more card readers, and for
some readers PC/SC service was needed.  If a user needs to use PC/SC
service, pcscd daemon is used, but it is incompatible to Pth theread
library, thus, we had an independent helper program called
'pcsc-wrapper'.  So, we had scdaemon + pcsc-wrapper + pcscd (together
with libccid).

In GnuPG 2.1.x, situation has improved.  Firstly, we now use nPth
which is compatible to pcscd, so, we don't need pcsc-wrapper anymore.
Secondly, internal CCID driver has much been improved, and for most of
readers, it just works well.  So, pcscd is only required to specific
(uncommon) readers.


For (2), according to my experience, I think that PKCS #11 is not that
good standard.  In GnuPG, the approach is more application oriented or
application specific.  We have OpenPGPcard support, and OpenPGPcard is
only the target for OpenPGP functionality.  While we have support of
other smartcard, its usage is very limited; the support of other smart
card is not intended for private key for OpenPGP, but it's intended to
be used for X.509 only (and it's experimental).

For PKCS #11 API with NSS, there is Scute.  The idea is that we
support high level (and complex) API of PKCS #11, on top of scdaemon
implementation of OpenPGPcard support.  Scute offers PKCS #11 API by
bridging scdaemon.

Unfortunately, Scute development is dead.  In my opinion, PKCS #11 is
mostly dead, too.

I know that there was once a project which approach is completely
different.  The idea seemed that supporting OpenPGPcard on top of
PKCS#11 API.  However, for me, this approach is questionable, because
feature set of OpenPGPcard is a way simpler than the one of PKCS#11.


Perhaps, the name, "scdaemon", would be misleading, it sounds like it
supports (many) smartcard.  In fact, for OpenPGP, it only supports
smartcard/token which implements OpenPGPcard specification.  That is,
the original OpenPGPcard, Gnuk Token, and Yubikey, etc.
--