[Freedombox-discuss] Identity UI

[Michiel de Jong]

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 <nick.m.daly at gmail.com> 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