On Fri, 10 Jan 2020, Paul Heinlein wrote:
The ideal toolchain would I think be something like this.
1. End users generate a keypair (ala PGP) and publish public keys.
2. Bob uses MUA-level hooks to encrypt body of message using Carol's
public key, signing the message with his private key.
3. MUA submits message to MTA using TLS-negotiated encryption,
protecting SMTP header info in transit along with already
encrypted message body.
4. Sender MTA delivers messaage to recipient MTA using similar
TLS wire-level crypto to protect SMTP header info.
5. Recipient MTA delivers message; body remains encrypted.
6. Carol verifies her trust in Bob's public key.
7. Carol uses MUA-level hooks to decrypt Bob's message using
her private key and verifying Bob's key as the sender.
Only the in-memory version of the message is decrypted;
the on-disk message remains encrypted.
Points 3 and 4 are already in widespread use. Point 5 will always be true is
encryption is handled by the MUA.
The lack of a universally accepted key-management system hinders points 1 and
6; I know that's where PGP is aimed, but I'd hardly call it universally
accepted.
The closest we have to an MUA standard in points 2 and 7 is S/MIME, which is
widely implemented but doesn't work with PGP, relying instead on the same
key-management techniques used to issue SSL certificates for, e.g., web
sites.
Beyond all that is the problem of data retention. It's likely that a secure
system will encourage key expiration, if for no other reason than to keep
moving away from once-secure techniques that become insecure due to increased
computing power, clever algorithm developments, or whatever. If that's true,
what do you do will all the messages that arrived encrypted with your old
key?
Paul,
Wow! What an education. Thank you. I suspect that most Windows users would
find this overwhelming, and their employers likely not interested.
Regards,
Rich
_______________________________________________
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
