While it is "boring stuff" at some level, consolidating the
various desktop cryptography solutions has the potential to
"pleasantly surprise our users and impress them", according to
Stef Walter in his presentation at this year's Desktop Summit in Berlin. His
talk, "Gluing Together Desktop Crypto" outlined his plan to use PKCS#11
as the "plumbing" that will serve as the foundation for
desktop-wide and cross-desktop sharing of keys and certificates. Once the
boring parts are taken care of, "we can do more interesting
things", he said.
The basic problem that Walter is trying to solve is that many of our
applications have their own ideas of where to store keys and certificates,
which leads to duplication and, sometimes, user confusion. If two (or
applications are accessing the same site and service (e.g. https), it would
be much simpler if they were both using the same cryptographic information.
Centralizing the storage of keys and certificates will make it easier for
users to migrate that data to new systems as well.
The current crop of desktop encryption tools is good, and many of the tools are
very stable, he said, but they need to be glued together to make them
more usable. He is involved in both gnome-keyring and Seahorse development and
noted that those applications already do some consolidation. For example,
gnome-keyring stores both ssh and GPG keys, but it needs to be done
"one level lower", he said. There needs to be a single store
for keys and certificates, "so the user doesn't have to care about
where they live". There is lots of diversity on the desktop, which
"should be celebrated" but not pushed out to users, he said.
Fedora is currently porting applications to use Mozilla's Network Security
Services (NSS), which has a
certificate store, but he has an alternate proposal that will still work
with Fedora's solution. He is proposing to use PKCS#11 (p11) as the
standard for keys and certificates, because it has a number of different
useful characteristics including integrating with hardware crypto devices
and smart cards.
There are three steps that need to be taken to hide the complexity of
crypto on the desktop from the user, he said. First you need to be able to
store keys and certificates in such a way that all applications and crypto
libraries can access the same ones. Second is that the framework
needs to make consistent trust decisions. Today it is too often the case
that one desktop application can connect to a particular service or system, but
that others on the same box
cannot—or they each may need to be configured separately. Lastly, there needs to be a way for applications
to refer to keys and certificates in a consistent way, so that they (and
users) can refer to them in standard ways.
Key storage is special, Walter said, so that a simple file or database
cannot be used for that purpose. The idea is that some keys never leave the key
store, instead the store signs those keys and returns that blob for use
elsewhere. According to Walter, p11 makes for a good key store that can be
used to glue together the different libraries that are used in various
The p11 standard has "modules" that are something like drivers for
different kinds of devices or storage facilities. It has a C API that is
"old and baroque", but it does what is needed, he said. It is
"not perfectly awesome, but what it has going for it is that it is
supported in everything". Gnome-keyring and NSS already support it,
while support in GLib, OpenSSL, and others is a work in progress.
When using p11 on the desktop, there are some coordination issues that need
to be resolved for a single application that is using multiple libraries which
all use the same p11 module. That's where p11-kit comes into
play. It will coordinate the access to p11 modules as well as providing a
consistent way for applications to determine which modules are installed
and enabled on the system. It also handles some configuration duties, for
example by telling applications and crypto libraries what key store they
should be using.
Any application that is using p11 can use p11-kit because
it can be used as a p11 proxy module. Due to the module mode, it can be used
in various places without actually integrating it into the code. Walter
specifically mentioned Java and Solaris as two possibilities there. It's
BSD licensed and has no dependencies other than libc.
Trust decisions are another area that Walter would like to see addressed
and he thinks that can be done using p11 as well. A trust decision is a
positive or negative assertion about a particular object (e.g. key or
certificate). It can also associate a level of trust in the object. The
p11-glue freedesktop.org umbrella project,
which is where this work is being done, has a proposed specification
for storing these assertions.
Since the keys and other objects don't leave the key store, there needs to
be a way to consistently refer to them so that they can be reused. There
is an IETF
RFC draft for p11 universal resource identifiers (URIs) that could be
used. Those objects could then be referred to using the pkcs11:
None of the p11 support is "written in stone", Walter said.
It is all still being designed and developed so he invited interested
parties to get involved and help shape it. Once the code is written and
gets into the distributions, users will have a much easier time dealing
with crypto objects for multiple applications and desktops.
Several audience questions further explored the possibilities that this
work would enable, including Mac OS X and Windows support and how to handle
PIN queries for accessing smart cards. One area that is still needing a
lot of attention is certificate revocation lists (CRLs). Revocations are
essentially negative trust assertions that could be stored. Another
possibility is to make a p11 module that exposes a directory of CRLs that
can be used by applications. There is "no actual progress
there", he said, but there are "solid plans". It is a
topic that is under active IETF discussion as well, he said.
Making desktop crypto work reliably, and largely invisibly, across all of
the applications on the free desktop would be an enormous boon for users.
Having Firefox and Chromium (as well as other browsers) share certificates
(and the level of trust the user has in them) would be quite nice, but it
reaches out even further than that. Lots of other applications are
rendering web content these days, so those could share the same information
too. Multiple email clients could hook into the same keys, regardless of
whether they were GPG keys or X.509 keys from some other email encryption
scheme. Switching to a different desktop environment would no longer
necessitate a repopulation of keys and certificates for various
services. And so on. As Walter said, it certainly has the possibility of
surprising and even impressing users who have likely been bitten by some of
these problems in the past.
[ I would like to thank KDE e.V. and the GNOME Foundation for assistance
with my travel to the Desktop Summit. ]
to post comments)