SDSI/SPKI

SDSI [47, 112, 152] or Simple Distributed Security Infrastructure (pronounced Sudsy) and SPKI [94] or Simple Public Key Infrastructure (pronounced Spooky) began as two separate standard propos- als. It was quickly realised that they shared many similarities, and the projects were combined in 1999.

SDSI was originally developed by Ron Rivest and Butler Lampson to address the complex and incomplete proposals for a public key infrastructure. Unlike X509, SDSI does not rely on a for- malised global certificate hierarchy. Instead they use a “Local Naming” architecture that leverages the advantages of a PGP-like “web of trust” (described in Section 2.5.2).

Both SDSI and SPKI are key-centric systems, in that, principals are public keys and all actions are performed by these keys. SDSI does not attempt to link identities to keys, however,people can hold these keys and thus manipulate the system.

The SPKI was proposed by the Internet Engineering Task Force (IETF) in 1996 as an alternative to the X.509 version 3 PKIX public key infrastructure (PKI). The IETF SPKI working group was founded just before the publication of the original SDSI proposal [152]. However, SPKI quickly incorporated SDSI names and shares many other similarities with the SDSI proposal. In 1999 the projects were merged and are now referred to as simply SPKI.

S-expressions

S-expressions [153] were developed by Ron Rivest at MIT. S-expressions are lisp-like data struc- tures that are used to represent complex data. They are either byte-strings (octet-strings) or lists of other S-expressions. The data in S-expressions can be represented in many formats, from simple strings to hexadecimal or base64 strings. S-expressions were designed to be a compact, human- readable efficient and transportable mechanism for storing data.

including strings, quoted strings, base64, hexadecimal, and length prefixing “verbatim” encod- ing; these should all be interchangeable. For example, the string “abc” can be represented as

#616263#, that is simply the hexadecimal form of the characters a (61), b (62) and c (63). The # marks surrounding the numbers are used to specify the data between is in hexadecimal form. Ver- batim length prefixing encoding, represents the string with the length of the string prefixed to that string, for example,3:abc.

Lists of s-expressions are also s-expressions. In this case, these lists are made up of s-expressions. An s-expression is surrounded with parentheses, for example(a (b c))represents a s-expression that linksato the second s-expression(b c). S-expressions are used to represent credentials in both SDSI and SPKI. S-expressions can be used to represent a variety of constructs:

• sets of elements;

• ranges of data, such as dates, time or numbers;

• prefixes of strings, used for comparisons, and

• any set constructs representing any s-expression out of a set of possible s-expressions.

These constructs can be used to store arbitrary data.

Local Names

The SDSI project introduced the idea of “local naming”. In SDSI all principals (keys) are equal. Each key has its own name-space, as in PGP (Section 2.5.2). When a principal refers to another principal in their own name space, they define the name themselves: For example if Alice has a computer, then she calls it “Computer”. Bob may also have a computer, and he may too refer to it as “Computer”. As Alice and Bob are separate principals this is perfectly acceptable. However, how does Bob refer to Alice’s Computer? Suppose Bob knows Alice simply as “Alice”. Local naming provides the ability to use names from other namespace. Bob therefore refers to Alice’s Computer as “Alice’s Computer”.

(Alice Computer) (Bob Computer)

(Bob (Alice Computer))

Figure 2.11: Local Names using S-Expressions

If we take these local names and describe them using s-expressions, then we get a naming system such as the one shown in Figure 2.11. Informally we refer to these naming relationships using the “’s” construction (i.e., Bob’s Alice’s Computer). These namespaces can be built up to

2.3 Trust Management Systems 39

describe a hierarchy, for example, consider there is more than one Alice in a company. We could refer to her computer as Company’s Department’s Alice’s Computer. This provides a flexible yet consistent method to name objects.

SPKI

The SPKI [54–56] is a certificate based system like KeyNote and PolicyMaker. A SPKI certificate is a signed statement consisting of five fields. The message without a signature (assertion in Poli- cyMaker), is called a 5-tuple. The five elements are: issuer; subject; delegation; authorisation, and validity dates.

The issuer and subject fields are mandatory, the remaining three are optional. These fields are expressed in the form of s-expressions. There are standard rules for converting s-expressions into binary format and back. These have the same purpose as the ASN.1 [99] notation. S-expressions are used instead of ASN.1 simply because they are lightweight expressions that are more suitable for lower specification hardware. The issuer field holds the key (or a hash value of the key) and a name associated with that key. This name is a SDSI local name.

The subject field also holds a SDSI local name, or a list of local names. The validity dates field contains the validity period of this certificate, in terms of a not-before and/or not-after date fields. The validity field may also include a number of “online test” expressions, that specify the certificate should be verified by checking a certificate revocation list (CRL) or an online validity list (a list of currently valid certificates). These are optional components of the field.

The authorisation field specifies the authority being delegated. This is roughly equivalent to the KeyNoteConditionsfield. Finally, the delegation field specifies whether the authorisations contained within this certificate can be delegated further.

Example 2.5 Figure 2.12 shows an example of a SPKI certificate, representing the Appoint Lecturerpermission discussed in Example 2.3. In this example a certain key (the President’s

(cert

(issuer (hash sha1 |dsEFA73sahfdDF3784JDFjfsFsd=|)) (subject (ref: UCC (ref: CSDEPT (hash sha1 |dasdk...|)))) (propagate)

(

(tag (Appoint Lecturer)) )

(not-before "2002-11-31_17:00:00") (not-after "2003-11-31_16:59:59") )

Figure 2.12: An example SPKI Certificate, authorising the appointing of academic staff.

propagatefield allows this permission to be delegated further, and the validity dates specify that

this certificate is valid for one year only. △

There are three types of SPKI credentials: identity, attribute and authorisation credentials.

• Identity credentials bind a public key to a name, similar to an X.509 certificate. However, unlike X.500 distinguished names, SPKI names are local to each public key in the system.

• Attribute credentials bind an authorisation to a name or group. These are generally used with identity credentials, as different issuers may generate the attribute and identity credentials.

• Authorisation credentials provide a means to delegate authority between names.