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 detected.
Tyler