Proposed F19 Feature: Shared System Certificates
jreznik at redhat.com
Wed Jan 23 15:05:39 UTC 2013
= Features/SharedSystemCertificates =
Feature owner(s): Kai Engert <kaie at redhat.com>, Stef Walter <stefw at redhat.com>
Make NSS, GnuTLS, OpenSSL and Java share a default source for retrieving
system certificate anchors and black list information. This is an initial
but useful step in the direction of a comprehensive solution.
== Detailed description ==
The goal is to have a systemwide trust store of static data, that is used by
crypto toolkits as input for certificate trust decisions.
By default, the trust store will continue to contain the trust list as
published by the Mozilla CA Certificate list (but use of others are possible),
including positive and negative trust (blacklists). The system will allow
updating of the core Mozilla CA list. The trust list can be adjusted, added
to and overridden by administrators.
There will be a global directory that is scanned for input files, which will
include the RPM-package-owned Mozilla trust bundle, and which may contain
any number of additional files.
In order to achieve this, the following implementation would be used.
Much of the upstream implementation of this is p11-kit and can be shared with
This initial implementation is a step towards a later more comprehensive
representation of locally stored trust policy information. The upstream
p11-kit project has more information on the long term concept.
p11-kit will provide a PKCS#11 trust module which provides trust information
based on a directory of certificates, some of which may have trust information
The PEM trusted certificate file format is supported here, as are others.
p11-kit will provide a tool to extract information from the PKCS#11 trust
module in the following formats:
Extract to a CA PEM bundle with TRUSTED CERTIFICATE information for OpenSSL.
Extract to a dirhash style directory for OpenSSL.
Extract to a CA bundle with plain certificates, for serverAuth,
Extract to the Java cacerts file.
This tool uses the PKCS#11 module as its source of trust information,
allowing future work to build off of this effort.
This tool is an interim bridge between OpenSSL, GnuTLS and Java until
they are able to read PKCS#11 trust information directly.
NSS: Uses the above PKCS#11 trust module directly to pull in trust information.
The PKCS#11 trust module is a drop in replacement for libnssckbi.so.
We can use update-alternatives to manage this drop in replacement.
NSS using applications would not need to be changed to work with this
OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the
PKCS#11 trust module.
These extracted certificates will be placed in a location so that they
can be consumed by OpenSSL by default.
The aim is that neither OpenSSL nor OpenSSL applications will have to
be changed for this to work.
In the long term future we hope that we can build a bridge so that
OpenSSL can consume trust information directly from the PKCS#11 trust module.
GnuTLS: The p11-kit tool tool will extract a CA bundle to be used by GnuTLS
from the PKCS#11 trust module.
This CA bundle would be placed in the location where most GnuTLS
applications today are configured to use it.
It would pull out all the certificates that are trusted for serverAuth
since GnuTLS does not yet provide a way to consume detailed usage directly.
Black listed certificates would obviously not be included in this bundle.
We are working with GnuTLS can consume trust information from the PKCS#11
trust module in the future.
Java: The p11-kit tool will extract a Java compatible cacerts file from the
PKCS#11 trust module.
Again it is our aim that this changes later, once we can provide a bridge
for java to load trust information from PKCS#11.
The recurring theme is that the PKCS#11 trust module is the source of trust policy
information. Over time, (but not in this Fedora release) there will be:
Work done to both make the trust module have a comprehensive model of stored
Steps taken to make it possible to use GnuTLS, OpenSSL and Java directly with
that stored trust policy.
Obviously applications can continue to use their own CA list as appropriate,
for example in servers such as httpd or postfix.
For more information:
More information about the devel-announce