monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathaniel J. Smith
Subject: Re: [Monotone-devel] Security is hard. Let's work on policy branches anyway.
Date: Mon, 22 Jan 2007 17:18:49 -0800
User-agent: Mutt/1.2.5.1i

On Tue, Jan 23, 2007 at 12:03:55PM +1100, Brian May wrote:
> >>>>> "Nathaniel" == Nathaniel J Smith <address@hidden> writes:
> 
>     Nathaniel> Alice and Bob both have access, and then Bob's access
>     Nathaniel> is revoked, and life continues on indefinitely:
> 
>     Nathaniel>   +ab
>     Nathaniel>    |
>     Nathaniel>  -b|
>     Nathaniel>    |
>     Nathaniel>   a1
>     Nathaniel>    |
>     Nathaniel>    :
>     Nathaniel>    |
>     Nathaniel>   a50
> 
> I haven't read the full details yet, but my immediately thought is:
> 
> What happens if Bob's access needs to be revoked, not because we don't
> trust him anymore, but because we no longer trust his key (e.g. his
> laptop was stolen).
> 
> Presumably, all signatures before the event can still be trusted, but
> new ones can't be trusted. How do we allow new users to pull from a
> database which contains versions from no-longer trusted signatures?

Check the bottom of my email, where I talk about this problem :-).

> Bob will need to create a new key, but as his email address remains
> constant how do you distinguish the old key from the new key?
> 
> You might end up accidently trusting the old key again.

The binding from key to keyname is planned to be part of the policy
branch data (so you can rename keys etc.), it's just being ignored for
now because we don't anticipate any major difficulties.

> What happens if Bob is unable to alert anybody of the problem until
> after a fraudulent version is committed and synced?  Not unreasonable,
> he just lost his laptop...

Just revoke trust for that particular fraudulent cert.

-- Nathaniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]