GNOME Bugzilla – Bug 591027
Simplify key fetching
Last modified: 2012-03-15 10:18:33 UTC
The goal is to make key exchange so simple even my mother can use symetric encryption without explanation. Create a DBUS interface that simplifies it. Looking up keys for encryption takes the name, the mail-address (as much as the program has available, can be NULL). If a key is available, the id is returned. If there is no such key, the program will do a lookup and trys to find the key on the remote servers (using the most specific query first). It will download the keys that match automatically (if fewer than 5 or very specific matches) or display a box to select the keys if there is more found. The keyids of the found and imported keys will be returned over the dbus interface This must be configurable with gconf.
Symmetric encryption doesn't require key exchange, only a passphrase. There's already a DBus interface that fetches keys based on name, email, or id. DiscoverKeys What program would consume the interface you propose?
sorry for not being more exact. - I am only talking about asymetric PGP keys - The programs I have in mind are mainly mail clients. They have the information needed (username and mail address) - AFAIK DiscoverKey looks up keys based on the keyid. - I want to get as much logic as possible on the seahorse side of the interface. This would simplify implementation of public key crypto for everyone
Sorry, I meant MatchKeys. It might have to be modified to search remote keys if it hasn't already.
AFAIK Matchkeys does not remote lokup yet. For better identification, having different input parameters for names and mail addresses would help a lot. Example: looking for keys with the mail address thorsten.sick@something.de would result in better results than looking up for someone named "Thorsten Sick" The logic of seahorse should first try to find any key with this mail address and only if it finds non it should start to search for the name. And offer the results in a list afterwards for the user to decide. This process should be as invisible as possible. Normally neither user nor calling program should have to mind if the key has to be fetched from a server first.
The core problem that always gets stuck in the craw of 'simplicity' is: Trust. Just because you can fetch a key with an email address in it, doesn't mean you should use that key to send something to the user. It has to be within your web of trust or it's essentially useless and a gamble as to whether the owner of the email address is the same as the owner of the key.
Perhaps email clients need to implement a semi-automatic trust check in which the first time you try to contact someone with an encrypted message that isn't known to have a valid key, the MUA captures it and forwards a challenge email to the recipient, the recipient's mua would recognize it, grab the challenge string (hash or such) and encrypt and sign it back, at which point the sender's mua would prompt the sender for their passphrase to encrypt and if everything's kosher send the original message. The validity of the recipient's key could then be set to Marginal. Trust would still be set to unknown so that the sender wouldn't use signatures of the recipient to inform their web of trust. In the end, expanding your web of trust is the only way to be sure of someone's identity.
If it is ok I would post a bug in evlution to create a plugin that - sends a challenge to all untrusted keys (once per key) - the challenge contains a specified, parseable part - the challenge can contain plaintext explanation - the same plugin recognizes challenges and responds to them - returned challenges are checked and the trust is updated Do you suggest any other mail clients ?
I would suggest the enigmail extension for thunderbird. If evolution and thunderbird support the protocol, then it's a cross platform solution.
The bugs have been posted Enigmail: https://www.mozdev.org/bugs/show_bug.cgi?id=21374 Evolution: http://bugzilla.gnome.org/show_bug.cgi?id=591342 We can go back to simplify key fetching :-)
Maybe I will have some time on saturday to figure out how to do it. Do you have any ideas or wishes concerning a dbus interface for a call that does a lookup for a key on the default server(s), and displays the "choose your key dialog" if something is found. Or is enhancing MatchKeys the better way ?
I would enhance MatchKeys. It should probably be implemented in such a way that after MatchKeys returns, DiscoverKeys is called to import the key desired. For the dialog, I would use the CryptUI Key Chooser after turning the returned keys into a cryptui keyset. Let me know if you have any questions. Thorsten: We probably ought to look into getting you a GNOME Git account if you don't have one already. If you start the process, I'd be happy to be one of your sponsors. Cheers!
Hi Adam Thanks, this helps a lot. Now i know where to start looking. I will start commenting the source and find out if it possible (and elegant) to implement it that way. The DBus interface should be: - simple - offer a way for an application to add several keys at once - Keys should be added by at least keyid or email address - Pop up the window where the user confirms which key to import - Not pop up an other window Is this ok ? Any suggestions ? Git account: I am honoured. Thank you. I have no account yet. So long
(In reply to comment #12) > The DBus interface should be: > - simple Check > - offer a way for an application to add several keys at once DiscoverKeys does this already > - Keys should be added by at least keyid or email address This goes in the "pattern" field of MatchKeys > - Pop up the window where the user confirms which key to import This is something the calling app should pop up, not a DBus method. You can use widgets from libcryptui to make this easier. > - Not pop up an other window > > Is this ok ? Any suggestions ? You'll need to add a "remote-only" flag, 0x00000100 for instance. To search both local and remote sources the flags would be or'd together.
This is a good idea. But needs someone to implement it. I'm trying to change gnome-keyring bugzilla so it tracks actual work/bugs, rather than plans and ideas. Those are better suited for gnome-keyring-list@gnome.org until someone is ready to start implementation.