Re: [Monotone-devel] Re: SPKI/SDSI

[Nathaniel Smith]

On Wed, Feb 08, 2006 at 03:35:25PM +0000, Bruce Stephens wrote:
> Nathaniel Smith <address@hidden> writes:
> 
> > I've been reading RFC 2693 [ftp://ftp.isi.edu/in-notes/rfc2693.txt] to
> > prepare for CodeCon, so I can talk about plans for trust management
> > without seeming totally ignorant of relevant literature :-).  It's an
> > interesting read; I think there are enough differences in problem
> > domain to make it non-ideal for monotone, but it's a good basis for
> > discussion.  So, good thing to read (or at least skim) at some point
> > if people are interested in this stuff.
> 
> Also <http://www.crypto.com/trustmgt/kn.html> is interesting.
> 
> I must admit all these things feel like nifty technical solutions in
> search of too few actual problems.
>
> In theory I think there's lots of things you could do in a uniform way
> if everyone would just agree on one framework to use, but in reality
> almost all specific problems seem adequately (if not completely)
> solvable using simpler (if specific) solutions.  (And so long as
> there's no obvious winner, it's not worth anyone going with a system
> that really could do everything.)

I'm not sure what has held back SPKI uptake in practice.  The web site
actually suggests that nothing has, it's just that it's a set of
principles rather than a single spec that everyone has to implement,
so all the people working on SPKI are now just writing systems that do
what they need to, instead of trumpeting their adherence to SPKI
canon.

This seems like a feature; if you read that RFC, they lay out how to
interpret PGP keys, X.509 keys, etc., as instances of SPKI certs.
They seem very aware that any "solution" that requires universal
adoption is no solution at all, and to have at least attempted to
target their design to make this irrelevant.

Regardless, though, _this_ part is all irrelevant to monotone :-).

> My guess is that'll be so for whatever problems there are for
> monotone: it'll be not too bad to add one or two features, and now and
> again add an epicycle or two, and the immediate requirements can be
> satisfied.
> 
> As a specific example, get_revision_cert_trust would probably be more
> useful if it had access to all the certs for a revision.  I could
> imagine wanting to ignore tags other than my own on my own branches,
> and probably there are other examples.  Maybe similarly for
> accept_testresult_change.  

Personally, I'm pretty darn convinced that get_revision_cert_trust is
a dead end.  Especially it just doesn't provide any way to get one of
the most basic things you expect out of a VCS: some way for a core
group of developers can manage "commit" access (really cert trust and
perhaps push access).  _Everyone_ has policy on who can change what
how, and in practice telling every user to work out their own rules,
while flexible, is completely... well, just way too clunky to work
:-).

(If anyone disagrees, then could I ask you to volunteer to go around
and get everyone on a project to manually update their hooks the next
time someone joins the project?  Thanks ;-).)

We know how to solve this; the full design of SPKI/SDSI is way
overkill and not appropriate, but some of the basic principles are
useful to think about.  We basically think we know how to solve
monotone's problem (the "trust branch" idea, for those who remember
it), and it's basically just the technique in 7.7 of the above RFC
(though we came up with it independently), plus some monotone specific
gunk to make it fit in nicely.

The really nice thing about this chunk of extra architecture is that
it also gives you natural solutions for such things as:
  * key lifecycle (including retiring old keys and making new ones
    with the same name as the old one)
  * branch naming (and renaming)
  * a natural place for a project to store project-general data.  say,
    for instance, darcs's famous email-address-in-the-repo, so one
    could in principle say "monotone email-changes" and have local
    changes magically bundled off to the appropriate list.
and so on :-)

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."