#232 Allow GPG/PGP fingerprints in "To:" and (possibly) "CC:" and "BCC:" fields

[rysiek]

Allowing users to input GPG/PGP fingerprints in "To:", "CC:" and "BCC:" fields seems like a good idea -- the work-flow of using GPG/PGP of a new contact instantly simplifies to:

• just input the fingerprint into one of these fields, all the rest will happen under the hood;
• in case there are several identities under this given fingerprint, just let user choose.

This also offers instant verification of the key -- the user has to input the fingerprint, hence we can already be sure that the fingerprint is correct (assuming the user got the fingerprint from a verified source), instead of requiring the user to input the e-mail address and then verify the fingerprint additionally.

Broader context and rationale are also available.

[Ludwig Hügelschäfer]

Sounds nice :-)

One thing to cover is backward compatibility. For existing V4 keys (which is the majority) you can extract the key Id easily from the fingerprint and then download the key if it is not available locally. However, this is NOT possible for older V3 keys, some of which are still in use. Key Id and fingerprint aren't related and you're stuck.

[rysiek]

Are v3 and v4 fingerprints easily distinguishable? If so, when the data turns out to be a v3 fingerprint, just ask the user to give the e-mail address, too. Then (in the background) download the key(s) associated with the e-mail address from a keyserver, verify if the fingerprint matches.

If it does, we're home; if not, inform the user of the problem.

[Ludwig Hügelschäfer]

Yes, the fingerprints differ in length: v3 are 32 hex digits and v4 are 40 hex digits.

[Patrick Brunschwig]

Do I get your feature request right - your idea is roughly he following:

1. you type a fingerprint, and Enigmail tries to match it to an existing key.
2. If the key is not found, Enigmail tries to download it from a key server. If the key is found, Enigmail will just use it.
3. Enigmail will sign the downloaded key, such that the key can be used.
4. Enigmail enables encryption to the key IDs found and replaces the key IDs with the email address(es) taken from the key.

[rysiek]

More precisely, it would be:

1. type-in (or paste; or retrieve from a QR code reader, etc) the key fingerprint into the "To:"/"CC:"/"BCC:" fields
2. if the key is not found, Enigmail tries to download it from a key server; if the key is found and trusted, Enigmail will use it
3. in case the key is downloaded, or found BUT not trusted, Enigmail asks the user to confirm that the e-mail associated with the key is the one they want to send e-mail to; in case of several e-mails/identities connected to a given fingerprint, the user should be able to choose the one to be used;
4. when the user selects/confirms the ID, Enigmail marks the key as trusted (but as minimally as possible) for future use;
5. Enigmail enables encryption to the key ID found and replaces the key ID with the e-mail address confirmed by the user.

The main use-case being: user gets both key AND e-mail in a single exchange, for example on a business card; if the user is instructed to use the key instead of the e-mail as an "information account number", and then are asked by Enigmail to confirm the e-mail, we can assume minimal trust has been established (as the user presumably got the business card with the data physically from the person they want to communicate with).

By inverting the usual process (type-in key, THEN get and confirm the e-mail, instead of the other way around) we get the user to pay close attention to the more complicated (and important) part: the key; and get an easy and quite good confirmation with something easily recognizeable by the user: the e-mail address.

This would, of course, be only an optional process -- if the user types-in the e-mail, nothing changes.

[Patrick Brunschwig]

I'm ready to accept a patch for this, but I won't work on this. I think this offers only marginal benefit.