Re: [Monotone-devel] Re: key trust

[Conrad Steenberg]

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 <address@hidden> on Tue, 11 Oct 2005 23:52:12 -0700, Nathaniel 
> Smith <address@hidden> 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 <address@hidden>
California Institute of Technology

smime.p7s
Description: S/MIME cryptographic signature