Future Enhancements to Autocrypt¶
Please see Autocrypt Level 1: Enabling encryption, avoiding annoyances for information about Level 1 requirements. Here, we document future improvements, which we hope will be incorporated in Level 1, or possibly some later Level. This is an unordered list. If you have ideas about how to address one of these points, feel free to jump in! (but let’s try to stay focused on getting Level 1 stable before we invest too much energy in these next steps)
Expiry¶
Todo
We need documentation about sensible key expiry policies. Autocrypt-capable MUAs that choose to have an expiry policy on their secret key material should use message composition as an opportunity to refresh their secret key material or update the expiration dates in their public certificate.
Client sync¶
Please see Multi-Device Pairing Considerations
Todo
We need to specify how to sync internal Autocrypt state between
MUAs. We want to be able to sync the state without sending sync
data for every message processed, while we also want all synced
peers to have the same internal state as much as possible. We
currently believe that syncing updates to pah
and changed
should be sufficient, and that peers do not need to sync
last_seen
. This has not been proved in practice.
New Types¶
Todo
how to deal with multiple types (at least when a new type is specified). When we support types other than 0, it’s possible that users will have multiple keys available, each with a different type. That seems likely to introduce some awkward choices during message composition time, particularly for multi-recipient messages.
X.509 and S/MIME¶
Todo
Someone is bound to ask for this as a “key type”
Deletable (“forward secure”) encrypted mail¶
Todo
Given the Autocrypt infrastructure for key exchange, there’s no reason we couldn’t define a mechanism for pairwise, ratcheted, session-key establishment for e-mail. See <https://github.com/autocrypt/autocrypt/issues/444>
RSA3072 to Curve 25519¶
Todo
Document change in preference for keys from RSA 3072 to Curve 25519.
Backups¶
see Autocrypt Secret Key Backup
Todo
We need guidance on how backups might be done safely.
Guidance on masking Key IDs¶
If any recipients are in Bcc: (rather than To: or Cc:), and the keys used are all OpenPGP, then the MUA SHOULD mask the recipient key ID in the generated PKESK packets that correspond to the Bcc’ed recipents. It does not need to mask recipient key IDs of normal recipients.
Masking of Key IDs is done by setting the key ID to all-zeros. See
the end of section 5.1 RFC 4880 for more
details. Users of GnuPG can use the --hidden-recipient
argument to
indicate a recipient who will be masked.
This is so that the message encryption does not leak much additional metadata beyond what is already found in the headers of the message. It still leaks the number of additional recipients, but the additional work and usability issues involved with fixing that metadata leak suggest that it’s better to leave that to a future level.
Encrypted headers¶
Todo
Document interaction with encrypted headers: if something like Memory Hole ever makes it possible to hide normal To: and Cc: headers, then we need to rethink our approach to handling PKESK leakage further.
Webmail¶
Todo
How does Autocrypt interact with webmail? Can we describe hooks for webmail and browser extensions that make sense?
Search¶
Todo
Guidance for implementers on dealing with searching a mailbox that has both cleartext and encrypted messages. (session key caching, etc)
Gossip (or “introduction e-mails”)¶
Todo
Can we specify a sensible practice for passing around keys for other people that we know about?
Or maybe it’d be simpler to define a standard workflow for “introduction e-mails”, where the sender tells multiple recipients about the keys she has for all of them.
Out-of-band key verification¶
Todo
Can we specify a simple, user-friendly way that Autocrypt users can confirm each others’ “Autocrypt info” out of band?
If we do specify such a thing, what additional UI/UX would be required?
Heuristics for dealing with “nopreference”¶
Todo
in Level 1, the Autocrypt recommendations for composing mail to a
remote peer with prefer-encrypted
set to nopreference
look
very much the same as the recommendations for when
prefer-encrypted
is set to no
. But different heuristics
could be applied to the nopreference
case for MUAs that want to
help users be slightly more aggressive about sending encrypted
mail.
Documenting reasonable heuristics for MUAs to use in this case would be very helpful.