On Sat, Jan 1, 2022 at 12:04 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 12/31/21 6:04 PM, John C Klensin wrote:
> Second, I'm not sure what you mean by "OpenPGP over SMTP" but
> cannot think of anything that would prevent defining an SMTP
> extension that asserted that no message was welcome unless the
> content was in OpenPGP (signed, encrypted, or both).
You don't even need an SMTP extension to do that, you just need an SMTP
server that can be configured to refuse or bounce mail that isn't signed
and/or encrypted.
The missing piece is a public key+cert discovery mechanism. This can
also be added to SMTP.
Sharon Boyen and I proposed a solution to that.
The bigger problem is how to issue certs to people. RFC822 email addresses don't work for individuals and we mucked up how to deploy S/MIME in organizations. It should have been an organization cert as for the WebPKI but people got greedy.
That leaves raw keys, fingerprints of keys and names issued on registration of a key.
Then you need mail user agents that query recipients' SMTP servers to
find the recipient's public keys+certs, and verify the keys used to sign
the certs as being trusted.
Verifying certs is easy. Issuing them and managing the private keys is the hard part.
A lot of enterprises would probably like to use encrypted mail but they
also want (for arguably legitimate reasons like looking for malware) to
be able to see the outgoing and incoming content in cleartext. So they
might want to encrypt the outgoing mail after the submission server, and
decrypt the incoming mail after the mail exchanger SMTP server gets
it. So they'd at least want copies of the private keys, even if they
forward incoming mail to its destination with encryption intact.
Threshold meets the compliance concerns better. Every message can be logged and held but exceptional access is subject to accountability.
