In message <[EMAIL PROTECTED]> on Wed, 12 Oct 2005 09:11:48 -0700, Conrad Steenberg <[EMAIL PROTECTED]> said:
conrad> On Wed, 2005-10-12 at 10:36 +0200, Richard Levitte - VMS Whacker wrote: conrad> > In message <[EMAIL PROTECTED]> on Tue, 11 Oct 2005 23:52:12 -0700, Nathaniel Smith <[EMAIL PROTECTED]> said: conrad> > conrad> > njs> On Tue, Oct 11, 2005 at 11:26:32AM -0700, Conrad Steenberg wrote: conrad> > [...] conrad> > njs> > As an example, we issue X509 certs to every member of a conrad> > njs> > collaboration, and having to manage ssh and monotone (and conrad> > njs> > other) keys is a major administrative pain. E.g. monotone keys conrad> > njs> > are not signed and have to concept of revocation lists etc. conrad> > [...] conrad> > njs> In monotone's case, though, we actually use the signatures for conrad> > njs> something a bit different, so I think different mechanisms end up conrad> > njs> being called for. Version control inherently revolves around conrad> > njs> long-term immutable archival. It's just not right that old conrad> > njs> versions of your tree disappear from a branch, because the person conrad> > njs> who committed them left the project now... conrad> > conrad> > I think you're operating under some false assumptions. Just because a conrad> > certificate was revoked yesterday, it doesn't mean that a signature conrad> > made a week ago suddenly becomes invalid. All that's needed is to conrad> > attach a datetime to the thing being signed before signing it, and conrad> > compare that to the revokation datetime to know if the signature is to conrad> > be regarded as valid or not. conrad> conrad> Agreed. The use of key trust features are only needed when the person conrad> tries to interact with the tree: commit or retrieve revisions. conrad> conrad> Once the authorization to interact with the tree is given by e.g. a conrad> server, there is functionally no difference between a monotone keypair conrad> or an X509 keypair. conrad> conrad> > conrad> > The biggest trouble with X.509 certs, as I see it, is that it would conrad> > automatically mean that the monotone administrators would have to run conrad> > a CA and start signing certs for the users (it may very well be a copy conrad> conrad> I honestly believe the usability of a CA-based setup is a conrad> matter of implementation: it is trivial to write a script that conrad> uses the openssl command-line to generate a self-signed key conrad> and then import the key into a monotone database - so the conrad> current non-signed case can be retained without the user or conrad> admin even noticing. Yes, self-signed certificates would provide exactly the same capabilities as today's key system does. This is what OpenCM did (does?), and I questioned that kind of use with that group, and I will here as well. Basically, it provides nothing more than bloat around the keys. If you're going to use X.509, do it for real. conrad> You're right that if a monotone admin wants to, it would be conrad> possible to run a CA (or use another CA, including some of the conrad> free CAs), with some lua hooks to implement ACLs, with the conrad> added attribute of a CA identity to test for, not just a key conrad> name. I thinking more along the lines of generating certs with a specific policy for monotone use, and being able to handle trust through policy settings. That would mean you wouldn't have to change any lua code at all. conrad> I think my argument for the use of an existing key trust conrad> system boils down to: conrad> - reduce time spent on developing a new key trust system I don't believe you're doing much of that right now. conrad> - identity portability That's an argument I can accept, actually, if you depend on identity uniformity for all subsystems you have in your site. conrad> Actually this brings up a question on the current trust conrad> implementation: Consider the case where tree T contains the conrad> key of _only_ developer D1. conrad> conrad> Developer D1 has a tree T1, I assume you mean D2... conrad> containing the key of developer D2. If D2 commits a revision conrad> to T1. D1 then syncs his tree T1 -> T. Would the change by D2 conrad> be accepted in T? Yes, if the sync is accepted, the revisions from T1 are integrated into the database holding T. However, when D1 does 'monotone update', the hook get_revision_cert_trust. The name is a bit weird, because it doesn't express the trust in the revision signature itself, but if I understand the code correctly, if no certs for a revision is trusted, the revision itself is untrusted as well. BTW, we need to change the example, it's still about the ancestor cert, which stopped existing almost a year ago... Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
