Merge pull request #283 from Coffey-Labs/roadmap-smime-reasoning

Say why S/MIME rather than OpenPGP, and why neither is urgent
2026-09-04 13:31:13 -07:00
parent eca8468d84 0df62e6b2f
commit 1f9c17ad18
1 changed files with 6 additions and 0 deletions
@@ -16,3 +16,9 @@ See [KNOWN-ISSUES.md](KNOWN-ISSUES.md) for what is built but worth knowing about
 - **Right-to-left languages.** Arabic, Hebrew and Persian are held back deliberately, and not for want of translators. RTL is bidi and layout work throughout — mirrored panes, gesture directions, icon sides, the message list's own geometry — and a catalogue without it produces a page that is translated and unusable. Adding one is not another entry in the picker.
 - **Two-factor sign-in.** Today an account with 2FA must use an app password (see [Quick start](README.md#quick-start-docker)), and Settings › Security offers no way to switch 2FA *on* — only off, for an account that already has it. Supporting a TOTP code directly means implementing OAuth: Stalwart offers the authorization-code and device flows and no password grant, so ihasmail would hand sign-in to Stalwart's own login and come back with a token. That is a better security posture than the sealed password it holds now — a refresh token rather than a credential — but it replaces ihasmail's own sign-in page for those users and may need an OAuth client registered. Came out of [#75](https://github.com/Coffey-Labs/ihasmail/issues/75), which is closed: what was reported there was a sign-in refused with nothing but "Invalid credentials", and that was fixed by saying what is actually happening and pointing at app passwords. The OAuth work it uncovered is tracked here rather than as an open issue, so there is no ticket to watch for it.
 - **S/MIME.** Backlogged, to be built when it is feature-ready — not refused. It is on this page rather than in the tracker because nothing is in progress and there is no ticket to watch, and it is written down at all because until now it existed only in conversation, which is the state a plan is in just before it is forgotten. [PR #67](https://github.com/Coffey-Labs/ihasmail/pull/67) is the starting point: a working public-key manager over Stalwart's `x:PublicKey` registry, built and then closed unmerged on 2026-08-26. Nothing of it is in the tree today. What the probing behind it established, against a live Stalwart **0.16.19** on 2026-08-26 and not re-run since the 0.16.20 upgrade: `encryptionAtRest` is a *field on* `x:AccountSettings` beside `description`, `locale` and `timeZone` — there is no `x:EncryptionAtRest` object, whatever the docs suggest — it is self-service with no administrator involved, taking `Disabled` / `Aes128` / `Aes256` plus `publicKey`, `encryptOnAppend` and `allowSpamTraining`; ordinary users can read and write their own `x:PublicKey` entries even though Stalwart's permissions table lists every `sysPublicKey*` permission as admin-only; and Stalwart parses key material itself and returns a precise complaint, so a client should surface the server's message rather than invent one. **The design caveat that has to be got right before any encryption UI ships:** turning encryption-at-rest *off does not decrypt what is already there*. Enabling it is a one-way door — every message delivered while it was on stays encrypted on disk, readable only by a client holding the private key. That is a property of Stalwart rather than a policy choice, and it is the part a user cannot undo by changing their mind.
  **Why S/MIME rather than OpenPGP, and why neither is urgent.** End-to-end encrypted mail never reached the mainstream and is not on its way there: as a share of the world's email, PGP-encrypted messages are a rounding error, and the most successful use of OpenPGP is signing packages rather than sending mail. The reasons are structural rather than a matter of better tooling. Everyone in a thread has to take part, so the network effect works against it from the first reply. Key discovery was never solved — keyservers were unauthenticated and got weaponised in the 2019 certificate-flooding attacks, which made specific people's keys unusable by any client that fetched them, and WKD is better without being universal. There is no forward secrecy, so one compromised key retroactively opens everything ever received. The metadata stays in the clear: subject lines are cleartext in classic PGP/MIME, and who corresponded with whom is often the sensitive part. Losing a key loses the mail permanently. And it breaks the client — no server-side search, degraded spam filtering, awkward on a phone — while EFAIL showed in 2018 that the clients themselves were exploitable through MIME and HTML handling. Meanwhile the actual privacy win arrived invisibly and without anyone participating, in STARTTLS, MTA-STS and DANE.
  So if one of the two gets built here it is S/MIME, because it is the one that is *more* deployed in the places that pay for software: native in Outlook and Apple Mail, and routine in defence, healthcare, finance and government, where a CA issues and revokes certificates that an IT department can actually administer. The web of trust never became something anybody could run at scale.
  Expect the asking to be far out of proportion to the using. A self-hosted webmail for Stalwart draws self-hosters, privacy-minded users and European SMEs, which is about the densest concentration of PGP users left alive — so this will be requested much more often than it would be used, and that is an argument for keeping it here, described honestly, rather than either building it on the strength of the requests or refusing it outright.