Hi Nick, Sorry if i confused the discussion by bringing in the keys of other people and the way you log in. We have to be aware though of which decisions have which dependencies.
Let's start from the assumption that the freedombox allows you to communicate using public/private key pairs for identity. As you say, there can be a many-to-many relationship between key pairs and people. On Sun, Jun 24, 2012 at 2:33 AM, Nick M. Daly <[email protected]> wrote: > When we do tackle key management, the key could exist on the remote box > alone and the user could log into the box, unlocking the key there. Good, i think that is indeed the only option. So each freedombox can host a number of key pairs. When you log in as your user, you choose one or more of the keys your user has access to, and start communicating. I agree that managing your own key pair is a separate issue from managing your peer's key pairs, but we need to make sure that multiple freedomboxes can interoperate with each other in a meaningful way. Having an identity only makes sense if you can communicate with peers (who themselves also have an identity). When there is an incoming message, it will be addressed at one of the key pairs. It will also come from a keypair which may or may not be connected to more than one entries in your addressbook. When you want to send a message, you probably choose the contact you want to send the message to, and if that contact has more than one key pair associated, then these will have to be labeled (e.g. 'home', 'work') so that the user can choose. Now I would identify the following dependencies, i.e., things we need to implement as a result of the assumption that identity will be based on asymmetric cryptography: 1) If there are no key pairs associated to an addressbook entry, then you cannot communicate with that person. This means we need some sort of friend requests in the UI, correct? 2) If your identity lives on your freedombox, then your house becomes very easy to find, so 100% of traffic over Tor becomes a requirement then, correct? 3) If you're not at home, you still want to use your identity, so you need a usable way to contact your freedombox from anywhere. This means the freedombox needs to come with a DNS domain name, correct? 4) When you contact your freedombox from outside your home, you want to do so over https. This means the freedombox needs to come with an SSL certificate that's supported (without ugly warnings) by all major browsers, correct? 5) We cannot assume people have a static IP address pointing to their home, so we'll either have to run a dynamic DNS service, or a reverse proxy service like pagekite. Otherwise we will not have a way to route the domain name to the freedombox, correct? Don't get me wrong, I'm not saying we should not base identity on asymmetric cryptography. I'm just saying we should identify (no pun intended ;) the dependencies we're committing ourselves to by making that decision. I don't see how we can do key-based identity without committing to all of these 5 points, but i may have missed something. Please correct me if i'm wrong! If we can get a consensus on this sort of design issues, then we can put them on the wiki, and get closer to having the actual freedombox design decided on in a way that's consistent with itself. Cheers, Michiel _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
