Short version: SPKI links not only names, but authorizations to keys. Also, it uses a better syntax (S-expressions) than X.509 certificates.
Long version:
What problem does it solve?
Both the traditional CA-based public-key infrastructure (PKI) and PGP's web of trust (and other similar systems) do mainly one thing: Linking names to public keys.
The idea behind SPKI is detailed in RFC 2692. It explains that, while this might be sufficient in the 1970's, when the relevant communities were small and one usually knew the person identified by a name before starting to use the key for communicating, it is not sufficient anymore for the Internet of the late 1990's (and even less later).
One reason is that names alone are not a globally unique identifier. (While my name seems to be quite unique in the WWW today, there are people which are less fortunate.)
More important, though, is what we are actually using the keys for: To access some resource (or to provide it).
Thus, we actually need certificates like these (examples from the RFC):
- I need a certificate to give me permission to write electronic
checks.
- My bank would need a certificate, proving to others that it is
a bank capable of cashing electronic checks and permitted to
give permission to people to write electronic checks.
E.g. we need a certificate linking authorizations to keys. (I.e. a certificate that says the holder of the private key belonging to the public key X has the right Y - for example, "access this SSH server".)
SPKI does this. RFC 2693 - Theory of SPKI details the theory. The actual specification (i.e. the data formats) seem to have never reached the RFC state (there are some Internet drafts which expired in 1998).
What rights (authorizations) there are possible is left to the application (i.e. whoever actually has control over the resource). Its owner indicates an access control list, i.e. which keys are (with which authorizations) the roots of any certificate graph leading to the ones which actually have access.
Authorizations can be transferred between keys (if the delegate-bit is set on the first key) by issuing a certificate.
Any key holder can issue any certificate to any other key (or even to ones own key), i.e. we have a web of certificates between keys. But whoever evaluates the certificates will decide which certificates are acceptable for which use (depending on which other key holder signed these keys).
The traditional "name-key" linking certificates are still supported, this way the conventional PGP Web of Trust or the X.509 CA hierarchy can be a part of this infrastructure, and their certificates can be transformed into the same internal representation like SPKI certificates.
Syntax
To represent the keys, names and authorizations used in the certificates, SPKI uses S-expressions. (You might know these from Lisp - nested lists written in parenthesis, containing byte strings.) Here is an example of a name:
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
For transmission and signing these are converted into a canonical form (length-prefixed literal strings).
These S-expressions are easier to parse than X.509 certificates.
Certificate revocation
A problem identified in the PKI was that is is not always totally deterministic whether a certificate would is revoked or not, depending on whether the evaluating client got the right CRL or not.
SPKI defines a way that makes this deterministic:
- certificates contain references to CRLs which can revoke them
- certificates contain the key that must be used to sign the CRLs (which must not necessarily be the same key that issued the certificate)
- CRLs must have a validity date span (and these must be non-overlapping)
