GNU Open Standard Directory Services

Summary

This document is a discussion of the problem of centralising user email, location and credentials information, along with some possible open source based solutions.

Introduction

The problem

Every operating system that has a concept of different users, has a database of users and associated characteristics. Out of the box, most of them hold this "Accounts Database" in its own local filesystem. There are of course as many different file formats and database structures as there are OSs. So if you just drop boxes on desks and let the users get on with it, you will have a bit of a mess, to say the least. When Alice's machine packs up and she tries to use Bob's box instead, depending what OS(s) they are using she will at least be frustrated and is quite likely to spend the rest of the day getting nowhere.

Then some sadistic person went and invented email. Another database of people, this time in the form of an address book. Now the problem is potentially even more complicated. Each different mail client will probbaly have its own address book file format and database layout and there are a choice of different mail clients for every OS. When Charlie joins the happy band, both Alice and Bob have to separately add him to their email address book. Lets say for the sake of argument that it takes 30 seconds for each person to add an entry to their address book. We now have 3 people and 3 address books. This works out as (3^2 x 30) seconds, or 6 minutes. Neither here nor there you might rightly argue. However, you should note that the time goes up as a power of two. It is exponential. Now do the maths for a 100 person company. This works out over time as a half a man month of combined messing about. So while there is a small number of people in the company, the problem is annoying but limited.Where we are talking about a larger organisation this is a real drag. It will slow people down. This is to say that they will take longer to do things. Which can be paraphrased as It Is Costing You Money.

Lets add another ingredient to the mix, signing and maybe encrypting emails and other documents. If Bob wants to buy something from The Acme Corporation, he will have to place an order. Traditionally this is done on paper, with maybe the facility of faxing the paperwork over. The order is a legal document. It is commiting Bob to pay for the goods on receipt of another legal document; the invoice. In normal circumstances it wouldn't matter how this was actually done as the goods will arrive in good order and the payment will progress in the opposite direction. The problems start when something goes wrong with this. In the worst case the documents will have to be taken to a court of law to prove that the uncompleted part of the transaction should have happened. The documents therefore have to be in a form that the court will accept. For so long this has meant they have to be pieces of paper, but there is legislation workingits way through that will mean electronic documents can be accepable to UK courts. They will however have to be electronically signed. In short this means that the sender and maybe the recipient in the case of encrypted messages, will have to obtain a cryptographic certificate. This is a file that only the owner can unlock, which when used properly proves that the document came from them and has not been altered en-route. if Bob wants to send some sensetive information to Acme, he will need his own certificate and also a certificate for Diane, the person in Acme he is sendingit to. Diane in turn will need certificates and email addresses for the folks shedeals with in Bob's company.

This blows the problem wide open.

Our 3 colleagues now need a reliable list of email addresses and certificates for a different company entirely. Do they only deal with the one supplier, of course not. Lets take another look at the power of two effect in the light of this new factor. Even with out 3 head company the problem is free to become quite fearsome.

Solutions ?

There are a number of solutions to parts of the problem. There are even a number of part solutions to the whole problem. However the systems that claim at least to be a whole solution to the whole problem are limited in number. Unfortunately they are not quite so limited in terms of cost. One finds oneself wondering how expensive the problem really is and therefore whether these solutions are going to be worth the money.

This article is a discussion of how to sort out the Contacts and Credentials Directory problem using free software.

GPL

The vast majority of software is covered by an End User License (EUL). Most software that is used commercially has the sort of license that prevents the user buying one copy and then using it across multiple machines when they should have bought several licenses. It also prevents them from selling the software on.

The General Public License (GPL) however, is a rather bizarre document that does exactly the opposite of this. It is used to prevent the supplier from making this restriction. It doesn't mean that you don't have to pay the supplier for the softare, but it does mandate that you get the source code with the product and that you are in turn required to do the same for anyone to whom you supply the software. The right to pass the software on is also enshrined in the GPL If you add code of your own to the product, you are required to include this new code if you pass the product on.

Theoretical System Layout

