PGP/SMIME?

[frenzybiscuit]

What's the status on PGP/SMIME support?

I know it's not like widely used by people but considering stalwart supports it out of the box it would be nice to see integration in this project.

I do see it's on the roadmap, so fingers crossed!

[ma2t]

Honest answer: it's on the roadmap but not in the next two releases. 1.6.0 is search correctness and 1.7.0 is the unified inbox, both driven by the volume of requests.

For encryption there are two different things people ask for under this title:

1. Encryption at rest. Stalwart does this server-side today (S/MIME based, AES-256 for stored mail as of 0.16.11), and it needs nothing from the webmail. If your threat model is "the disk", configure it on the server now.
2. True end-to-end OpenPGP in the client. That means key management in the browser, a heavy dependency, and a lot of UX for failure states. I want to do it properly rather than bolt it on, which is why it keeps its "planned, not scheduled" status.

If you have a concrete setup in mind (existing keypairs? WKD discovery? signing only vs full encryption?), describe it here. Real requirements will shape the design spike when it starts.

[frenzybiscuit]

Yes that is my goal.

I use stalwart and have the key on the server. But in order to read the email the client must be able to decrypt it with the pgp key.

I only care about that aspect tbh

[ma2t]

That clarifies it, thanks. One important detail though: Stalwart holding the key server-side lets the server encrypt at rest, but it does not let the webmail read your encrypted mail. To show you the plaintext, the client has to decrypt in the browser, which means your private key (or a way to use it) has to be available client-side. So "read my PGP mail" is really the client-side OpenPGP track, not something the server encryption solves for the client.

Concretely that means importing your private key into the browser (kept in memory or wrapped in storage, never sent anywhere), decrypting after fetching the raw MIME, and a clear signature-validity banner. It is real work and I want to do it without a heavy always-loaded dependency, so it stays planned rather than scheduled behind 1.6.0 (search) and 1.7.0 (unified inbox).

Keeping this open as the tracking issue for decrypt-and-verify specifically. If you can say which OpenPGP implementation your keys came from and whether you need signing too or just decryption, that will shape the design.

[frenzybiscuit]

My PGP key is EdDSA & Elliptic Curve with AES-256.

[ma2t]

Thanks. That reads like the GnuPG future-default profile: Ed25519 for signing, Curve25519 for encryption, AES-256 as the cipher. The browser-side OpenPGP implementations handle that fine, so nothing about your keys blocks this.

So the crypto side is settled. What's left is UX: how the private key gets into the browser in the first place. Two options I'm weighing:

1. Import once, stored in the browser encrypted under your passphrase, unlocked each session. The key never leaves your machine, but the wrapped key does sit in browser storage.
2. Import at each login, held in memory only. Nothing persists, at the cost of re-entering it every session.

If your key already has a passphrase, option 1 with that passphrase as the unlock is probably the default. Which would you actually use?

Scope for the first pass stays what you described: decrypt plus signature verification when reading. No signing or encrypting on send yet. Still queued behind the unified inbox work, but this thread now has enough detail to write the design from.