exclusive vs. shared smart card access
Бранко Мајић
branko at majic.rs
Wed Sep 16 22:24:24 CEST 2015
Дана Wed, 02 Sep 2015 13:23:51 +0200
Werner Koch <wk at gnupg.org> написа:
> On Tue, 1 Sep 2015 08:46, andreas.schwier.ml at cardcontact.de said:
> > It's OK to claim exclusive access to a smart card during a session,
> > but the software must release access if it's no longer needed.
>
> GnuPG requires the card all the time.
Sorry for chiming in on this one so late, but had to work my way
through the mail backlog (and this topic is of interest to me, so
can't let it pass by).
At work I work with X.509 CAs, OCSPs etc. In many cases I need to be
able to use smart-cards through the PKCS#11 for accessing the
installation for administrative purposes etc (mostly for testing
deployments for customers).
In parallel I also use the OpenPGP card for private purposes.
However, if I have used the OpenPGP card at least once (and therefore
the scdaemon is all up and running), I will not be able to use the
non-OpenPGP card through the PKCS#11 middleware/interface afterwards.
I don't know much about the internals (and sorry if I don't make much
sense here), but can the scdaemon be modified so it does not try to get
exclusive access to non-OpenPGP cards?
Although this would not cover the dual-applet card scenario, it would
at least allow people with non-OpenPGP cards to use them "in
parallel" (well, one after another) without additional effort.
At least I have this issue with GnuPG 2.0.28, perhaps this has already
been fixed/implemented in GnuPG 2.1.x?
Best regards
--
Branko Majic
Jabber: branko at majic.rs
Please use only Free formats when sending attachments to me.
Бранко Мајић
Џабер: branko at majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150916/16faac30/attachment-0001.sig>
More information about the Gnupg-devel
mailing list