monotone-devel
[Top][All Lists]

## Re: [Monotone-devel] Re: Security is hard. Let's work on policy branches

 From: Justin Patrin Subject: Re: [Monotone-devel] Re: Security is hard. Let's work on policy branches anyway. Date: Wed, 11 Apr 2007 14:18:25 -0700

```On 4/11/07, Bruce Stephens <address@hidden> wrote:
```
```"Nathaniel J. Smith" <address@hidden> writes:

[...]

> So suppose that we want to determine whether some merge node R is
> trusted.  What we can do is take the certs that claim it should be
> trusted, and walk over the graph checking for each node whether that
> particular node likes this cert, i.e., mapping our function over the
> DAG.  This generates a new DAG in which all the values are simple
> binary scalars.  I suggest that _this_ is the right DAG to calculate
> the meaning of "merge(S, T)", in the definition of inherent trust.
>
> For instance, in the examples from Problem 3, we are interested in
> whether c1 should be trusted:
>
>      +ab          +abc
>      / \           / \
>   +c/   \         /   \-c
>    /     \       /     \
>   a1      b1    a1      b1
>    \     /       \     /
>     \   /+c       \   /+c
>      \ /           \ /
>       c1            c1
>
> In the left case, the c1 cert looks good according to a1, only, so we
> get a binary graph (using "+" for "trusted" and "-" for "not trusted")
> like:
>     -
>    / \
>   +   -
>    \ /
>     ?
> Clearly this merges to "+", i.e., c1 trusted.
>
> In the right case, the c1 certs look good according to a1 and the
> root, but not b1.  So we get a binary graph like:
>     +
>    / \
>   +   -
>    \ /
>     ?
> Clearly this merges to "-", i.e., c1 untrusted.

Why is that clear?

Are you using *-merge here?  I'm quite willing to believe *-merge
defines all these cases coherently; I just have the impression you're
assuming something somehow more primitive?
```
```
Yes, *-merge.

The *ed nodes are:
+*
/ \
+  -*
and since +* is an ancestor of -*, -* wins.

--
Justin Patrin

```