On 15/01/13 04:02 AM, Sean Lynch wrote: > On 01/11/2013 11:42 PM, ianG wrote: >> >> Question 1: would your application allow multiple keys per person? And >> if so, does this mean the app has to manage a petname across multiple >> keys, or does the user have to manage multiple petnames across multiple >> people? >> > > Multiple (Ed25519) keys would mean multiple identities. I suppose the > contact list manager could easily allow grouping multiple identities if > the user knows they're the same person, just like Pidgin does.
Yes, something like that, that is what I am tussling with now. A person with two accounts is still a person by most human-oriented worldviews. The person needs a petname and the 2 accounts need petnames as well. Then, there needs to be a grouping to relate them all. So, I have a petname grouping for my friend Bob's accounts, which might be the same petname as I have for Bob. Then, what happens when I (or my UI) discovers a new account from Bob? My UI should automatically add it into Bob's account group? Is Bob allowed to have to separate sets of groups? Separate personas? Gets messy very quickly. (I also have distinct contracts to worry about, which most people will not be bothered with.) BTW, why the keenness on Ed25519? >> Question 2: what happens when a user's PGP key / persona (however it is >> termed) is lost or compromised? >> >> I'm tussling with these issues at the moment. > > This is the standard key revocation problem. Revocation works in a PGP world where we simply dust off, create new keys and let all our friends know. To add another wrinkle, if the keys manage money or something else that is important like ones phone number, then losing the persona means losing more than comms, part of ones self. We need a way to get that context back. So key-agility becomes quite an issue. > Most likely I'd generate a > revocation certificate and store it (encrypted) on friends' computers, > along with your own, just like is the recommended practice for PGP. The > hard part is the UI, which should probably work similarly to Facebook's > report flow, Sorry, not in detail familiar with their report flow. All I know is what I saw in the film ;-) > possibly even just automatically revoking a user's key if > enough friends report their key as compromised, using quorum encryption. That's exactly what I was thinking :) But I am suspicious of the idea of crypto and quorums, too fanciful to work reliable. Still thinking about how to do this. It also implies that we need strong relationships between friends, enough to trust them to revoke. I'm not seeing Facebook as a good lead to follow there, but maybe I'm wrong? >>> When you start the application for the first time, it prompts you to >>> generate a public key or import one (it could be generated from a >>> password, but this has some problems associated with it). It lets you >>> put any metadata you want on the key, then connects to the network via >>> an included list of seed peers, or you could type them in yourself. The >>> application would then maintain a list of known reachable peers for >>> future connections. >> ... >> >> To echo James' comments, if you want ordinary users, you shouldn't ever >> expect them to use keys. Most ordinary users will run screaming on >> sight of a PGP key. > > Absolutely. The word I'd use would be "identity" or "account," never > "key". Ordinary users would never even know cryptography was involved. > For all they knew everything should be based on a central server. Yeah. I've used many words over time, none of them capture what we really need. Identity doesn't work because people confuse with their own identity, and the common question of "what's your identity" drags us into a minefield. 'Account' is probably the most accurate, but it is so widely used that it is easy to assume too much. OTOH, once people get used to the system, they tend to learn what any frequently-used term means. iang _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
