On Tue, Jul 29, 2014 at 10:03:04AM -0400, Wietse Venema wrote:
> > That was also my thinking, but I was expecting a new parameter,
> >
> > smtpd_tls_ask_ccert_helo_names = <domain match list>
> >
> > Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
> > a bit of special gymnastics to deal with "yes" and "no", would that
> > be better?
>
> smtpd_tls_ask_ccert_helo_names does not generalize. We'd also need
> smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs
> and so on. Instead of introducing code that solves only one user-visible
> problem, introduce infrastructure that can be reused in other contexts.
My thinking is that only the HELO name is a plausibly correct client
identity for certificate checks. This is that the client calls itself.
while the client name is not reliably available (DNS timeout, ...)
and the IP address is difficult to reliably associate with a given
sending organization. The envelope sender address is end-to-end,
and so is not applicable to hop-by-hop TLS security policy.
Therefore, the client gets to announce its name (via EHLO) and the
server can optionally request client certs when the alleged EHLO
name is on a list of special domains, or perhaps in the future when
there is a client DANE TLSA record for the name in question.
So the choice of "helo_names" is not random, it is I think the
only plausible "reference identity" for the client.
--
Viktor.
