Mon, 15 May 2000 15:50:09 -0400
Tyler Close wrote:
> Ben Laurie wrote:
> > Tyler Close wrote:
> > >
> > > Ben Laurie responding to me:
> > > > > The only reason to sign something is if you want to
> > > > provide offline
> > > > > verification of authenticity, or non-repudiation. I can't
> > > > think of any
> > > > > scenarios in which I'd want to verify the
> > authenticity of a URI
> > > > > offline. It's so much easier to just click on it.
> > > >
> > > > Unless you have a reverse mapping embedded in the response
> > > > to the URL
> > > > fetch, clicking on it doesn't verify its correctness, only its
> > > > 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.
> > >
> > > How does mallet effect this perversion?
> > I don't know. Are you saying he can't? Since you were talking about
> > untrusted SLSes earlier, I presumed this was easy!
> Your user-agent (the browser) trusts the combination of its configured
> SLS(es). An SLS does not trust any other SLSes (whats the plural of
> SLS?). An SLS will only accept entries that it can directly see came
> from the private key holder (because the entry is signed with that
> private key).
> Mallet has to hack your trusted SLS(es) in order to make the
> perversion. If your user-agent is configured for multiple SLSes, then
> mallet must hack them all, not just one, or the perversion will be
Why trust anyone? Mallet could very well corrupt all your SLSes,
especially if you have only one (and security is not just for the
The obvious solution is for the SLS to show the user agent the entries
themselves. The user agent can verify them just as the SLS would, but
presumably would not mention this to the user unless it fails. This is
equivalent to building an SLS into the browser. A local SLS cache is
probably a good thing anyway.