Re: cap exchange race with map/unmap

[Jonathan S. Shapiro]

Marcus:

Please re-send using the more careful notation. I suspect that you
aren't getting out the revocation hierarchy that you think you are.
Whether I am right or wrong, it is better to be sure.

shap


On Wed, 2005-10-19 at 15:10 +0200, Marcus Brinkmann wrote:
> At Wed, 19 Oct 2005 09:52:40 +0200,
> address@hidden (Ludovic Courtès) wrote:
> > 
> > Hello,
> > 
> > Marcus Brinkmann <address@hidden> writes:
> > 
> > > At Tue, 18 Oct 2005 14:27:56 -0400,
> > > "Jonathan S. Shapiro" <address@hidden> wrote:
> > >
> > > [A broken protocol snipped]
> > >
> > >> I believe that the only possible protocol that could be correct is for
> > >> all object servers to return by way of CapServer.
> > >
> > > I agree.  This is exactly what I proposed in my talk in Dijon.
> > >
> > > The server maps a revocable copy to the cap server.  The cap server
> > > maps another revocable copy to each client.
> > 
> > Marcus, how is this different from what Jonathan described in
> > <address@hidden>, that is:
> > 
> >   In the absence of any authority to fabricate new capabilities, the
> >   following chain of mappings is now in effect after the exchange:
> > 
> >         RevCopy                RevCopy
> >      A ----------> CapServer -----------> B
>  
> Here, A and B are clients.  Let me draw you a picture of the only
> solution I know, which also Shapiro mentioned above:
> 
> Before copy operation:
> 
>            RevCopy               RevCopy
> Server S ----------> CapServer -----------> A
> 
> After A initiated the copy operation to B:
> 
>            RevCopy               RevCopy        RevCopy
> Server S ----------> CapServer -----------> A ----------> B
> 
> After B initiated the copy operation from the cap server.
> 
>            RevCopy               RevCopy        RevCopy
> Server S ----------> CapServer -----------> A ----------> B
>                              ^                            |
>                              |           RevCopy          |
>                              +----------------------------+
> 
> The revocable copy from B to the cap server proves to the cap server
> that B possesses the capability, and furthermore allows the cap server
> to identify the capability to copy in the first place!
> 
> At the end of copy operation:
> 
>            RevCopy               RevCopy        RevCopy
> Server S ----------> CapServer -----------> A ----------> B
>                              |                            ^
>                              |           RevCopy          |
>                              +----------------------------+
> 
> The copy from B to the cap server has been removed.  It's not needed
> anymore.
> 
> After the copy operation:
> 
>            RevCopy               RevCopy
> Server S ----------> CapServer -----------> A
>                              |
>                              |   RevCopy
>                              +------------> B
> 
> The copy from A to B has been removed.  It is not needed anymore.  Now
> A and B have a co-equal copy.
> 
> Thanks,
> Marcus
>