This page is part of the web mail archives of SRFI 84 from before July 7th, 2015. The new archives for SRFI 84 contain all messages, not just those from before July 7th, 2015.
On Wed, 2006-02-01 at 11:39 +0900, Alex Shinn wrote: > On 2/1/06, Thomas Lord <lord@xxxxxxx> 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