[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [graydon@gabber.multinet.net: Thinkin' about identifiers...]
On Mon, 6 Jan 1997, Ron Rivest wrote:
>
> I'd be interested in seeing what you come up with.
>
> If you haven't seen our paper on SDSI, please take a peek at it
> (http://theory.lcs.mit.edu/~rivest, publications); it deals with
> similar stuff, a bit differently...
>
> Cheers,
> Ron Rivest
I have just read your paper on SDSI; happily it seems we are working on
projects which complement each other well. My original intrest in a strong
naming scheme grew out of my intrest in publicly implementing stanford's
ontology server project, which uses KIF to represent local-name-scope
knowledge bases in a (possibly) distributed system. The possibilities for
machine-learning and CMC within such a setting are immense and quite
inspiring. I thought I'd get to work making a friendly client and possibly
porting their server, in order to make the effort to build a good sized KB
as public as possible. I totally support the exported-lexical-scope notion
for building local bindings. The problem which arose, and which I believe
still plagues the name systems you have included thus far in your "well
known roots" list, which gets used when exported relationships either do
not exist or have failed, is that these global name systems are too
heavily influenced by other uses, other application-domains.
As a result of being tied to a domain which is unrelated to principal
identity, such a global name is not under individual control. Furthermore
you're placing the burden of resolving multiple name-types on the clients,
which likely already have to deal with multiple hashing algorithms and
multiple security paradigms. Also, it becomes tricky to decide where
(physically) SDSI auto-cert servers go, when they live in multiple
namespaces. What if your X.500 organization borders fon't follow your DNS
borders? Where do you put certificates for principals in one office with
both email names and X.500 names? How do you co-ordinate the databases?
Who is running your server?
SDSI seems extremely advanced and flexible, but basically requires a
powerful recursive S-expression evaluation engine (like say, libguile) to
be embedded in each implementation. While this is a desirable scenario for
all software, it's not likely given today's programmers and today's market
-- particularly not in consumer electronics or embedded systems. I don't
expect all secure devices will have the patience or resources to do a full
SDSI implementation. All I'm proposing is an identifier-distribution and
association network. The certificate-authentication interface of my
implementation will be quite generic, and will likely be amenable to SDSI
as well as X.509, PGP, and hopefully some low-overhead schemes which
consumer electronics can use to work securely even given limited memory.
It is neither my concern nor remotely within my ability to code such
security systems. I'm focusing on making an identifier system which is an
order of magnitude more reliable and flexible than DNS, which requires
virtually no maintenance and which has no identifiable attack points.
You should be able to walk up to any system, connected to the internet in
even the thinnest possible way, and say "I am bleh-bleh, and I have
someone here who says they are blah-blah-blah... give me some credentials
so I can prove it". This includes the special case of "I am bleh-bleh,
here are some personal credentials, I want access to everything I am
authorized to do, from this new location". It's up to them what sorts of
extended credentials they use, and it is up to an external module of the
server software to decide what sort of inter-peer communication security /
update authorization system gets used. My plan is to rip off the
structure of IP6 secure-OSPF code for the server-location and database
concurrency module, I'll probably just wrap data-conversion code around
berkeley DB for the actual records, and then present pluggable generic
security and communication layer APIs to handle the outside world. I'm
using a very simple protocol.. most of the thinking work gets done by
client libraries living above the name service (like SDSI).
I definitely like what you've done so far. It's cool. It's essentially the
set of security predicates which were missing from early KIF/KQML designs.
Hopefully they can be more tightly integrated in the future. You might try
re-coding your predicates in KIF, as ARPA likes it so much ;) In the
meantime I am going to go ahead with designing my little
identfier/credential daemon. I'll publish it widely as soon as I have even
a fragment of code that compiles (some of us really suck at anything
system-level ;)
I'm working on an internet-draft that spells out my motives a little
better. I think I have most of the glaring technical details covered. I'll
post it when I'm done.
Thanks for your response.
-graydon <graydon@pobox.com>