1631198 - Allow manual import of autocrypt sender key

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert (:KaiE:)]

Although we don't claim to fully support Autocrypt, some OpenPGP correspondents might use Autocrypt, and the key in the header might be the only way to obtain their public key.

If a received message contains a key, we should make it discoverable, and allow the user to manually import it - similar as with other key attachments (where the user has to right click the attachment).

I have an initial patch, which displays an additional line at the bottom of a message, only if an autocrypt key is contained in the message. The line says "Message contains sender's OpenPGP public key" with an import button.

Comment 1

[Kai Engert (:KaiE:)]

Attachment: autocrypt-key-only.png

This is how it looks, if there are no other attachments.
Will need some UI styling fix to make it look prettier.

Comment 2

[Kai Engert (:KaiE:)]

Attachment: autocrypt-key-and-attachment.png

If there are additional attachments, it looks like this.

The line is hidden if there's no such key in the email.

Comment 3

[Kai Engert (:KaiE:)]

Attachment: Bug 1631198 - Allow manual import of autocrypt sender key. r=PatrickBrunschwig

Comment 4

[Kai Engert (:KaiE:)]

FYI, the change in rnp.jsm makes it possible to pass both ASCII and binary blocks to the RNP key import.

Comment 5

[Kai Engert (:KaiE:)]

Alessandro, this is just my initial hack. It's fine to display this differently in the future.
FYI, this is about a sender public key that is transported in a regular message header, and thereby invisible in the attachment list. This is the reason why I'm treating it specially.

In general, I could imagine a smarter mechanism for dealing with an OpenPGP key that's attached as a regular attachment.

Although a regular key attachment could be anything, including the key of someone else, or a list of multiple keys - we could try to detect if a regular attachment is indeed a single key belonging to the sender's email. If yes, then we potentially could hide that attachment from the regular attachment list, and display it in this way, too. But that would require some more work, which we'd have to do at a later time. So initially, it would be easier if we can handle regular attachments, and these "autocrypt header" keys differently.

Comment 6

[Magnus Melin [:mkmelin]]

I don't really think this message belongs at the bottom of the message, but I guess we can figure out how to display it better later.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/804e09a2b571
Allow manual import of autocrypt sender key. r=PatrickBrunschwig

Comment 8

[u617804]

This does not work for me, see bug 1689048.

Comment 9

[Kai Engert (:KaiE:)]

(In reply to Arvidt from comment #8)

This does not work for me, see bug 1689048.

It works for me as expected.
I've explained in bug 1689048 why we don't import that key - it isn't a key from the sender email.

Comment 10

[u617804]

Can confirm, that Autocrypt key from header can be imported from a real (so not from Autocrypt bot) email I received, where the key matches the sender's address.

Comment 11

[u617804]

P.S. What I have is a received email from mail provider posteo.de.
The sender sent me an encrypted and signed mail, with the sender's public key only as Autocrypt key, no attachment.
Since I had the sender's public key before, to test the import I deleted the key from the TB key store and restarted TB.
When then clicking on the received mail, I do not see the import notification shown in comment 1.
I only see the symbols for encrypted and signed mail (but signed with blue question mark, because unknown signer key), see screenshot.
Then I can click on that OpenPGP symbol button and then click on "import", and then the Autocrypt key is imported.

It would be better user experience if the import offering notification shown in comment 1 would show up here.

Comment 12

[u617804]

Attachment: OpenPGP button

Comment 13

[Kai Engert (:KaiE:)]

Please let's use new bugs for new discussions and request for changes.
I've filed bug 1749664 regarding comment 11.