On Tue, Jul 29, 2014 at 11:24:52AM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
> > * smtpd_tls_ask_ccert_helo_names =
> > <domain match list> (overrides smtpd_tls_ask_ccert = no)
>
> And one more main.cf parameter for client TLSA records. That would
> make three.
Yes, in this model, another boolean to enable client TLSA records.
>
> > * smtpd_tls_ask_ccert =
> > no | yes |
> > match_client_{address,name,helo_name} type:name,
> > ...
>
> What would this user interface look like with client TLSA
> records?
Well, the DANE case is more interesting, because it likely fits
better into "req_ccert" than "ask_ccert", with the client cert
required when associated TLSA records are found, and validated
based on those records.
So we'd perhaps have:
smtpd_tls_req_ccert =
no | yes | dane
which leaves the question of whether this too needs a local policy
override:
smtpd_tls_req_ccert =
no | yes |
[ dane, ]
[ match_client_{address,name,helo_name} type:name, ]
...
Where "no" or "yes" stand alone, but "dane" could be combined with
any of the match primitives.
Perhaps a better option is to change the "match" feature to a lookup
feature which returns a value of "no | ask | require | dane", thus we'd have:
smtpd_tls_ccert_policy =
lookup_client_address static:no,
lookup_client_helo_name static:ask,
lookup_client_name static:require,
lookup_client_helo_name static:dane,
with "static" being just an example table type that illustrates
the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".
--
Viktor.
