Then I think you'll have to use pgp or some other mechanism one layer up. E-mail ain't the way to do it, it's not built into the current protocol as it stands.
Just use PGP, but keep in mind headers won't be encrypted.
If it doesn't fit your bill, just give up and use other methods of communication that aren't email. Email just wasn't built for this sort of purpose in mind.
I was actually thinking more the standard model, where you encrypt the email to a person's PGP key. This only works if the other person has a PGP key, though. It's the usual security <-> convenience tradeoff, unfortunately.
it's an interesting question, but i think the "right" answer here would be that the emails should (in the rfc sense of the word) be end-to-end encrypted, thus there wouldn't be a way to do this at all
How? If I send an e-mail via Amazon's service, they must at minimum have the standard e-mail headers in order to process it. In which case, it's no different than PGP-encrypted e-mail, available with almost any e-mail provider. This also provides Amazon (and whoever subpoenas Amazon) with significant meta-data on my communications, even if they don't have my actual text.
In order to make e-mail into a system where two people can communicate in a secure fashion, where no data is stored on or passes through a remote system unencrypted, you would have to re-implement e-mail. And of course there goes interoperability.
So sending this stuff over unencrypted email would be better?
I think not.
The UX here sucks, but sending this stuff over normal email is a completely ridiculous idea. Crypto would be an option but that'd require custom client software, and nobody is going to use PGP.
(Frankly, I'd be surprised if it was even legal for the NL govt to hand this stuff to third parties by emailing it)
It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath.
The other contender is Autocrypt, which performs key exchange inline in emails in an automated fashion. It only depends on client support, and has gained at least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some others).
They can. Use strong point-to-point encryption. Of course, doing this over email/IM requires special setup that can be pretty clunky and certain habits which require discipline to maintain, and you can not rely on any third-party providers, but in principle that is possible. It's just inconvenient.
The point is about making encrypted email easier. PGP is not the answer, its tools are awful as stated in OP. SMIME can be the answer, but the paucity of CA for personal certs is an issue. That is what we are discussing in this thread.
In theory you could automate it, but that would require a different architecture.
It's honestly pretty stupid that email is being used for this instead of having a secure portal which could include things like RSA hard tokens, or even just passwords with 2FA would be a step up. Nothing is fool proof, but this sort of stuff is common with other sensitive information like finance.
They should do PGP on the way in, for people who want it. It's trivial to set up. All they need to do is let people paste in a public PGP key and encrypt all incoming email with that key. Here's how I've been doing it for the last 7 years:
well since you're working on a mail interface... maybe you could try a frictionless PGP encryption option in the interface? It might be something you at least build a prototype or placeholder for so that it can be implemented fully when going open source.
It is technically possible to add all the support necessary to work with PGP or S/Mime encrypted emails directly in the client. I.e. protonmail implemented this.
reply