monotone-devel
[Top][All Lists]
Advanced

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

key trust (was Re: [Monotone-devel] Transport encryption)


From: Nathaniel Smith
Subject: key trust (was Re: [Monotone-devel] Transport encryption)
Date: Tue, 11 Oct 2005 23:52:12 -0700
User-agent: Mutt/1.5.9i

On Tue, Oct 11, 2005 at 11:26:32AM -0700, Conrad Steenberg wrote:
> Hi Nathaniel
> 
> Another alternative might be to have a utility to convert x509 certs and
> their associated private keys to the format monotone uses, and then use
> the former for SSL tunneling. If monotone is using RSA keys, it could be
> (almost) trivial.
> 
> The advantage is that x509 is supported by a lot of libraries and
> browsers - despite the fact that those libraries might be horrid, they
> do work and are quite widely inspected for holes already.

I can't really speak to this part, since I try to leave crypto-related
details up to others (I have a finite number of sanity points, and it
seems better if I spend them on merging).

> As an example, we issue X509 certs to every member of a collaboration,
> and having to manage ssh and monotone (and other) keys is a major
> administrative pain. E.g. monotone keys are not signed and have to
> concept of revocation lists etc.

But here I want to say -- I appreciate your situation, but I think
things might be a bit more subtle than you imply.  As I understand it,
things like key signatures and revocation lists are used as part of a
particular usage model: basically, we want to know who is authorized
to use some resource, at any given point in time.  The last part is
important -- we want to know whether this person should be allowed to
log in _right now_, or whether this email we _just got_ is valid, and
for this, certificate authorities and revocations and expiration dates
are Good Stuff.

In monotone's case, though, we actually use the signatures for
something a bit different, so I think different mechanisms end up
being called for.  Version control inherently revolves around
long-term immutable archival.  It's just not right that old versions
of your tree disappear from a branch, because the person who committed
them left the project now...

We have some ideas on how to manage this, that haven't been
well-written up anywhere, but there is an IRC log discussing the basic
ideas:
   http://frances.vorpus.org/~njs/mt-permission.html
The basic problem being tackled is how to allow a single universally
trusted person or group to define which keys are trusted, and do this
in a way that both respects monotone's distributed nature, and has a
trust model that's appropriate for a VCS (in the way I argued above
that standard CRLs aren't).

This is all vapor, though, at the moment.  Not because we don't think
it's important -- this sort of decentralized trust stuff is actually
kind of the whole point monotone was created to work towards -- it's
just that we've gotten side-tracked trying to get basic VCS
functionality that doesn't suck :-).  Key management is definitely an
area we need to work on, and we know that...

Your use case of wanting a single common interface to adding/removing
users is interesting and appreciated.  I'm not sure how possible it
will be do achieve quite what you want, even in principle, but it
should at least be possible to automate the "kick this person out of
the project going forward" process to a button-press sort of thing...

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."




reply via email to

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