Re: Public Key Look Up

It appears that Jeremy Harris  <[email protected]> said:
>On 08/05/2021 15:03, [email protected] wrote:
>> In order to address this interoperability issue in a standards centric approach, the proposal is the addition of
>a new SMTP command to allow the retrieval of a recipients public key prior to the transmission of a mail. This
>will enable the sender to encrypt the email content before the same is transmitted through the existing SMTP
>commands.
>
>This requires the MUA to be a full MTA not just an MSA passing off outbound
>traffic to a real MTA,  Not the current usual architecture.

It also treats mail providers like Google and Comcast as "end users" which
seems quite wrong.

We have had standard ways to encrypt mail with S/MIME and PGP for a
long time. It happens in the MUA so the MTAs are outside the trust
boundaries and see only an encrypted blob of data. S/MIME is widely
supported on desktop and mobile MUAs (Apple mail on an iPad, for
example) but hardly anyone uses it which should tell us something.

There are no standard ways to look up S/MIME or PGP public keys
because secure key lookup is a very difficult problem. How do you know
you are talking to the "real" key server? Why do you believe what it
tells you? PGP has its web-of-trust which we have repeatedly learned
does not scale beyond tiny niche communities. S/MIME is TOFU; if I
send you a signed message, it includes my public key, and MUAs
remember the key in the address book so you can encrypt mail to me.

Given our decades of failure getting people to use e2e encrypted mail
I don't see any point in doing it again.  On the other hand, channel
encryption with STARTTLS is now nearly universal since it doesn't
depend on users to do anything.

R's,
John