The directory is accessable to everyone who needs and has the right to access it. All of the machines are connected to it and when someone tries to log into a machine, the machine checks with this database to find out if that person should be allowed to log on. The same record that contained Alice, Bob and Charlie's login name and password also contains their email addresses and certificates. They can each connect to their accounts and update certain details as and when they change. For example, Alice gets married and changes her surname. This only has to be changed once and everyone else who should know about it, then does. The certificates are *partially* accessable to all of the players, but can only be used to sign and decrypt messages by their owner. if Bob wants to send an encrypted message to Alice though, he will need to be able to get at part of Alice's certificate, the so called "Public" part. She needs the "Private" part of her certificate to be able to sign her outgoing messages and decrypt encrypted messages intended for her.

The System Components

We need a database. There are loads of these of course and plenty of them are published under the GPL. However we need a specific kind of database; in essence one that can actually be a directory and that has a reading and writing protocol that mail clients can talk. This document will restrict itself to the protocol LDAP and a piece of software called OpenLDAP.

We need email clients. Given that we are considering the problem of integrating disparate systems into one co-operating whole, we cannot restrict ourselves to GPL based products. They do however need to be able use the standard client/server languages spoken by the other parts of the system. The languages are called protocols and are usually refered to by the use of rather awkward acronyms. LDAP for example stands for Lightweight Directory Access Protocol. This, if no other, is a pre-requisite, as we have chosen OpenLDAP as the core database.

We need a common cryptography standard as well. We shall look at two. The most famous of the two is PGP. This is a robust and powerful standard that has been implemented as GPL code in the product GNU Privacy Guard (GPG). It has also been implemented as a closed source, chargeable product that plugs into certain email clients. It is however, unlikely to form the basis of signed documents that the courts will accept. I hope that I will be proved wrong on this one, but the action is currently centred around another set of standards. In lieu of a better name, I will refer to this second style of crypto as X.509. This is a much more complex system and one that deliberately restricts the uses that its certificates can be used for. However it has many more uses than signing and encrypting static documents like emails and purchase orders. it can also be used to sign blocks of software that are downloaded into existing products to extend their functionality. it can be used to secure the endpoints of Virtual Private Network (VPN) connections. It can also be used to validate users in the event of them wanting to log into their machines.

While the database could conceivably hold both kinds of certificate for every user, it would be better to reduce the management overhead by only using one of them. This unfortunately tends to exclude PGP from the game.

X.509

A full discussion of this set of standards would take a great deal of time and almost certainly render the reader comatose. There are however a few of the characteristics that should be illustrated.

