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)." _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel