Hi Thanks for the thoughtful responses as usual :-) More below.
On Wed, 2005-10-12 at 10:36 +0200, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Tue, 11 Oct 2005 23:52:12 -0700, Nathaniel > Smith <[EMAIL PROTECTED]> said: > > njs> On Tue, Oct 11, 2005 at 11:26:32AM -0700, Conrad Steenberg wrote: > [...] > njs> > As an example, we issue X509 certs to every member of a > njs> > collaboration, and having to manage ssh and monotone (and > njs> > other) keys is a major administrative pain. E.g. monotone keys > njs> > are not signed and have to concept of revocation lists etc. > [...] > njs> In monotone's case, though, we actually use the signatures for > njs> something a bit different, so I think different mechanisms end up > njs> being called for. Version control inherently revolves around > njs> long-term immutable archival. It's just not right that old > njs> versions of your tree disappear from a branch, because the person > njs> who committed them left the project now... > > I think you're operating under some false assumptions. Just because a > certificate was revoked yesterday, it doesn't mean that a signature > made a week ago suddenly becomes invalid. All that's needed is to > attach a datetime to the thing being signed before signing it, and > compare that to the revokation datetime to know if the signature is to > be regarded as valid or not. Agreed. The use of key trust features are only needed when the person tries to interact with the tree: commit or retrieve revisions. Once the authorization to interact with the tree is given by e.g. a server, there is functionally no difference between a monotone keypair or an X509 keypair. > > The biggest trouble with X.509 certs, as I see it, is that it would > automatically mean that the monotone administrators would have to run > a CA and start signing certs for the users (it may very well be a copy I honestly believe the usability of a CA-based setup is a matter of implementation: it is trivial to write a script that uses the openssl command-line to generate a self-signed key and then import the key into a monotone database - so the current non-signed case can be retained without the user or admin even noticing. You're right that if a monotone admin wants to, it would be possible to run a CA (or use another CA, including some of the free CAs), with some lua hooks to implement ACLs, with the added attribute of a CA identity to test for, not just a key name. > of a cert from somewhere else, that's not a problem), or trust some > local CA. I do not see any gain in having monotone administrators > trust VeriSign for validity and then have to keep an internal list of > permitted users, because then what's the point? You're right, of course. The absolute size of revocation lists tend to be zero 99.9% of the time though, and thus a lot less time-consuming to administer. I think my argument for the use of an existing key trust system boils down to: - reduce time spent on developing a new key trust system - identity portability --- Actually this brings up a question on the current trust implementation: Consider the case where tree T contains the key of _only_ developer D1. Developer D1 has a tree T1, containing the key of developer D2. If D2 commits a revision to T1. D1 then syncs his tree T1 -> T. Would the change by D2 be accepted in T? Corollary to that: if the answer to the above is "no", can D1 "bless" or re-sign the changes made by D2 to help get them included into tree T? Obviously, I think it would be great if the answers to the above could be "no" and "yes" respectively ;-) Regards Conrad -- Conrad Steenberg <[EMAIL PROTECTED]> California Institute of Technology
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
