Re: Public Key Look Up

On Wed 12/May/2021 05:47:52 +0200 John C Klensin wrote:
> --On Tuesday, May 11, 2021 14:55 -0400 John Levine wrote:
>> It appears that Alessandro Vesely  <[email protected]> said:
>>>> I think it's a terrible idea both because it puts the keys in the
>>>> wrong place and the reasons you gave, extensions are optional which
>>>> means not implemented. >>>
>>> I'm not clear why a domain's MX would be the wrong place.
>> 
>> Because you can't tell the user's relation to the domain. Would you want
>> Google to be the authoritative source of keys for every gmail user?
>> Apollo Global Management for every Yahoo and AOL user?

At least, I'd expect Google to be aware that I have a mailbox at theirs, in 
case.  Different keyservers either treat email addresses as opaque tokens or 
need to periodically check whether the email address is still in use by the key 
holder.

Yes, freemail providers are the overwhelming majority, but there are also other 
mail sites.  And the need of an interoperable standard is mostly necessary for 
the latter ones.


> Well, if the keys were signed by entities I trusted, I wouldn't be worried
> about what "authoritative source" means.  And if they weren't, not only
> would I not like that, but it would probably turn the whole idea into
> theater rather than security.   And, as you know at least as well as I do,
> getting general-purpose keys signed in a way that could be generally
> depended on has proven to be a challenge.(to put it mildly).

There are different classes of mailbox providers.  Some have personal knowledge 
of their users, other accept anonymous subscription.  Some users trust their 
mailbox provider.  Some kind of provider can even sign the public keys of its 
users.

I don't think that distrust of one's provider is the only reason to apply 
end-to-end encryption.  Consider a message signed by [email protected] 
whose key is authenticated by the company.  Isn't that a good employer-employee 
relationship?


>> Personally, as a passive-aggressive mail system operator, the
>> only keys my MX would publish would be proxy ones that let my
>> MTA decode the mail and do spam and malware filtering.


I was talking about /public/ keys.


Best
Ale
--