httpy://

Ben Laurie ben@algroup.co.uk
Mon, 15 May 2000 01:22:46 +0100


Tyler Close wrote:
> I introduced something like this in my response to Ben. The idea was
> to create a family of schemes, all ending in 'y' that use SLS to
> locate multiple possible hosts. This is similar to the family of
> schemes that append 's' to indicate protocols that will be run over
> TLS. I like the way this turns SLS into a general replacement for DNS
> that all schemes can use.
> 
> Ben referred to this as a "URI -> URL transformation". I think that
> this is the best way to look at the service that the SLS provides.
> 
> In my last message, I suggested a transformation that turns a URI into
> a list of URLs of a particular scheme.
> 
> Since you're expressing a desire for a single, protocol neutral,
> capability URI, maybe we should create a URN that can be transformed
> into a list of URLs of mixed schemes (where I started from in the
> first httpy post).
> 
> I'll suggest:
> 
> urn:cap:<public-key-hash>/<cap-string>
> 
> where <cap-string> is a host specific string. In the case of an E Vat,
> it's a SwissNumber. In the case of a Droplet database, it's a
> <zone>/<database>/<context>/<swiss-number>.
> 
> So now our SLS responds to two types of location queries.
> 
> When the user-agent has a urn:cap, it sends a location request
> (public-key-hash) and gets back a list of (scheme, DNS hostname, IP
> address, port).
> 
> When the user-agent has a URI like HTTPY, it sends a location request
> (public-key-hash, scheme) and gets back a list of (DNS hostname, IP
> address, port).

Exactly. I presume you are aware of RFC 2483: "URI Resolution Services
Necessary for URN Resolution", but if not, you need to look at it. The
transformation (which they call an operation) you are describing is
I2Ls.

> 
> > However, I notice something present in cap: URIs that's
> > missing in your
> > proposal:  The list of TCP/IP addresses of the SLSs to
> > consult.
> 
> Since I use SLSs to localize requests, as well as to route them, it
> doesn't make sense to specify SLSs in the URI. The entity creating the
> URI can't know in advance where the URI will be used from.
> 
> >  Sure, the
> > browser can be configured to check some well known ones,
> > but if you're going
> > to have a truly decentralized and non-corruptible system,
> > it's important for
> > the URI string to carry its own list of suggested SLSs as
> > well.  Otherwise,
> > the well known SLSs becomes a point of vulnerability.
> 
> I wasn't expecting to have any 'well known SLSs'. I was expecting each
> region of the web to have its own SLS. If you're concerned about the
> security of the local SLS, you can run your own without having any
> security dependencies on any other SLSs. This is why the signed SLS
> entry message is just forwarded, as is, around the web of SLSs. You
> might then configure your user-agent to query multiple SLSs and report
> any discrepancies between them.
> 
> I believe this is a truly decentralized system that can strongly
> isolate any corruption.

Aren't the resulting URLs going to be signed by the owner of the URI,
and hence unforgeable?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html