On Tue, Jul 29, 2014 at 10:52:42AM -0400, Wietse Venema wrote:
> > My thinking is that only the HELO name is a plausibly correct client
> > identity for certificate checks. This is that the client calls itself.
>
> It does not matter. We have a client with N properties and we need
> a matching mechanism. The matching mechanism should be more general
> than the specific user-visible problem at hand.
>
> Anf if at all possible, we should also avoid a user interface that
> requires two parameters to turn on/off one feature: one binary
> parameter and one matching parameter.
STARTTLS is just after the first EHLO, so what we have is:
* Client IP address
* Possibly a client DNS name we can't rely on.
* A client EHLO name.
Thus a decision to ask for client certs can use at most these three
inputs. The user interface is then one of:
* smtpd_tls_ask_ccert_helo_names =
<domain match list> (overrides smtpd_tls_ask_ccert = no)
* smtpd_tls_ask_ccert =
no | yes |
match_client_{address,name,helo_name} type:name,
...
We can indeed give users enough rope to attempt to use the client
address or name in this context.
If/when the DANE WG blesses TLSA records for TLS clients, we could
also enable client certs based on the presence of associated TLSA
RRs. These would have to be based on the client HELO name. Neither
of the other inputs are suitable for constructing the TLSA base
domain.
--
Viktor.
