On Tue, 31 Mar 1998, Perry E. Metzger wrote:

> > As was suggested in a later email, SPKI is certainly a possibility -- what
> > I'd really like to see is a standard interface to the variety of
> > certificate systems out there so that we can plug in arbitrary PK systems
> > as we need to, be it SPKI, X.whatever, or DNSsec.  They each have their
> > advantages (be it scalability, distributed or centralized management,
> > etc), but I don't want to commit to one :).
> 
> You might find this is hard, given that they all have very different
> ideas about trust and how naming works.

The problem is really that in an ideal world we would support all of these
authentication mechanisms, and then have some policy description language
that told us what authentication to accept, deny for various identities,
and how to map all of the various types of identities to ones that Coda
understands.  It has been suggested that we scrap large parts of the
current authentication and replace them with Kerberos, but I'd rather not
lock us into an authentication system that closely without a lot more
thought. :)  Having a general architecture for authentication would make
life a lot easier.

One of my thoughts on managing large authentication domains had been to
map them into DNSsec, and then allow "Authentication Referral".  Take a
look at draft-ietf-dnssec-ar-00.txt.  I wrote it up largely to see if
there was interest/ongoing work in trying to integrate support for
multiple authentication systems in DNSsec, which apparently there is not
currently much support for :).  Clearly, this method of "Referral" would
not be able to manage some of the details of SPKI, as DNS-AR make use of
centralization of authentication information.  However, it would be fairly
simple to adapt Coda to use DNS-AR to pull in some form of PK
authentication (over DNSsec keys, misc certificates), KerberosIV and V;
even NIS, NIS+ and Radius.  It is not clear at this point whether the idea
of mapping all identities into DNS is going to fly with DNSSEC/DNSIND
working groups.

I will reread the SPKI drafts and get back to you with my thoughts on
adding support to Coda.  Coda, as an off-shoot of AFS, does seem to follow
the tradition of centralized, closed servers -- it would be interesting to
see how SPKI could fit into this architecture.  In a sense, my currently
implementations of various authentication schemes map foreign identities
to local names, where the existence of mapping rules forms a sort of
authorization model for providing "Coda Tokens" to the entity in question,
allowing them to authenticate as the coda local name when contacting
servers.  Maybe we should be looking at some other models?

  Robert N Watson 

Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services  http://www.safeport.com/
robert@fledge.watson.org   http://www.watson.org/~robert/