Building a Vision for GnuPG

As part of the EasyGpg2016-contract we try to build a vision for the future user experience of GnuPG. This includes archetype users, some user stories and aspects how to evolve the existing certificate manager gui towards this vision.

This page started with results from a day-long meeting on the 20th of April at Intevation, Osnabrück. Participants were Andre Heinecke, Bernhard Reiter, Björn Balazs, Emanuel Schütze and Jochen Saalfeld.

Feedback appreciated, see contact points for EasyGpg2016.

Vision

Future GnuPG

With future GnuPG communication partners will typically exchange their emails and files confidentially. To achieve this, the effort needed for the user will be minimal and a number of security levels and compatible applications will be supported.

Comments:

• communication partners: All people even without any previous knowledge on crypto. See section archetypes for more details.
• typically: We are aware that we will not be able to reach 100% of the communication events and security demand varies between different users.
• confidentially: Means end-to-end encryption.
• minimal effort: We are aware that there will always be a small additional hurdle. We try to make it as small as possible to foster frequent use.
• compatible applications: Support by a larger variety of applications can only be reached by providing open standards and a Free Software implementation.
• To make this vision become reality, we want to introduce a handshake of the client with the mail-provider of the recipient, that will return the public key for encryption.

GUI / Kleopatra

Kleopatra (as example of an UI server and GUI) will be a crypto manager providing all the power features advanced users need to manage their confidential communication. Users with lower demands will not need to enter the full application, instead Kleopatra will provide contextual dialogues for the main applications (Mail, File Manager) to either allow crypto operations on files or emails or to gather the information needed to configure private communication.

Users

Trying to formalize the users of a project is always a difficult task. We have decided to go with what we call archetypes for now:

Tasks of the Users

Following some typical tasks of the users are described and how the interaction with future GnuPG will look like

T1: Sending Mail to one recipient

Description: Annika wants to tell her University that she is sick.

User:

• This task does apply to all users

Comments:

• University provides a look-up service for public keys
• Communicating about Sickness is a sensible topic and hence the communication about it needs to be encrypted.

Workflow:

1. Annika starts email client on her desktop
2. Annika selects her university identity to send mail with
3. Annika put her professors email address into the TO: field.
   1. Automatically the public key for that address is being retrieved. A little indicator represents the security estimation of that communication process (smart integration of Tofu, WoT, individual certificate verifications,...). She could click here in order to gain more information about this state and what to do in order to improve the security estimation.
4. She writes and sends her mail as usual.

Remarks:

• This process in its ideal form does not require any more steps than sending usual, not-encrypted email.
• Users should be able to configure the behaviour if it is not possible to send an encrypted mail (e.g. send anyway, ask, wait for some time before being able to send)

T2: Communicating with a non-crypto user

Description: John wants to communicate safely with a potential whistle blower.

User:

• This task does also apply to all other users.

Comments:

• We assume the new contact has no key-pair yet.

Workflow:

1. John starts his email client on his desktop
2. John chooses the right identity to send with
3. John enters the email-address in the TO: field
   1. The system now searches for a public key, finds none and indicates this directly on the TO: field
4. John now enters the rest of the mail and presses "Send"
5. The system feedbacks to him, that it is not able to send encrypted (because John has defined this in the settings), why this is so and offers the following:
   1. Inform the communication partner how to set-up encryption:
      1. Send a mail with instructions
      2. Webpage with instruction to communicate via some other form (Telephone, Jabber, ...)
      3. White list this recipient as someone to not communicate encrypted to
   2. Define what to do with this mail:
      1. Send not encrypted
      2. Save
      3. Send as soon as a key is discovered
      4. Discard the current mail

Remarks:

• The standard behaviour when trying to send to someone without cert has to be defined. For Erna e.g. it will be sufficient to send anyway, without asking
• The white list of non-encryption partners needs to be configured. Ideally, the system searches for keys to the partners anyhow and asks to remove them from the white list, when a public key is being found.

T3: Create a new mail account after having received crypto instructions:

Description: Ernst wants to leak and discuss a memo with John.

User:

• This task does also apply to all other users.

Comments:

• Ernst got an URL from John about how to setup crypto.
• So he cannot that easily be tracked, Ernst has bought a new computer.
• He has access to the Internet and just applied for a gratis email account.

Workflow:

1. Following the instructions he now installs Thunderbird and Enigmail.
2. He starts and follows the normal setup to access his new mail account
3. After the "normal" mail setup, the dialogue asks him whether he wants to import his keys or create a new key.
4. He chooses new key, as he has none. The keys get generated and he gets asked to choose a password to protect his key.
5. (Maybe) he gets instructions how to backup his key and gets asked to upload his key so others can communicate safely with him.
6. He is now ready to communicate with John.

Remarks:

• It seems to be reasonable to make the set-up process even slicker. Neither passwords or a backup of key has to be done in this step. It might be a good idea to simply prompt the user with these tasks after having used crypto a couple of times. This advantage would be to even lower the barrier to start with crypto.

T4: Installation of GPG4Win / Kleopatra

Description: Annika wants to install software to encrypt her communication.

User:

• This task does also apply to all other users.

Comments:

• She has found some manuals, pointing her to install Gpg4win

Workflow:

1. She download Gpg4win and start the normal installation
2. During the installation the system shows her the new actions she can do with Gpg4win installed, namely file-actions and email actions.
3. After successful installation of Gpg4win she can
   1. Quit the application
   2. Watch a video (?) that explains the main terms of encryption to her
      1. After watching the video she is asked to create or import her own keys (see T3)
   3. Import her keys.
   4. Last option would be to start Kleopatra.

Remarks:

• When she stops the configuration before key creation, the corresponding dialogues will be prompted once she initiates an action that requires some input from her (e.g. she wants to sign something)
• There should not be any need to start Kleopatra itself. All configuration should be done via external dialogues (compare T3)

T5: Configuration of an additional device

Description: John buys a new smartphone and wants access emails in parallel to his laptop.

User:

• This task does applies to all users, but is not equally important. Maybe Ernst or Erna can just initiate a completely new installation and can disregard old settings, devices or data.

Comments:

• Technically all devices need to have access to the same private key.

TODO

Some corner cases

• What should happen if not all recipients possess keys / the same kind of keys?
  • Don't send
  • Only send the encrypted mails
  • Send all unencrypted
  • Send different mails encrypted and unencrypted
• How to solve when more than one certificate is being found?