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: Brian May
Subject: Re: [Monotone-devel] Security is hard. Let's work on policy branches anyway.
Date: Tue, 23 Jan 2007 12:03:55 +1100
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

>>>>> "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?

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.

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

Possible solution:

Totally revoke Bob's old key and resign all his old revisions with his
new key?

Possibly this might solve the problem of if we don't trust Bob anymore
- revoke his key (somehow to all clients in a distributed manner) and
resign the versions we still trust with another key.

The naming of the key is still a problem though.
-- 
Brian May <address@hidden>




reply via email to

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