Copyright (C) 1997, 1998 by the Massachusetts Institute of Technology, Cambridge, MA, USA. All Rights Reserved.
Permission to use, copy, modify and distribute this documentation for any purpose and without fee or royalty is hereby granted, provided that you agree to comply with the copyright notice and statements, including the following disclaimer, and that the same appear on ALL copies of the documentation, including modifications that you make for internal use or for distribution:
THIS SOFTWARE IS PROVIDED "AS IS", AND M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. By way of example, but not limitation, M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE LICENSED SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
The name of the Massachusetts Institute of Technology or M.I.T. may NOT be used in advertising or publicity pertaining to distribution of the software. Title to copyright in this software and any associated documentation shall at all times remain with M.I.T., and USER agrees to preserve same.
SDSI/SPKI 2.0 (hereafter just SDSI) is a specification for a simple public key infrastructure (see section References Ellison, et al). It takes public-key cryptography, introduces a format for making simple statements called certificates, and shows how to use them "to make sense of this crazy computer world."
To start with, SDSI is based on public-key cryptography: the idea that everyone has a matched public key and private key for scrambling messages. Your public key can be known far and wide; the private key you hold in secrecy.
For SDSI, the most important feature of public-key cryptography is the ability to sign things. To create a signature on a message, your private key scrambles the message in its own unique way - much like your handwritten signature is always identifiable and unique to you, but is still a little different on each thing you sign.
Once you have made a signature on a message, anyone that knows your public key can verify that signature by unscrambling it and comparing that to the message. Since the public key will only correctly unscramble signatures that were made by its matched private key, a correct signature (and therefore, the message) can be believed to be from you.
If you use the programs PGP or SSH, you are already using public-key cryptography.
Public keys are long numbers, and people have a hard time remembering numbers - even short ones like phone numbers. What we can remember are names. So, we have phone books that we use to look up peoples' numbers. How do we look up peoples' public keys?
This is a real problem. The Internet doesn't have cities and towns, which is how phone books get split up - so would there be one gigantic phone book for the whole world? How do you find your friend Bob Smith when there are so many of them on the planet? Worse yet, the Internet isn't a phone company, it's a global network - who's going to get to write that phone book?
SDSI's answer to this problem is that there is no big phone book. In SDSI, you just keep your own little phone book, filled with the names and public keys of the circle of people you know. Usually, this is all you will need, since these people are the ones you talk to most of the time.
If you ever need the public key of someone that you don't know, what do you do? If there were no phone books, and you needed to know someone's phone number, you'd ask the friends of yours that might know it. SDSI works the same way - if you need to talk to the person named John Smith, and you know that your friend Sam has John's public key in his little phone book, you just ask for the public key for `Sam's John Smith'.
With everyone keeping their own little phone books of the people they know, and telling people who they know when they are asked, you can find just about anyone you need to find, just like a game of "six degrees of separation"(1).
Certificates are a big part of SDSI. Think of them as the entries in your little phone book. When you add someone to this phone book, you write down their name and their public key. Then you sign that entry, so later, someone that sees that entry can know its really one of yours.
Certificates are those entries. Here's an example of a simple certificate:
(cert (issuer (name (hash md5 |PWKULKycrQ/Pxu9qWBSY2Q==|) "Sam Washington")) (subject (hash md5 |Z4a6hysK/0qN0L5SFkcJFQ==|)))
Every certificate has an issuer. That's you. Or, rather, that
(hash md5 |PWKULKycrQ/Pxu9qWBSY2Q==|) is your public key, which
in the SDSI world is you(2).
Say your friend Sam Washington's public key is
|Z4a6hysK/0qN0L5SFkcJFQ==|)). This public key is the subject of
your phone book entry.
So, the way to read this certificate is: you are issuing your
phone book entry for your
Sam Washington, and his public key is
(hash md5 |Z4a6hysK/0qN0L5SFkcJFQ==|)).
Once you have signed this certificate, it's in your phone book. Whenever anybody wants to know what your friend Sam Washington's public key is, if they see this certificate and your signature, they'll have it.
In SDSI, you can make many phone book entries about the same name. While it probably won't make too much sense to have many entries about Sam Washington, since he probably only has one public key, many entries for the different people that are your poker buddies makes sense, since each one has a different public key.
Your poker buddies are a group of people. To make a group of people in your phone book, you make an entry for each one under the group name. For example, if Sam Washington and Frank Adams are already in your phone book, and they're your poker buddies, you could add these two entries to your phone book:
(cert (issuer (name (hash md5 |PWKULKycrQ/Pxu9qWBSY2Q==|) "poker buddies")) (subject (name "Sam Washington"))) (cert (issuer (name (hash md5 |PWKULKycrQ/Pxu9qWBSY2Q==|) "poker buddies")) (subject (name "Frank Adams")))
These certificates look an awful lot like the simple certificates from
before. There isn't much difference. You are issuing two entries about
poker buddies. One of them says that your
Washington is one of your poker buddies, the other says that Frank
Note how the
subjects of these certificates aren't hashes of
public keys. Now, these subjects are
names, ones that are
already in your phone book. Since you already have entries for Sam and
Frank in your phone book that do have hashes of their public keys, you
can just use those names in other certificates you write about them.
So far, we have seen SDSI certificates as entries in your phone book. You can write down public keys next to the names of the people you know, and make groups of those people. Those kinds of certificates are usually called name certificates, since they are used to associate a name with a public key or with another name. With certificates you can also give certain people permission to do some of the things that you are allowed to do.
If you are on a list of people allowed to play a certain online poker
game, you would probably like to allow your poker buddies to play it
too. The list that you are on may be the
(play super-poker at http://best-casino.com) list. To allow your
poker buddies to play the same game, you issue a certificate that lets
them do that:
(cert (issuer (hash md5 |PWKULKycrQ/Pxu9qWBSY2Q==|)) (subject (name "poker buddies")) (tag (play super-poker at http://best-casino.com)))
The tag is the "what you're allowed to do" part. This
certificate allows Sam and Frank to play that online poker game, but
that's it. Any other privileges that you have, they don't get, just the
play super-poker one. Sam and Frank can present this certificate
http://best-casino.com and be let in to play
super-poker, since you are allowed to play the game, and you
allowed them to play it.
These kinds of certificates are called authorization or delegation certificates, since that's what they do.
SDSI uses public-key cryptography so you can digitally sign certificates. Your certificates can be name certificates, which attach names to the public keys of people you know, or delegation certificates, which give others permission to do some of the things that you are allowed to do.
With the ability to have names and give permission, SDSI hopes to bring a real sense of security to the Internet, by having a clear way of saying who can do what on the network.
This software distribution contains a portable library and tools written in C that implement SDSI/SPKI 2.0.
The tools include a command-line shell that you can use to create, sign,
and issue SDSI certificates by hand. There is also a graphical user
interface that lets you use your Web browser to do the same things, but
without having to put together
certs by hand. It also tries to
present the set of certificates you have issued in English, so that they
are easier to understand.
The library is for programmers that want to use SDSI in their own programs. It provides a C language interface that allows programs to easily perform many SDSI operations.
The library and tools were largely written in C, although the real heart of the graphical user interface is a collection of Perl 4 scripts. The entire release should build on just about any Unix-like system out there.
Go to the first, previous, next, last section, table of contents.