Introducing a cmp() operation

[Marcus Brinkmann]

At Wed, 15 Jun 2005 14:35:06 +0200,
Bernhard Kauer <kauer at os.inf.tu-dresden.de> wrote:
> 
> > The nameserver is not necessarily trusted by C.  If C wants to send
> > the capability to B (which it must, to get the mapping hierarchy right),
> > then it must be as a reply message.
> > Thus B must send the request to C, as C is the trusted system server,
> > not A (which B doesn't trust that much).  The required protocol is pretty much
> > enforced from start to end given the border conditions (trust
> > parameters).
> 
> There are two ways how B could get its capability. Either B asks C to give
> them, or A asks C to send one (of the capabilities it has from C) to B.
> 
> Both operations work out of the box. A and B do not trust each other and C do 
> not need a cmp().

That's simply not true, and I have explained why.  If anything I said
was unclear, you should respond to specific points I said and ask for
clarification.  I have to say I am at a loss how I can explain it
further.  Here a summary: A can not ask C to send one, because this
would either mean C has to make a blocking call to B, or B has to make
a blocking call to A _and_ trust A to forward the request to C.  B
really wants to make sure that it gets its own new mapping of the
capability from C, and not from A.

Again: A can not act as an intermediate between B and C, because B
does not trust A for that.  C can not make a request to B because C
does not trust B at all.  B must make the request directly to C.  It's
the only option within the trust boundaries that we set.

The operation where B requests the message from C can not be done
without an operation like map_lookup(), because B has to prove to C
that it has the capability that A provides, and C needs to identify
that capability.

cmp() doesn't even enter the picture here, as it is, I am repeating
myself, useless in this scenario.

If you dispute any of that, please point out precisely which step in
my reasoning you find wrong.

Thanks,
Marcus