Created attachment 111955 [details] [review]
Preliminary patch

I had some free time so I hacked something, what I think might implement this feature. However I'm not really sure about configuration dialogs and I'm unfortunately unable to test this code right now. So it will most likely not work :-).

*** Bug 372037 has been marked as a duplicate of this bug. ***

It'd be interesting to expose certificates through the GNOME keyring. Evolution, for example, would benefit from being able to see certs for mail encryption and for client certificate authentication during SSL/TLS auth on POP3, SMTP and IMAP connections.

See bug 585214.

Note that gnome-keyring ALREADY supports certificate management, though there's no UI for it in Seahorse yet and only an incredibly basic import tool "gnome-keyring import".

NetworkManager should use gnome-keyring for key management. That'll permit proper support of smart cards ( remember, not all keys are PKCS#12 files ) and centralized key management.

Linux does need a centralized certificate store.  However, that's not just gnome-keyring.  We need a *system* key store too, for when the UI isn't necessarily up yet.  That needs to be a unified key store, and that's not something that gnome-keyring can currently provide.  The leading candidate (on the backend) is NSS at this time; but more thought needs to go into the whole architecture here.

gnome-keyring's support basically consists of a PKCS#11 provider that makes the keyring look like a smartcard reader to NSS.  That's fine, but that only works with the *user's* NSS database and the UI isn't quite ready yet.  We'd want a standalone widget that apps could embed to talk to the certificate store (either seahorse or NM for example) and select certificates, which the applet would use.

So basically, yeah, a cert store would be awesome, but more work is needed to figure out the *whole* architecture, not just the gnome-keyring architecture.  GK might be part of the larger system, but it's only one component and certainly not something we can just pick up and use today.

One other problem is that the supplicant and vpn daemons (which run as root) need access to the keys, and that *shouldn't* happen by a root process poking around with the user's files.  The call chains here need to be clear and not cross security boundaries.  For example, if you need the certificate to log into the network, but of course your home directory is on the network, gnome-keyring certainly isn't going to help you because it stores the certs in your homedir.

Thanks for the excellent explanation; it's much appreciated.

A centralized certificate store based on NSS has one significant issue: NSS isn't really designed for concurrent access by multiple clients. In fact, while looking for references on that I ran into this post:

  http://www.opensubscriber.com/message/dev-tech-crypto@lists.mozilla.org/4872152.html

re certificate management in GNOME.

Consequently, the central certificate store would probably have to look a lot like gnome-keyring's current PKCS#11 provider, where each app's private NSS instance talks to it, but each app has its own private NSS store.

The PKCS#11 code in gnome-keyring might in fact be a useful starting point for a system keyring manager. It'd handily allow apps to add the system keyring as just another NSS provider, along with gnome-keyring and whatever else they want.

NSS is working on a shared keystore with multi-application access to help with this:

https://wiki.mozilla.org/NSS:Roadmap#SQLite-Based_Multiaccess_Certificate_and_Key_Databases

See also Fedora's crypto consolidation efforts:

http://fedoraproject.org/wiki/FedoraCryptoConsolidation

There's also a related page for SuSE, also recommending NSS as the library of choice.

http://en.opensuse.org/SharedCertStore

In particular, note in the OpenSUSE article:

"NetworkManager may require a host-wide certificate database in addition to the per-user ones. NSS specifies a standard location for this: /etc/pki/nssdb/ This directory is not created by the openSUSE mozilla-nss RPM; it probably should be. [AI: Discuss with Wolfgang Rosenauer and Michael Wolf] [FIXME: Tambet likely has a lot more to say about NetworkManager]. "

NSS looks a _LOT_ like it already tackles these problems, especially with the newer shared database support.

I am working on this , and will submit a patch soon.

Created attachment 152555 [details] [review]
enable pkcs12 certs for nm-openvpn

Created attachment 152556 [details]
sample config file

Attached patch enables this functionality, it uses the current nm-openvpn strategy of just storing the path of the cert in gconf and not actually escrowing the cert in keyring or nss

Any news on this yet?

9d68010833e797aec027600fbef37696223cccdb (master)
ee070bad5028c34ef794ecfbb9a9d2115184916e (0.7.x part 2)
3fdf0a608c55aff58717153ed1c06d2dbf02c07e (0.7.x part 1)