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)
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.
Please see Multi-Device Pairing Considerations
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
should be sufficient, and that peers do not need to sync
last_seen. This has not been proved in practice.
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.
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.
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.
How does Autocrypt interact with webmail? Can we describe hooks for webmail and browser extensions that make sense?
Guidance for implementers on dealing with searching a mailbox that has both cleartext and encrypted messages. (session key caching, etc)
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.
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?
in Level 1, the Autocrypt recommendations for composing mail to a
remote peer with
prefer-encrypted set to
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
Documenting reasonable heuristics for MUAs to use in this case would be very helpful.