[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] [RFC] versioned policy -- introduction

From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] [RFC] versioned policy -- introduction
Date: Thu, 07 Sep 2006 09:06:15 +0200 (CEST)

In message <address@hidden> on Wed, 6 Sep 2006 23:28:30 -0700, Nathaniel Smith 
<address@hidden> said:

njs> Questions, comments?

I've one quickie.  You said this about keys names:

njs>   * Our key names are required to be globally unique over space and
njs>     time.  This turns out to be very bad; we need to make it possible
njs>     to get rid of old keys, and create new ones.  That each key used
njs>     "burns a hole" in this global namespace makes our current
njs>     approach unsustainable in practice.
njs>     -- Solution?: create some kind of local, per-project namespace,
njs>        within which keys have names.  The bindings of name to key
njs>        should be shared by all members of the group, but should be
njs>        allowed to change over time.

I still don't understand why keys would be stored by name.  In the
rest of the security community, keys are identified by a form of hash,
or a fingerprint if you will.  There is of course the usual risk that
you can get two keys with the same hash (fingerprint), but since a key
has certain properties and a structure that can't be altered without
invalidating it, the risk is minimal, so in essense, you can
practically say that there's a 1:1 mapping between keys and their

Why do we depart from the wisdom of identifying keys with fingerprint?
It wouldn't harm monotone, since we already use hashes as identifiers
for a lot of stuff.


Please consider sponsoring my work on free software.
See for details.

Richard Levitte                         address@hidden

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]