Re: [Monotone-devel] Re: key trust

[Richard Levitte - VMS Whacker]

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