Add option for scdaemon to open smart card in non-exclusive mode

[Uri Blumenthal]

On Sep 13, 2016, at 11:05 , Bernhard Reiter <bernhard at intevation.de <mailto:bernhard at intevation.de>> wrote:
> Am Montag 12 September 2016 03:18:24 schrieb Uri Blumenthal:
>> The problem is that scdaemon insists on grabbing the token, so first - it
>> refuses to access it when another daemon (tokend in this case) is connected
>> to it (tokend on Mac OS X is the daemon that makes the token available to
>> all the native OS X applications, such as Safari, Google Chrome, Apple
>> Mail, MS Outlook, Adobe Acrobat, Keychain Access, etc. etc.). Tokend is
>> talking to PIV applet.
> 
> from your description, I can see that you are having an use case that should
> be supported.

Thank you!

> The next steps would be to
> a) write it down, open up a ticket on bugs.gnupg.org <http://bugs.gnupg.org/>

Will do soon.

> b) come up with a good proposal how to technically solve this

This I’d like to discuss with the GnuPG Dev team.

> c) come up with someone doing or funding the work.

Since I don’t have money to offer, I guess I will do the work - thankfully the expected efforts should be fairly low.

> A workaround in your case could be to use two readers, one for each token.

Sorry, can’t work. For one - there are only two USB ports on my MacBook, and they are already used! Second and more important - this is one and the same physical token. It houses two (actually more, but we’re interested in two) applets - PIV (that’s being handled by OpenSC.tokend and OpenSC) and OpenPGP (accessible via scdaemon, which is the reason of my request and this email exchange). You physically cannot plug one token into two readers.

> I'm no expert, but reading up a bit, it seems that shared access from several
> application could be a problem, either because of the state of the token
> that needs to be handed over and otherwise because of speed issues if
> applications have to reset the token to some clean state.

Theoretically yes. However, my experience of heavy use of the token by multiple applications (Web browser, email client, and intermittent OpenSSL via libp11 via OpenSC) shows that is not a problem in practice.

> So I'm unsure if a "non-exclusive mode" is technically feasible.

It certainly is feasible, as OpenSC proves quite nicely. That’s how PIV tokens work with OpenSC on Mac today: tokend connects to it and interfaces with the native Apple applications, while OpenSSL and Firefox use OpenSC PKCS#11 library to talk to the token directly. OpenSC provides a mechanism to detect if token’s state changed.

Also, please note that I do not suggest eradicating exclusive access. I merely request that the user is given an option to configure scdaemon to connect in non-exclusive mode when the appropriate parameter in the config file is set. The default can well stay as it is now.
--
Uri Blumenthal
uri at mit.edu <mailto:uri at mit.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160914/e49aebb0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20160914/e49aebb0/attachment.sig>