Tyler Close wrote:
>
> > existence. i.e. what I'm saying is you need a defence against mallet
> > finding that perverting URI mapping uri:A -> url:B to map
> > uri:A -> url:C
> > instead, where url:C is a working URL, has a useful effect.
>
> I think I got myself all confused yesterday.
>
> If url:C is a working URL, then it must be a valid mirror of url:B.
>
> url:C and url:B have the same <url-path>. The SLS transformation only
> affects the <host>:<port> portion of the URL. If mallet perverts the
> transformation so that url:C is not a valid mirror site, then the
> perversion will be caught during the site authentication stage of the
> connection between the user-agent and the site. The bogus site will
> not have the private key corresponding to the public-key-hash in
> uri:A.
>
> If the uri:A scheme is not an authenticated protocol, then there is no
> way to prevent a capable mallet from responding on any IP address that
> the client may use. In this case, there is no real security gained by
> making sure that the client only initiates connections on IP addresses
> listed by the owner of uri:A.
>
> If the site for url:C does have the private key corresponding to the
> public-key-hash in uri:A, then it must be a mirror for url:B. If url:C
> is a mirror for url:B, then the <url-path> must, by definition, refer
> to the same object on both site B and site C.
Aha. OK, then we're not really talking about URLs at all, we're talking about mapping _part_ of a URI to _part_ of a URL (specifically, the part called the "authority", appropriately enough), but leaving the rest to the client to map (or rather, copy).
I don't think this is a defined transformation, but I can't see any reason to not do it anyway. However, we do need to come up with some terminology that doesn't lead to this confusion :-)
> Unless I've missed something, let's go back to the previous iteration
> of SLS, that did not deliver the signed SLS entry. Clients do not
> trust any SLSs. For unauthenticated schemes, the results are merely a
> best effort.
That seems reasonable.
Cheers,
Ben.
-- http://www.apache-ssl.org/ben.html