1755281 - UI for OpenPGP key acceptance per email address

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert [:KaiE:]]

We need improvements for managing a key's acceptance status, if the key contains multiple email addresses.

Today, the Thunderbird user interface implements a simplified model for accepting keys for email addresses.

Today, if a key lists multiple email addresses, we show all email addresses to the user. If the user accepts it, we will store the same decision for all combinations of {fingerprint, email address}.

If the key contains email addresses [e-mail] and [e-mail], and Bob knows that both email addresses belong to the same person, then our implementation is sufficient.

In a more complex scenario, it is insufficient. For example, a key could contain two email addresses for [e-mail] and [e-mail]. In this scenario, it could be an attempt by Eve to mislead Bob. Eve could have sent an email to Bob with this key, in the hope that Bob will accept the key. If Bob accepts it, then Bob might use this key to send an encrypted email to Dave in the future, using a key that allows Eve to decrypt the message.

Today, to be protected against this trick, Bob must carefully look at the list of email addresses when accepting a key, and reject the key if the additional email addresses seem wrong.

Ideally, our user interface could allow Bob to limit the email address Bob accepts. For example, Bob could be allowed to accept the key for Eve, but not accept it for Dave.

It is also possible that a new user ID (and email address) appears when automatically updating a key. For example, if we already have a key with a specific fingerprint imported, and we see a different version of the key in an email or in an online directory (keyserver or WKD), we automatically merge in the updated properties of the key. If this includes a new user ID, we will import it.

Today, Thunderbird already protects against the risk of accidentally using such an additional email adress, it will NOT automatically accept new email addresses.

E.g. if Eve initially sent a key with only [e-mail], then Bob accepted the key, then Eve sends an updated key with the additional email [e-mail], then the key will remain unaccepted for [e-mail].

Today, this will result in a confusing user interface. When showing the properties of an updated key, the user interface will the old acceptance decision and it will list all email addresses (old and new), even if the acceptance decision only applies to a subset of the email addresses.

The key properties dialog should be improved to show which email addresses are covered by the acceptance choice.

A very powerul user interface would offer a separate radio button list for each of the email addresses.

I'd rather suggest that we use a simpler implementation. For example, it might be sufficient to have a checkbox in front of each email address (user ID). The checkbox could say if an email address is covered by the acceptance choice. An email address that isn't checked would then be treated as "undecided" (it's undecided if this key is accepted for this email address).

Besides what I explained above, we are currently working on a new mechanism to accept keys, that will make this issue more visible.

In bug 1627956, we intend to implement a key assistant user interface, that allows Bob to accept Eve's key in a more convenient way.

It is an open question how the new key assistant will handle additional email addresses. We have two choices:

• show the additional email addresses, too (e.g. dave),
  and continue to require that Bob is careful and notices
  that the additional email addresses might be an attempt
  to trick Bob into accepting a fake key for Dave,
  and automatically accept the key for dave, too.

• only accept the key for the email address that the key
  assistant is currently helping with (eve, but not dave).
  This introduces a new scenario, in which the key
  properties dialog will show incorrect/incomplete information.

One aspect of this has already been reported in bug 1663925.
I'm filing this new separate bug developing a general solution that covers all aspects.

Comment 1

[Kai Engert [:KaiE:]]

(In reply to Kai Engert (:KaiE:) from comment #0)

It is an open question how the new key assistant will handle additional email addresses. We have two choices:

• show the additional email addresses, too (e.g. dave),
  and continue to require that Bob is careful and notices
  that the additional email addresses might be an attempt
  to trick Bob into accepting a fake key for Dave,
  and automatically accept the key for dave, too.

• only accept the key for the email address that the key
  assistant is currently helping with (eve, but not dave).
  This introduces a new scenario, in which the key
  properties dialog will show incorrect/incomplete information.

Currently our data model doesn't allow different acceptance decision by email address (same fingerprint).
If a key (by fingerprint) is accepted, and only one email address is accepted, the other addresses treated as undecided.

When designing the improvement, we also need to consider the following scenario:

• key DEF12345 lists [e-mail] and [e-mail]
• key DEF12345 has an acceptance decision (positive or negative) for [e-mail]
• assistant is used to help with [e-mail]

This scenario requires special handling, the user needs to be made aware of the existing key with the overlapping email address.

If the other email is a positive acceptance, then it must be said, that accepting the additional email address will reuse the same acceptance decision (either the default undecided, or the potential verified status).

Or, if the key was already marked as rejected for the other email, then it's not possible to simply accept it (it would undo the rejection for the other email).
I think in this scenario, the user must be required to go into key properties, and manually adjust acceptance/rejection and which email addresses are covered.

Comment 2

[Kai Engert [:KaiE:]]

In the key properties dialog, I suggest to show a checkbox next to each user ID:
[ ] ignore

By default, no ID is checked, no IDs are ignored.

If an automatic key update of an accepted key adds an additional user ID, those will be shown in the dialog with [x] ignore (checked).

If the key assistant accepts a key just for one email address, the other email addresses will be listed in the key properties dialog with [x] ignore (checked).

Note that any user ID needs this flag/checkbox, it needs to cover both the topmost user ID shown (alleged key owner) and also each of the entries in the "alleged alternative identities" list.

Comment 3

[Kai Engert [:KaiE:]]

To summarize, I think the following would be the implementation strategy with the least amount of work:

• add [ ] ignore checkbox for each user ID in key properties
• in key assistant, accepting a new key will be limited to the single
  email address, to minimize the risk of accidental decisions.
• in key assistant, if this key is already accepted for other email address,
  offer one click acceptance for this additional email address.
• in key assistant, if this key is already marked as rejected,
  do not offer the user to accept the key with one click
  (require manual resolving in key properties)

Comment 4

[Kai Engert [:KaiE:]]

The key properties dialog needs to be consider the scenario that multiple user IDs could refer to the same email address.

If one checkbox is changed, other checkboxes referring to the same email address must be automatically synchronized to get the same checkbox state.

Comment 5

[Kai Engert [:KaiE:]]

Attachment: Bug 1755281 - Manage ignored email addresses for OpenPGP public keys. r=aleca

Comment 6

[Kai Engert [:KaiE:]]

Tomorrow I want to attach screenshots and explanations.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/381ba5e4ad3e
Manage ignored email addresses for OpenPGP public keys. r=aleca