On 1/1/22 5:17 PM, John Levine wrote:
It appears that Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> said:
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.
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.
People have been reinventing this idea for about 30 years now.
Actually, no. And the things you mentioned were not examples of
"reinventing this idea".
It should be clear in hindsight, and should have been clear all along,
that just having a standard format for encrypted messages is not
sufficient to facilitate widespread adoption.
We have
S/MIME, which works pretty well in non-web MUAs if you can get an S/MIME
key which you generally can't unless you work for an organization with
a signing key.
We have various ways to wrap mail messages with PGP signatures and
encryption, a fairly well understood PGP key server scheme, and RFC
7929 which says how to publish PGP keys in the DNS.
One aspect these all share is that, within rounding error, nobody
uses them. I don't see any reason to think that yet another version
of basically the same thing would turn out any differently.
Nor do I, which is why I was explicitly mentioning barriers that have
not yet been addressed.
But hey, you do you.
Keith
