Multi-Device Pairing Considerations¶
types of inter-MUAA unicast messages¶
Difficult to reason about when we don’t know what we really want to do (cryptographic protocol wise)
Some authenticated key exchange so later messages between MUAAs can be encrypted
Shared private key so messages encrypted to the account’s public key can be encrypted and outgoing mail can be signed
remote key updates¶
notify other MUAAs that you add to or change an entry to your keyring
Why not use IMAP METADATA instead of specially-named folders?
We ultimately want Autocrypt to be more generic than IMAP, to make it clear how other mail-checking protocols could work (e.g. MAPI, webmail interfaces) as long as they offer some sort of namespaced shared storage. Using IMAP METADATA would tie Autocrypt more tightly to IMAP, and would also limit the number of IMAP implementations that Autocrypt-enabled MUAs could connect to (METADATA is not widely supported by today’s IMAP server implementations).
If we wanted Autocrypt to use METADATA where it was available on the server, but allow for fallback to normal folders for IMAP servers that don’t support METADATA, then we’d be adding an implementation requirement for MUAs that might not already know how to use the METADATA extension, which makes adoption harder.
And without initially requiring it for MUAs, we don’t see a way to transition once non-METADATA capable MUAs exist in the wild, either, since lockout and sync become difficult to do. So we don’t see a good story for METADATA deployment, sadly, despite it targeting our use case fairly neatly.
See also earlier discussion about IMAP METADATA.