On 15 Mar 2011, at 00:26, Daniel Kahn Gillmor wrote:

(for some reason, my MUA thinks that this message from henry story may be a scam. it is not.)

On 03/13/2011 08:11 AM, Henry Story wrote:

...

If you had a global reliable distributed public key inscription/lookup service, then one could create URLs based on it so that boxes could be moved easily. Perhaps one could create such HTTP URLs based on the existence of such a service. call these httpk urls. The could look something like this

httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#fb

Without getting into the details, it sounds to me like you're proposing dropping human-meaningful identifiers entirely (and relying on the FOAF assertions to situate the opaque identifiers in a social context). This is an interesting approach, but it makes it difficult to mix between the online and offline worlds, i think.

At this point, I'd rather not comment on the specifics of whether to use HTML forms, what specific structure each datapoint should use, etc, because i think we don't have consensus yet on how we should handle the basics of the naming question.

If we give up on human-meaningful names, then yes, i think the rest of the puzzle pieces fall into place -- it's not terribly hard to come up with a distributed namebaddress resolution mechanism that covers a cryptographically-strong namespace. We can then use that address resolution mechanism to make requests about the rest of the related data (e.g. what human-memorable name each entity claims for itself, and what names other entities claim for it).

Revocations become quite permanent in that case (the name itself gets retired), and (it seems to me) it becomes difficult to refer cleanly and unambiguously to a specific entity in the offline world while online, and vice versa.

However, petname-style proposals (which i think includes the system Henry sketched here) implemented on trusted hardware allow humans to have some sort of private/non-universal human-meaningful name that they can apply to a given peer.

What do other people think of the consequences of this sort of tradeoff?

I'm assuming that people in this discussion are aware of the concept of Zooko's Triangle (whether you subscribe to it or not). If you haven't read about it yet, please take a second to do so:

https://secure.wikimedia.org/wikipedia/en/wiki/Zooko's_triangle http://zooko.com/distnames.html

Regards,

--dkg

I came across Zooko's triangle in a few recent posts by Dan Kaminsky, of which this one http://dankaminsky.com/2011/01/13/spelunk-tri/ In the e-mail you are responding to, I started with the idea of an httpk URL which I found to be a very useful one in helping me frame my thoughts. Its advantages and disadvantages are quite easy to see, and Zooko's triangle makes those clear. I then showed how if each server published the public keys/ip addresses for each of the servers it had fetched its TLS protected content from, one could have a system that used normal human readable names but could easily be mapped to secure URLS if needed. Or in other words: one could have a system where FreedomBoxes could work with the current DNS but also be alert to suspicious changes. One could work in both frameworks simultaneously. The question one would then have is what would a box do when the keys did not match? Perhaps just reduce the trust it put in information coming from a box, provisionally? It would have to be careful with the response being too strong, as this could lead to a form of attack that Bruce Schneier describes well: attack a system by creating many false alerts until the guards no longer pay attention to the alarm bells. Then attack. As far as how such a protocol would work, I agree it is way too early for that. The idea of a simple RDFa backed HTML form protocol was there to show that something like that could be built in an afternoon. Most of all the point was that we can build a Web based system on TLS and add these layers with time. They don't have to be built in from the start. Henry Social Web Architect http://bblfish.net/ _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE