Re: [Monotone-devel] branch naming conventions

[Daniel Carosone]

Naming is always interesting, and the source of many arguments :)

With respect to key naming, I agree entirely that the internal
representation of a key id should be based on a hash of the key
material.  Ascribing a name to a key should be done with certificates
- signed attestations by other trusted developers as to the correct
identity owning the key in question.  This is the beginning of the
identity trust mechanism we need.  That mechanism will need to be able
to handle revocation of the identity attestations, as well as
revocation and renewal of the underlying keys - potentially as
discrete cases so we can see which is happening.

Whether we use, borrow, or reimplement the gpg model, something
relatively close to it is probably required:
 - here's a big bucket of public keys
 - one or two (..) of these keys are Special, because they're mine and
   they correspond to private keys. These keys are identity (and,
   later, authority) trust roots.
 - here's a collection of certificates that make identity assertions
   about the keys. These assertions include at least one by each key
   for itself, and at least one by me, as a root, to get the ball
   rolling on the rest.
 - here's a mechanism by which I follow a tree of such assertions from
   a trust root to identities I consider valid.

This is very much like monotone works for revisions between the
database and a checkout: a big bucket of revisions, and a collection
of signed assertions about their validity that are tested before being
used.

Branch naming might work out very similar, too, if we wanted it
to. Each branch would need a unique internal id.  I can see a couple
of possibilities for how to come up with this id: a key, or a
revision.

 A key might then be used to sign a name cert for the branch, and
 perhaps some permissions certs allowing other keys to commit to the
 branch (implicitly giving a branch an owner).  This avoid having to
 give out the branch private key to all committers.  

 Using a revision would directly imply a branch point for the branch
 (which I'm not sure we need, but some people seem to want) and if
 we're not careful, only one branch-point per revision.  Otherwise, we
 might just use a random number. Either way, naming certs for the
 branch would then be established using developer keys and naming
 trusts, but we need a more complex way of delegating permissions
 certificates for commits to the branch.

For consistency with the rest of the system, perhaps the random number
is best.  Branch identities are then established the same as developer
identities, and both can have multiple names with different (trust)
scope.  As owner of my local database, I can establish a locally
trusted additional alias name for a branch (or a developer) to refer
to something named differently by others.

Oh, this reminds me: it would be an interesting idea to allow (all)
certs to contain a "local only" flag, which means they aren't exported
by netsync by default.  Could be a helpful tool to cut out a lot of
replicating noise; local testresult certs for example.

I also don't really have a problem with using branch names directly on
branch certs as we do now, apart from the renaming difficulty; the
RFQDN scheme deals well enough with accidental naming conflicts.  The
more significant issue with this right now is deliberate naming
conflicts.  Monotone's authority trust mechanisms aren't really up to
the task of dealing with injection of malicious branch certificates in
a usefully robust, distributed and user-friendly manner.

--
Dan

pgpDoPjGpEF75.pgp
Description: PGP signature