"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:
and a signature on that 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