After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591027 - Simplify key fetching
Simplify key fetching
Status: RESOLVED INCOMPLETE
Product: seahorse
Classification: Applications
Component: general
2.26.x
Other All
: Normal enhancement
: 2.26.0
Assigned To: Seahorse Maintainer
Seahorse Maintainer
Depends on:
Blocks:
 
 
Reported: 2009-08-07 05:01 UTC by Thorsten Sick
Modified: 2012-03-15 10:18 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Thorsten Sick 2009-08-07 05:01:48 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.
Comment 1 Adam Schreiber 2009-08-07 12:48:32 UTC
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?
Comment 2 Thorsten Sick 2009-08-07 16:01:44 UTC
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
Comment 3 Adam Schreiber 2009-08-07 16:11:43 UTC
Sorry, I meant MatchKeys.  It might have to be modified to search remote keys if it hasn't already.
Comment 4 Thorsten Sick 2009-08-07 17:50:22 UTC
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.
Comment 5 Stef Walter 2009-08-07 18:32:01 UTC
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.
Comment 6 Adam Schreiber 2009-08-07 18:46:38 UTC
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.
Comment 7 Thorsten Sick 2009-08-10 05:17:52 UTC
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 ?
Comment 8 Adam Schreiber 2009-08-10 12:17:39 UTC
I would suggest the enigmail extension for thunderbird.  If evolution and thunderbird support the protocol, then it's a cross platform solution.
Comment 9 Thorsten Sick 2009-08-10 15:54:04 UTC
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 :-)
Comment 10 Thorsten Sick 2009-11-17 21:53:34 UTC
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 ?
Comment 11 Adam Schreiber 2009-11-18 00:10:24 UTC
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!
Comment 12 Thorsten Sick 2009-11-18 21:39:49 UTC
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
Comment 13 Adam Schreiber 2009-11-19 01:02:51 UTC
(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.
Comment 14 Stef Walter 2012-03-15 10:18:33 UTC
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.