[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: key trust
From: |
Richard Levitte - VMS Whacker |
Subject: |
Re: [Monotone-devel] Re: key trust |
Date: |
Wed, 12 Oct 2005 19:37:43 +0200 (CEST) |
In message <address@hidden> on Wed, 12 Oct 2005 09:11:48 -0700, Conrad
Steenberg <address@hidden> said:
conrad> On Wed, 2005-10-12 at 10:36 +0200, Richard Levitte - VMS Whacker wrote:
conrad> > In message <address@hidden> on Tue, 11 Oct 2005 23:52:12 -0700,
Nathaniel Smith <address@hidden> 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 address@hidden
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
- Re: [Monotone-devel] Transport encryption, (continued)
- Re: [Monotone-devel] Transport encryption, Michael Neumann, 2005/10/13
- Re: [Monotone-devel] Transport encryption, Michael Neumann, 2005/10/13
- Re: [Monotone-devel] Transport encryption, Conrad Steenberg, 2005/10/11
- key trust (was Re: [Monotone-devel] Transport encryption), Nathaniel Smith, 2005/10/12
- [Monotone-devel] Re: key trust, Richard Levitte - VMS Whacker, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Brian Campbell, 2005/10/12
- [Monotone-devel] Re: key trust, Nathaniel Smith, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Conrad Steenberg, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Richard Levitte - VMS Whacker, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Conrad Steenberg, 2005/10/12
- Re: [Monotone-devel] Re: key trust,
Richard Levitte - VMS Whacker <=
- [Monotone-devel] Re: key trust, Bruce Stephens, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Conrad Steenberg, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Richard Levitte - VMS Whacker, 2005/10/12
- [Monotone-devel] Re: key trust, Bruce Stephens, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Richard Levitte - VMS Whacker, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Conrad Steenberg, 2005/10/12
- Re: [Monotone-devel] Re: key trust, Richard Levitte - VMS Whacker, 2005/10/12
- [Monotone-devel] Re: key trust, Lapo Luchini, 2005/10/13
- Re: [Monotone-devel] Re: key trust, Chad Walstrom, 2005/10/13
- [Monotone-devel] Re: key trust, Lapo Luchini, 2005/10/13