On Wed, 2006-02-01 at 11:39 +0900, Alex Shinn wrote:
> On 2/1/06, Thomas Lord <xxxxxx@emf.net> wrote:
> >
> > In GNU Arch 1.x we have, I claim, decentralized + human-readable +
> > secure names.
> [...]
> > We again start with the idea of an infinite tree-topology
> > name-space in which ownership can be assigned (recursively)
> > to subtrees:
> >
> >                 community-sentiment
> >                   /      |      \
> >                top-level authorities
>
> This is an interesting compromise, but I wouldn't call it secure.  As
> soon as you leave something up to "community sentiment," you've lost
> security, as there's nothing stopping people from creating their own,
> conflicting top-level authorities.  Further the model itself doesn't
> guarantee that each top-level authority itself is secure.

Um....

Community sentiment is the only thing available to hold up SRFI-84.
That's what the top level is.   The community has to agree to use
a SRFI, or a particular hash function, or an ICANN governed
internet, or faith in the coherence and trustworthiness of the
RnRS process, or.....    Community sentiment is the root of any
proposal you care to put forward --- I just happened to make that
explicit.

I didn't make it explicit just to be pedantic:

That community sentiment -- that rough consensus -- can be usefully
extensible, forkable, mergable, etc.   For example, it could be
extensible by saying we trust the community to perform ongoing
consensus forming around certificates.   Suppose that I say:

     tom-lord-of-gnu-guile-fame:

is the root of a name-space which is mine (all mine, bwahaha) and
publish a certificate advertising a public key for that name-space.
People can individually accept or reject that declaration.  To
the extent there is community spirit, it might become commonly
accepted and even reported in a trusted summary on schemers.org.
If my evil twin in East Buttfudge, PA makes a competing claim
to the name, at least the community has rigorous mechanism for
speaking precisely about the debate.

In the end, each end-user of names can have their own little
database of the name->key mappings they believe in.   You
could kinda run the Internet this way --- everyone could have
a file of domain names which they edit freely;  people could make
peer-to-peer arrangements to share that effort.   We could dub
this HOSTS.TXT.   Of course, if Scheme got so important that
grandma had to have her own copy of this file and, anyway,
there'll be a lot of easily duped people unqualified to maintain
themselves we might be tempted to create a central authority
to keep things simple -- but on the other hand, maybe with good
tool design we can avoid that quagmire.

SRFI-84 might do very well to just clean up the language
a bit -- to note some of these matters;  to not convey
special authority on the owners of a particular domain
or members of a particular committee -- to emphasize that it
is just a particular generative grammar (maybe a bit simplified
relative to the current draft) and call for later SRFIs to
elaborate.

SRFI-84 might do *much better* by boldly venturing into a
conservative certificate design and explicitly allowing
people to claim name-spaces that way.   That would at least
give tool builders something interesting to work on :-)

> The hypothetical situation posted earlier was exploring what would
> happen if we tried to build a trusting, decentralized system of
> executing code, and signed and secured everything to the best of our
> abilities - with the exception that the module names themselves had no
> verification mechanism by their original design.

I acknowledge that that was explored but I don't think it was explored
very far.

> The conclusion was
> of the sort of blinding obviousness that so often gets overlooked when
> such systems are designed - if you refer to external modules only by
> name, and those names themselves are not secure, then there is room
> for attack.  The anecdotal doctor anecdote says "don't do that then."

It's more subtle and I don't think you can ignore the role of community
in managing such risks.

-t