Parse incoming Autocrypt header, import keys
I spoke with people about Schleuder version 4, and stuff they would find helpful. Something people mentioned several times was better Autocrypt support, especially if Schleuder is used in a "frontdesk setup", with lots of different people sending mail to Schleuder, etc. To make this more easy, and to give people an option to get rid of boring, manual and repeated work, this is a proposal:
- Introduce a new per-list option to parse incoming Autocrypt header.
- If enabled, handle the
keydatafield, check the data in there, and if all good, import the key into the final keyring.
- Probably, checking the data in the field means importing the data into a temporary keyring, and checking the result.
- Add a new pseudo-header,
sender key status, with the result of the check and/or import as per above:
Not present - Key imported(if there was not key yet for this email addr, TOFU)
Already present - Key unchanged(if the key is already part of the keyring)
Already present - Conflicting Key - not imported(if a different key for this mail addr is already part of the keyring)
- Pending questions:
- Use a dedicated per-list keyring for these keys, similar to what MUAs are doing?
- Still, prefer the manual keyring, and only if no key is found there, fallback to the Autocrypt-keyring?
- Should a disctinction be made regarding sending to subscribers, vs. resending? That is: Should the manual keyring be the single source of truth to handle key lookups of subscriptions?
- As per the Autocrypt spec, AFAIK, MUAs do replace keys, if a key is already present on the local system and there is a new one received via mail. Do we want this? Or do we let people handle this situation on their own, as per above?
- Wording: Not really sure if I'm happy with
sender key status, maybe just
Autocrypt? OTOH, not sure if that's "too technical".
That's a first draft, happy to take any input, and to get this into something worth implementing.