This has recently caught my interest, I've seen it before, but brushed
it aside for some reason:
www.ists.dartmouth.edu/library/16.pdf
SPKI even rates a mention in Li Gong's "Inside Java 2's platform
security" 2nd ed. page 144.
There is some BSD licensed software on sourceforge called JSDSI,
although it hasn't been actively developed recently, the code looks
relatively clean.
Anyway, I'm thinking about writing some graphical utilities to manage
pubic private key pair and certificate generation and storing keystores
and truststore's.
The appealing thing about SPKI is it's based on local name spaces, ideal
for internet based secure communications.
Authentication is left up to the local namespace, so for instance
someone can log on using PAM (or any other login provider) their Subject
then runs with their authenticated Principal ( a Certificate), their
company Principal (Certificate) would then delegate permission, if
allowed for that Principal to communicate with another company's network
on behalf of the company. The second company is only concerned with the
first, not with the details of the user from the first company. So it
provides and allows for anonymity, if required.
I'm not completely sure how it integrates with Java 2 Security, or
whether the java security policy needs to provide support for it. It
should be relative simple binding local names to principals using
keystore aliases. This allows interacting, but separate companies, to
have their own principal aliases for each other, their users, user
groups or roles etc.
To quote the referenced paper (pages 7 & 8):
"In 1996, Ron Rivest and Butler Lampson at MIT designed the Simple
Distributed Security Infrastructure (SDSI) [26]
with the main goal of facilitating “the building of secure,
scalable, distributed computing systems” [7]. Around the
same time, Carl Ellison proposed the Simple Public Key
infrastructure (SPKI) [5] to simplify authorization. In 1998,
these two proposals merged to form SPKI/SDSI.
One of the main goals of SPKI/SDSI is to provide flexible and
lightweight authorization—particularly in comparison
to X.509. Moreover, to avoid the ambiguity problems in global names,
SPKI/SDSI is centered on public keys—since
a PKI principal always ends up needed to prove knowledge of the
private key. SPKI/SDSI is egalitarian: no global
hierarchy or hierarchical infrastructure necessary. Every principal
is free to issue certificates to other individuals. This
also leads to scalability. As noted above, SPKI/SDSI is centered on
keys, and dispenses with the notion of globally
unique names. A principal is free to use names, but these names are
explicitly part of that principal’s local namespace.
SPKI/SDSI works by combining a public key with a set of attributes
to form an authorization certificate (in contrast
to its counterpart, the X.509 attribute certificate that binds a
distinguished name to a public key). Figure 4 shows this
authorization triangle [12]. SPKI/SDSI authorization certificates
list the issuer and subject (both identified via public
keys), a tag field that carries the conveyed authorization, and
validity dates.
One of the other main advantages of SPKI/SDSI is its ability to
delegate authorization easily. This is done using a
propagate bit in the authorization certificate. If this bit is set,
then the subject of this certificate can re-delegate the
permission or attributes he is given. Delegation is transitive; if
Alice delegates to Bob (with permission to delegate
further) and Bob delegates to Carol, then in effect Alice has
delegated to Carol.
SPKI/SDSI can also create name certificates binding names to public
key but they are not required for authorization
decisions. The name is valid only for the local namespace and is
used by the principal only for personal identification
SPKI/SDSI name certificates list issuer and subject (both identified
via public keys), identifier (the local name), and
validity dates. In SPKI/SDSI, a principal can also create groups by
issuing multiple name certificates—one for each
group member—with the same name and different subject keys. The
concept of groups can also be used to create roles
for role-based authorization."
"In SPKI/SDSI, an authorization flow is a chain of valid
certificates—authorization only, or authorization and name—
that specifies an authorization [7]. The trust root of an
authorization flow is the first principal in the chain who started
the delegation process. Unlike X.509, this principal does not need
to be a distinguished CA.
SPKI/SDSI certificates use S-expressions: “human-readable ASCII
representations” [25]. LISP-like S-expressions
make it easy for humans to read a certificate and deduce its
meaning, in contrast to X.509 and ASN.1. Parsing
canonical S-expressions can take much less code size that parsing
ASN.1 data; in one study [11], S-expression parsing
code takes 8 KB, while ASN.1 parsers take 50KB to 500KB,.
As noted earlier, SPKI/SDSI uses a tag-language to express
authorization information through large sets of strings or
S-expressions. Standard libraries may be written to intersect
certificate tags and deduce what an authorization chain
authorizes. On the other hand, because of X.509’s generality, each
developer is free to define an X.509v3 extension
format and then define how those attributes may be intersected.
Thus, each application using X.509 has to write a
separate X.509 chain-processing routine.
In contrast to X.509, SPKI/SDSI emphasizes short-lived certificates,
rather than Certificate Revocation Lists (CRLs)."
Cheers,
Peter.
