--On Friday, April 21, 2017 09:52 -0600 Doug Royer
<douglasroyer@xxxxxxxxx> wrote:
> On 04/21/2017 09:48 AM, John C Klensin wrote:
>
>>
>> In addition, as others have pointed out, if you can't trust
>> your email (server) provider, then expecting others to trust
>> keys on the basis that they are obtained from that server may
>> not make a lot of sense.
>
> You do not have to trust your or their email server. If you
> trust the cert issuer. Then use the result.
>
> If you do not trust the cert issuer, then do not use the
> results.
Doug,
Sorry... should have been more explicit (or just stayed out of
this). While I agree with you, given the current state of
certification quality readily available to most of us and the
process needed, in the general case, to verify a cert, I have a
lot of trouble figuring out what this thread is about if getting
the cert from the mail server doesn't add value.
There are, as Rich points out, too many cases (perhaps a large
number every year) where a direct connection cannot be made from
the MUA to the remote server (final delivery MTA or something
verifiably under its control). For almost any case involving
relaying rather than that sort of direct connection (and some
that don't), cert requests risk being used to propel a DoS or
blowback attack unless the server can verify the identity of the
MUA or at least the submission server, creating a chicken and
egg problem at best.
The one advantage the (final delivery) mail server has is that
is is able to know --and, in general, is the only system that
knows -- which email addresses in its systems are aliases for
which other one, including such things as whether case-folding
works (and, for non-ASCII local parts, what it even means).
However, some of the discussions now going on in LAMPS
notwithstanding, the certificate issuer generally doesn't have
access to that information so the cert one gets back may not
match the address you asked about closely enough that, in the
general case, you can make a competent decision as to whether or
not to trust it.
Each one of those complications, including any returned
certificates that can't be trusted without further verification
(that might be all of them), makes the value proposition for
fixing a mail server to return certificate over something
mail-related less attractive... and the answer to the original
question in the subject line closer to "why bother?". And, if
the plan is to connect to that server over something other than
email protocols, then it seems to me there is relatively little
advantage of trying to tie the discovery and retrieval
mechanisms to the email infrastructure rather than treating its
as a service we already know how to find with the DNS (even
though that doesn't solve all of the problems. So that answer
is, again, "why bother?" except for a very selected set of cases.
Back to trying to get useful work done.
john