In common with PGP it is based on a mix of the basic cryptographic components. Probably the most important crypto building block for this application is public/private key cryptography. In this, every user has one or more Private Keys, each of which has a corresponding Public Key. The public key is made public and the private key is (yes, you're way ahead of me) kept private. In order for you to encrypt something in such a way as to be secure against everyone other than the recipient, you need their public key. You use this key to encrypt the document. They then decrypt it with the corresponding private key. They will sign things using their private key, which you can check using their public key. In both cases it is critical that the owner is the only person able to use their private key.

The public and private "Key Pairs" form the core of the certificate. The certificate is analagous to your passport. It proves that you are who you say you are. Lets just take a moment to consider why it is that your passport is such a powerful document. I could go out and get some card, some paper and a dodgy photo-booth photo, but I would not be able to create my own passport. it has to be verified and in this case manufactured by someone else. That someone else needs to be trusted by the person I am showing my passport to, otherwise it is worthless. The same goes for the certificate.

This set of standards does this by the use of a cascade of private keys based on a key owned and published by a body called a Certifying Authority or CA. This is a company or other organisation that has set itself up as a "Trusted Third Party". A person or indeed a company will trot along to the CA and bring with them a selection of documents that they will hand over to the CA to prove that they are who they say they are. When the CA is satisfied, they will take the applicants certificate and cryptographically sign it with their own special key. Now this certificate can be used to prove to anyone who trusts the CA that they really are who they say they are without recourse to anything other than that signed certificate.

For example, when you connect to a company's website using a secure connection you have ensured that nobody outside the link can readthe data on the way past, but that's only part of the problem. You also need to be sure that the website is the one you were intending to connect to. You may well be about to hand over your credit card number! The saving grace is that part of their certificate is the website address. Nobody else can get a certificate with this in, the CA would never sign it. So you check their certificate for the address and if it is there, you at least know that you haven't been diverted to another site without your knowledge.

Another characteristic is that once your company has gone through the CA hoop, they can get a special certificate of their own. They can then sign their employee's keys. When the recipient wants to check the certificate, the trail leads from the sender's certificate to the company certificate back the the CA.

A break from this rather autocratic sounding approach is a subtle variant championed by Thawte of South Africa. They operate a normal Public Key Infrastructure (PKI) system where you pay them some money and they take the time to check your paperwork and sign your key. However they have also set up a system modelled and named after the PGP "Web of Trust". Their MD is the core member with the power to sign other people's keys, but he does so in such a way as to allow those people to sign more keys. It is done on a points system. Anyone can get a certificate with just their email address in it. They prove to themselves that you have a right to use that email address by simply sending you a passcode via email. If you can bring that code back to them via their web site then you are the owner of that email address. This is the first step. The next thing is to get your actual name into the certificate. For this you need to get hold of 50 points. You need to find another Thawte certificate holder that has been licensed by Thawte to sign keys. They can check your documents and sign you up to the tune of between 10 and 35 points. You need 50 points to get your name in the certificate. Once you get up to 100 points, you can then sign other people's keys for yourself.

OpenSSL

This is a GPL project that implements all of the core functionality needed for X.509 style cryptosystems. It is written in such a way as to allow other systems to pull in bits of openssl, rather than having to implement their own code. It is a very solid system, but does not provide much in the way of a user interface. It leaves that to the applications that use it.

OpenLDAP

Another GPL project. This, as was mentioned above, is a database that can hold user data and responds to queries send using the Lightweight Directory Access Protocol (LDAP). The database is fast and sturdy. It has a minimal impact on the host computer. It does not however provide a GUI for editing it's content. Much as OpenSSL it leaves this to the client applications that will be using it. It could however use a GUI to edit the database structure.

Putting it all together

The first thing to show here is the state of interoperation of various email and web clients with the relevant crypto standards and with LDAP databses. Please follow the numbered notes for a more complete description of the state of play for that table element.

Functionality
 LDAP Read
 LDAP Edit
 LDAP Storage of Crypto Keys
 PGP Send
 PGP Validate
 X.509 Send
 X.509 Validate
 Interoperability Status
Necessity
 Mandatory
 Mandatory
 Optional
 Optional
 Optional
 Mandatory
 Mandatory
Netscape 4.79 (Linux)
 Full
 None
 None
 None
 None
 Full
 Full
 Needs LDAP Edit
Evolution 1.2.1 (Linux)
 Full
 Partial
 None
 Full
 Full
 In Dev (1)
 In Dev (1)
 Needs LDAP Edit and X.509
Mulberry (Linux)
 Unknown
 Unknown
 Unknown
 Full
 Full
 Unknown
 Unknown
 Unknown
MS Outlook 5 (Win32)
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
MS Outlook Express 5 (Win32)
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
Agent (Win32)
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown
 Unknown

Note 1 - Evolution vs X.509

It has been reported (Simon) that the source code for Evolution contains the start of a hookup to a suitable crypto library to enable X.509 style cryptography. It is also rumoured that the project will goon to integrate their address book and certificate handling systems.

System Component Information

NB Only GNU or similarly free projects will be listed in this table.

Project Name
 Comment
 Project URL
OpenLDAP
 LDAP database server
 http://www.openldap.org/
OpenSSL
 Multirole crypto library
 http://www.openssl.org/
Evolution
 Email/Address/Diary Application
 http://www.ximian.org/
Mozilla
 Email/Address App;lication
 http://www.mozilla.org/









Author: Andrew Meredith <andrew@anvil.org>
Date: 16th Jan 2003
Copyright: The Anvil Organisation Ltd 2003

This document is released under the GNU Free Documentation License.

The author wishes the thanks the following people for their invaluable assistance in the compilation of this document.