SPKI Certificates


Carl Ellison
Affiliation: Cybercash
Abstract: The Simple Public Key Infrastructure [SPKI] group has come up with a proposed certificate structure to fit the charter of the group. From the message launching the SPKI group on 22 Feb 1996...

"According to the proposed charter, the SPKI group will:

develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use."

An SPKI Certificate addresses the primary needs of developers with as few options and as little overhead as possible. Those needs are, in order as far as the SPKI group has been able to determine:

1) to know with assurance if a public key is authorized to perform some action, eg.: a) access a system b) spend money from a given account c) write a purchase order d) sign a contract binding a company e) pay taxes f) vote g) .. etc.

2) to grant or revoke authorizations for named groups of keyholders

3) to delegate authority to temporary keys [allowing for the possibility that long-lived public keys are not made generally available]

4) to associate a public key with a name -- most especially, for individual mail privacy and standard ACL uses, using a local name meaningful to the person sending the e-mail or writing the ACL. These names should be thought of as nicknames or SDSI names, rather than global names. [We do not believe there is, can or should be any such thing as a global name.]

5) to disseminate useful information, secure from tampering (e.g., one's own preferred e-mail address or name)

An SPKI certificate does not directly address the specification of complex policies as in PolicyMaker or the distribution of keys and certificates as in DNSSEC. We intend to rely on that work if possible rather than re-create it.

The SPKI group sees items (1) through (3) as the predominant need for public key trust certification and therefore we label SPKI certificates "Authorization Certificates" to distinguish them from Identity Certificates (such as X.509). However, one form of certificate, (4), includes identity certification as a subset. [As Rivest and Lampson point out, a commercial CA is one owner of a local namespace and can issue SDSI names just as anyone else can. It can therefore issue SPKI certificates as well.]

An SPKI certificate is limited to the following fields:

Subject: , Issuer: ,

and a signature on that body. gives a specific authorization -- and is indefinitely extensible to include any authorization (or name specification, PolicyMaker statement or S-expression) of interest to a user of certificates. Extensions do not require interactions with any standards body.

The current draft specification is available at http://www.clark.net/pub/cme/spki.txt or ftp://ftp.clark.net/pub/cme/spki.txt and that draft goes into significant detail on kinds of authorization as well as a process for reducing chains or meshes of certificates (possibly of mixed format (X.509, SDSI, PolicyMaker, SPKI)) into a signed certificate result which is, itself, an SPKI certificate. That draft also specifies the simple binary encoding for SPKI certificates and a short summary of the reasoning behind the rejection of ASN.1 and X.509.

For more information, contact cme@cybercash.com