[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
politics etc. (usual top-posting apology)
Thanks, Alex. Rather than reply point-by-point here's this:
In GNU Arch 1.x we have, I claim, decentralized + human-readable +
secure names. The design has some imperfections so I won't defend it
in every detail. It basically works, though, and suggests a paradigm.
I'll describe the paradigm in idealized terms so as not to get hung up
in the flaws in Arch.
We again start with the idea of an infinite tree-topology
name-space in which ownership can be assigned (recursively)
/ | \
/ | | | \
names and sub-authorities
To be decentralized we must allow authorities to self-nominate.
To be secure, that self-nomination must be based on a public key.
To be human-readable, we can not (normally) use the text of the
public key itself as the name of an authority.
By convention -- community sentiment -- we start with a generative
grammar for human-readable names with the property that it is easy
for people to make accidental collisions unlikely and malicious
collisions clearly apparent as such. The current SRFI-84 draft does
such but also goes further (too far?) by creating specially
privileged top-level authorities and by failing to allow people to
self-nominate as new authorities without paying perpetual tribute to
the privileged authorities.
By standard, define a way for self-appointing naming authorities to
issue certificates which bind public keys to names within the
context. Of course there may arise contention, though in practice
there is little legitimate need for such. When contention arises,
we fall back to the community sentiment to form a consensus about
which competing claim is true. The role of crypto here is simply
to give the community an objective basis on which to recognize and
discuss the contention.
As a pragmatic matter, communication falls into the classes
"formal" and "informal". Where formal communication is called
for, certificates are explicitly referred to and tools are available
to see that they are applied correctly. In informal discourse,
the human-readable names enough. In other words, in talking at
the conference on software for missile launching I'll just say
`foo:bar' and people know what I mean. But in the paper in the
proceedings and in the link-loader for my software -- I'll use
the keys, thank you very much.
It turns out that some folks are way ahead of us on systems like this.
This paper is well written and appears to be a good entre to the
If we accept the general thrust of what I'm saying then we can ask
about the proper form and function of this SRFI. Should it say
anything about certificates? Should it privilege some short-hands
I've got my own opinions about such questions but I'm not terribly
interested in trying to argue anyone into them. I'm content to
raise contextual awareness and to be seeing some contemplation of the
issues going on.
p.s.: one last thing that doesn't quite fit into the above but
responds to Alex:
Yes, there is a difference between securing the named thing,
securing the binding of name to name thing, and securing the
I'm interested here in the issue of securing the name itself --
in other words, allowing a decentralized yet secure process
to create new nouns and refer to those nouns unambiguously.
The binding problem (names to meaning) and ontology thing
(identities of the named things) are separate. Securing
names seems to me a prerequisite, though, for solving the
binding and identity problems.
What a mouthful. I need a gin an tonic. Mmmm.... `Quine'ine.
:-) (Sorry. ;-))