After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 537239 - Use PKCS#11 (smartcard) API for handling certificates and private keys
Use PKCS#11 (smartcard) API for handling certificates and private keys
Status: RESOLVED DUPLICATE of bug 719982
Product: NetworkManager
Classification: Platform
Component: nm-applet
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on: 537237
Reported: 2008-06-08 11:49 UTC by David Smith
Modified: 2014-07-23 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---

Add PKCS#11 manager class and modify EAP-TLS to use it. (41.55 KB, patch)
2008-07-27 06:46 UTC, David Smith
none Details | Review

Description David Smith 2008-06-08 11:49:21 UTC
This bug is related to bug #537237, only this bug is specifically for how to do the UI parts. Please see #537237 for the rationale.

nm-applet should allow using PKCS#11 API for certificates, CA certs, and private keys. Unlike libnm which just has to manage the settings and pass it on to the appropriate programs, nm-applet will have to actually (dynamically) link with a PKCS#11 API implementation of the user's choosing in order to allow the user to select the credentials she wishes to use.

Ideally, nm-applet would by default use gnome-keyring's PKCS#11 implementation for storing credentials and pass that along via libnm to wpasupplicant for EAP-TLS configuration instead of sending certificate and keyring binary blobs. To simplify the UI, gnome-keyring could be enhanced to proxy PKCS#11 API requests to alternative backends such as OpenSC or openCryptoki and nm-applet's configuration would retain simplicity, similar to OSX's network management configuration utility.
Comment 1 David Smith 2008-07-23 16:38:03 UTC
I've begun work on a patch to implement this, making nm-applet use the pkcs11-helper library from and defaulting to using keyring's PKCS#11 implementation. The work is moving quickly, and I will have a patch soon.

One problem that has come up is that keyring's PKCS#11 implementation connects to the keyring daemon by a socket found by examining the GNOME_KEYRING_SOCKET environment variable. But, wpasupplicant running under DBus service activation doesn't provide a way to set that environment variable so it won't be able to connect to the user's keyring. I propose fixing this by adding a DBus API call to wpasupplicant to set environment variables in its process (and similar would have to be done for other system daemons that were to be controlled by network manager, i.e. strongswan/openswan for IPSec VPN plugin). Are there significant downsides to that approach I'm overlooking, particularly with regards to security?
Comment 2 David Smith 2008-07-27 06:46:11 UTC
Created attachment 115361 [details] [review]
Add PKCS#11 manager class and modify EAP-TLS to use it.

Attaching an initial patch, not ready for production, that makes the EAP-TLS method use PKCS#11 instead of files. It works for connections with opencryptoki's software backend, but only supports selection of objects from other backends like gnome-keyring because of issues with getting wpasupplicant to connect to the keyring session, discussed elsewhere. The PKCS#11 implementation interface is provided by libp11 and autoconf has been updated to check for it.

Please take a look.
Comment 3 Dan Williams 2014-07-23 15:44:16 UTC

*** This bug has been marked as a duplicate of bug 719982 ***