Re: [Monotone-devel] Re: key trust

[Conrad Steenberg]

On Wed, 2005-10-12 at 08:55 -0700, Nathaniel Smith wrote:
> On Wed, Oct 12, 2005 at 10:36:15AM +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> 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.
> 
> I don't understand -- Alice writes out a cert saying "in June, I say
> version da39 is good".  Then her cert gets revoked with a July
> timestamp.  So Bob trusts the cert that says "in June, ...", because
> June < July.  Then in December Mallory comes along, with his cracked
> copy of Alice's old key, and writes out a cert saying "in June, I say
> version 0123 is good".  So Bob trusts _that_ cert too...

Simply stated, any interaction with the tree that involves the revoked
cert should be refused for all eternity as soon as the revocation gets
published. I.e. any revisions being checked in by anyone that are signed
by Alice should be rejected.

Obviously Alice would need to get a new cert to get changes committed to
the tree again.

Any revisions in the current tree(s) signed by Alice's revoked cert
needs to be checked for malicious code etc. That is not a matter of
cryptography, there's no way around that...

Alice's changes then need to be re-certified in some way.

This re-certification is also useful in order to allow contributions
from outside the trusted inner circle. Think of the Linux kernel "Change
signed off by" policies. See the questions in my earlier mail.

> More generally, we don't have reliable date-time -- even if we could
> somehow force people to not outright lie about times, we don't have a
> centralized clock they could use (and should not add such a
> requirement).

Fortunately, you don't need reliable time-stamps at all, just a
revocation list that amends some of the rules of how the tree state can
be changed in future.

The physical "time" aspect is merely a convenience for us humans to
refer to. As far as the tree is concerned there is only "state", as
signified by a "revision" stamp.

Conrad

-- 
Conrad Steenberg <address@hidden>
California Institute of Technology

smime.p7s
Description: S/MIME cryptographic signature