SharedCertStore

From openSUSE

Current Situation

• Multiple crypto stacks: OpenSSL, GnuTLS, NSS.
• No unified way to manage certificates; each application does its own thing.
• This chaotic situation forces users to keep certificates around in transport files, which are compromised more easily through negligence.

Goals

• Keep certificates in more secure database.
• Share certificate database between applications.
• Ease the import/management of certificates.
• Avoid duplication of user certificates.

Means

The most effective approach seems to be to focus on a single crypto stack.

• GnuTLS has an attractive license (LGPL), but it's not FIPS certified and seems to have some technical problems as well.
• OpenSSL is not a bad choice at first glance; it has a certificate database and it's widely used, but there are problems with its FIPS validation; each application that relies on it needs to be FIPS validated itself.
• NSS, a cornerstone of the Mozilla project, implements the required security standards and is four times FIPS certified. NSS is already employed by several major Free Software/Open Source projects, including Firefox, Thunderbird, Evolution, OpenOffice.org and (in some configurations) Apache. Applications relying on NSS are automatically FIPS certified if they follow a set of rules (detailed PDF).

NSS seems to make the most sense, particularly in light of FIPS validation and existing client applications. Another important influence is Fedora moving towards standardizing on NSS. Note that we'll need NSS version 3.12, which first shipped in openSUSE 11.0, to achieve shared certificate database capability.

Enabling Applications

We've identified a list of applications/areas where consolidated cryptography/certificate handling is of high priority to users. These are, roughly in order of priority (most important first):

• Network access
  • Wi-Fi Protected Access (WPA)
  • 802.1x wired authetication
  • Virtual Private Networks
• Mozilla Suite
  • Firefox
    • Web Browsing
  • Thunderbird
    • Server Authentication
    • Mail encryption/signing
• OpenOffice.org
  • Document signing (http://www.linux.com/feature/57554)
• Evolution
  • Server Authentication
  • Mail encryption/signing

Additionally, we may want to look into the following:

• GVFS-enabled applications
• Nautilus
• WebDAV for T+C
• All other crypto consumers
  • SSH
  • wget

Network access

NetworkManager stores WPA and VPN secrets using gnome-keyring. Cryptoki (PKCS#11) support for gnome-keyring has recently been invested in upstream - if it gets support for an NSS backend, we might be able to use that directly.

Issues include: FIPS compliance might not propagate up to gnome-keyring, and thus not to NetworkManager. However, if we can ensure that gnome-keyring, in using NSS, follows the “simple rules” needed to inherit FIPS compliance, we might be ok.

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 created by the openSUSE mozilla-nss RPM since 11.1. [FIXME: Tambet likely has a lot more to say about NetworkManager].

Mozilla Suite

Already using NSS, obviously. We need to make it use the shared per-user certificate DB. Upstream NSS proposal for the location of the per-user DB is ~/.pki/nssdb.

OpenOffice.org

Already using NSS for document signing. Might just be a matter of making it use the shared per-user certificate DB.

Evolution

Already using NSS. We need to make it use the shared per-user certificate DB. [AI: Discuss with Srini]

GVFS-enabled applications

GVFS uses libsoup for HTTP, DAV, FTP, which uses GnuTLS for SSL/TLS. The GnuTLS integration code lives in a single file of some 600 LOC and looks like it should be easy enough to replace with the NSS equivalent (estimate 2-3 working days for an experienced C/GLib programmer).

However: GVFS does not handle any of the SSL/TLS-specific callbacks from libsoup, which implies that it has no support for certificates at all (there's a bug that might be relevant). [AI: Find out what GVFS maintainers plan to do about this]. We'd have to implement this at the GVFS level. The complexity of this is unknown, but likely to be medium-high (certificate information must be propagated to application, which may prompt user to make a decision; decision must be passed back; applications would ideally share UI elements for this).

Users report HTTPS and DAVS working with the older gnome-vfs; how was this done? I don't think it had a certificate UI. [AI: Find out how much work a minimum-effort implementation with no certificate UI is, perhaps based on what gnome-vfs did].

Additionally: libsoup's certificate primitives may be too limited – it only supports X509-encoded certificate files – so we may have to change its API significantly to accommodate NSS functionality.

All other crypto consumers

This encompasses command-line utilities, mainly. Most of these use openssl. Fedora wrote a wrapper library – called nss_compat_ossl – which aids porting these by providing an openssl-like API that maps to NSS calls. A bit of manual porting is still involved, particularly where struct fields are accessed directly and where other non-mappable functionality is used. Fedora has an ambitious plan to migrate everything.

The wrapper library is packaged for openSUSE Factory; the package is called “nss-compat-openssl”.

It's unlikely that we'll get around to porting any of these applications for openSUSE 11.1, but with the packaged wrapper library, at least we'll be able to do so more easily in the future (e.g. in SLE service packs).

Certificate Management

Today, NSS comes with command line tools to manage certificate databases and import/export certificates. Firefox also includes a GUI certificate management tool, reachably thusly: Edit → Preferences → Advanced → Encryption → View Certificates. This tool is pretty buried in the Firefox GUI, though – maybe we can find a way to make it run stand-alone, or clone it using GTK+ (estimate 5-8 work days for an experienced GNOME programmer). [Can we steal the one in the Evolution preferences dialog? Should we just extend seahorse?] [The mozilla repo contains a XUL app called nss-manager which is a PoC based on xulrunner]

NetworkManager may need a host-wide database in addition to the per-user ones (see Network access). If we need to interact with a host-wide database, a standalone certificate management GUI is required – it will have to run as root at some point, or spawn a helper running as root, which is not something we can do with all of Firefox.

The appearances for this work will be important. Having a solid UI that can be used to managed certificates would be good. The Evolution tab could be a good start.

[AI: We should clearly document our plan for supporting both a system-wide and an user-specific certificate store.]