Signing Emails to Non Delta Chat Users

Background

When I send emails to anyone, I always sign them using my OpenPGP public key (unless there is a good reason not to do so). This has the dual purpose of allowing future verification of the email and its attachments, should that ever be important, but also to bring into people’s mind the fact that encryption and cryptographic signing of emails is something that is available and can be done (the majority do not even think of it, probably because they are not meant to think of it).

It would remain practical in terms of user time and email size to sign emails to non-Delta Chat users, even if having to enter one’s password, because one does not normally send lots of very short messages to non-Delta Chat users.

Proposed behavior

Allow optional (per message) signing of unencrypted emails to non-Delta Chat users, by adding, for example, a “Sign” checkbox on the message compose window.

Allow, as an application-level option, the choice of signing such email messages with either one’s external OpenPGP key or the key used by Delta Chat.

Possible Issues

Would there be any reason (besides time and resources, of course) that Delta Chat might not wish to add the optional ability to sign outgoing messages to a non-Delta Chat user, with either (a) one’s normal OpenPGP key (i.e., not the Delta Chat one, therefore requiring password entry); or (b) the Delta Chat key (not requiring password entry)?

A possible issue (particularly with option b) is that one would also need to either attach the public key to the outgoing message, and/or publish the public key on public keyservers.

Another possible issue is that a brief (one-liner?) notice would need to be added to the outgoing message to inform the recipient that the email is signed.

Current behavior

An email to a non-Delta Chat user is always sent both unencrypted and unsigned.

Delta chat code contains reference to this post in the comments: https://k9mail.app/2016/11/24/OpenPGP-Considerations-Part-I.html

Yes. There are some significant flaws in that post, but essentially it boils down to:

  1. Low perceived utility (really a time and resources issue)
  2. Programming complexity (time and resources issue)
  3. UI complexity (non-issue, because it would be an opt-in feature)

In the end, different user groups want different features.

No, that is not true, although both sides must support Autocrypt. Assuming that it is enabled, at the beginning, two messages to a new contact are sent unencrypted but with the public Autocrypt key included, to test if things could work out well. Afterwards, all messages sent to that contact will be encrypted. Of course, that does not cover signing of messages.

Thanks for the clarification, Gerry. I had forgotten about other Autocrypt clients. I guess I was meaning “garden variety” MUAs and average Joe email user, which is what I have been dealing with so far.