Friday, October 22, 2010

Looking for open source work

Well, all good things must come to an end. My job at The Family International is changing significantly, and I'm looking for other work. It's been a great organization to work for, I've been able to work on real interesting and varied projects, and at the same time working to support a really worthy cause.

They've been supportive of my open source work, and have allowed me to release several internal projects as open source. I managed singlehandedly to get them on the short list of top organizations that contributed to GNOME.

But I'm excited about this change. I've applied for positions at a number of open source companies. I think it'd be awesome working further with the great folks in the open source community. I've had over 10 years of extensive experience to bring to the table.

My wife, son and I are likely going to move to Germany.

Tuesday, October 19, 2010

This aren't the benchmarks you're looking for

I was evaluating use of GObject for small plentiful short-lived objects in libgck. I wanted to see how their performance compared to custom reference counted structures. Turns out it's not as bad as I imagined.

The speed difference on my system, with a simple test program, ended up being around a factor of eight. Most of that cost is due to pthread_mutex_lock and pthread_mutex_unlock.
$ ./test-gobject-speed 
struct x 10000000 = 1.091700
object x 10000000 = 8.578848
Note that I didn't use heavy weight stuff like properties or signals in my benchmark. But I don't need those for this use case.

Sunday, October 17, 2010

Goals of the Keyring and Seahorse Projects

In an effort to get better organized, I've put together a page listing the goals of the gnome-keyring and seahorse projects. It's all broken down into tasks, plans, and what's already done.

The basic jist of it is to make crypto and security a usable experience on the desktop. This means laying down a foundation for integrating crypto into applications easily. We have tons of technically excellent crypto libraries and security components, but there hasn't been the glue to tie them together and make them usable in apps.

It's sort of like what PackageKit or NetworkManager did for their respective areas. Linux (and other open source OS's are) really great at networking, but NetworkManager pulled together all the various bits, and completed missing parts to make it to be usable.

Wednesday, October 13, 2010

About Trust Assertions

I've been working on some specifications for storage of 'trust'. This a sufficiently vague and abstract concept to require a hoity toity name: Trust Assertions

Trust assertions are used to assign an explicit level of trust to a public key or certificate. I'll just refer to certificates below because that's the easiest to grasp, but the concept is sufficiently abstract to allow trust assertions for other types of keys.

Examples of trust assertions include:
  • Certificate Authority root certificates
  • Certificate Revocation Lists
  • Certificates you decide to trust manually (for your favorite self signed certificate)
  • Certificates marked bad explicitly
Trust assertions are not about the process of deciding whether you'll eventually trust a certificate. Ultimately an application needs to determine trust a certificate for a given connection, email or instant message. It does this by checking if it's valid, who it's signed by, and an obscene amount of other rules. It usually does this with the help of a crypto library.

Only the application has all the information necessary to make a trust decision. A simple example of this is how web browsers check that the common name (ie: CN) of the certificate matches the domain name of the https:// website you've browsed to.

Trust assertions are about storing basic facts that applications use in their trust decision process.
The Concept 
A trust assertion describes a level of trust in a certificate for a given usage or purpose.  Conceptually each trust assertion is a triple containing:
  • Certificate Reference
  • Usage (aka purpose)
  • Level of Trust
We examine each of these parts of the triple in further detail below.

The Level of Trust

A trust assertion ultimately denotes a level of trust. These are:
  • Untrusted: The certificate is explicitly untrusted.
  • Unknown: The trust is not known and should be determined elsewhere.
  • Trusted: The certificate itself is explicitly trusted.
  • Trusted Delegator: The certificate is trusted as a certificate authority trust root.  Trust is conferred to certificates that this certificate has signed, or that signed certificates have signed, and so on.
The Usage

A trust assertion always refers to a specific purpose or usage.  A certificate may be trusted for purposes like: email, code signing, authenticating a server.

It turns out that carte blanche trust not a super useful concept. You (should) always trust someone for some purpose. You trust your bank with your money, not your children; you trust your school with your children, and so on.

The Certificate Reference

And finally we have the certificate that the trust assertion refers to.

Pretty boring stuff actually. But it does get exciting. By comoditizing trust storage, we can use these well defined concepts for new methods of trust decision making.

The way certificate authorities work in your web browser scares a lot of people. By changing to a more general trust storage model, we have the possibilities for applications to try out new trust paradigms. One example is the have-I-seen-this-key-at-this-site-before trust model, used by OpenSSH. But I'm certain that more methods will emerge as more energy is brought to bear on the problem.

Okay enough hand waving, and back to earth.

The specification I'm working on defines how to store trust assertions as PKCS#11 objects. This isn't a new concept, and has been implemented in Mozilla's NSS for a long time. However as far as I can tell it hasn't yet been documented.

After some prodding (thanks Nikos) I figured I'd do some work to document it properly.

GNOME Keyring is completing its implementation of trust assertions. For a long time now, we've had simple read-only trust assertions that exposed everything in /etc/ssl/certs as a trusted delegator (ie: a certificate authority).

But now we're working on rounding out the support on the trust-store branch of gnome-keyring.

Cosimo is working on XTLS to encrypt jabber chats in empathy, and so the trust-store work will help store certificate exceptions in gnome-keyring.

Friday, October 8, 2010

Certificate and Key Widgets

The new certificate and key view widgets are now merged into gnome-keyring master. They live in libgcr: a library for crypto UI widgets and crypto helpers.

The goal of the widgets are to have a simple mode, where only the information needed for a user to uniquely identify a certificate is displayed. The widget can be expanded to show all the details about the certificate.

Simple mode, with a dialog border.

Details expanded.

At GUADEC Matthew Paul Thomas helped us design a nice certificate selector, and I'm working on implementing that.

Monday, October 4, 2010

Introducing libgck: A PKCS#11 GObject wrapper

In gnome-keyring we use PKCS#11 for the storage of keys and certificates. PKCS#11 is standard sort of a plugin API that allows drivers or software to provide key storage and crypto algorithms to an application.
libgck is a GObject wrapper of PKCS#11. Still pretty low level but makes PKCS#11 easier to use from GNOME or GTK+ apps. libgck is used extensively in gnome-keyring and seahorse.
  • GCK stands for "Gobject CryptoKi".
  • Currently lives in the gnome-keyring git module, but could be split into its own module in the future.
  • Replaces libgp11 with many lessons learned and a cleaner API.
Besides the mundane expected key and certificate storage functionality and crypto mechanisms. There's support for stuff like PKCS#11 URIs used to identify keys or certificates residing in a certain key storage or smart card. Also enumeration and loading of modules from a common system location.
All this goodness is in gnome-keyring master or 2.91.0