On Thu, Aug 20, 2020 at 01:20:00PM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
>
> > - &&TLS_DANE_BASED(state->client_start_props->tls_level))
> > + && TLS_DANE_HASTA(state->client_start_props->dane))
> > @@ -1427,7 +1427,7 @@ static void tlsp_get_request_event(int event, void
> > *context)
> > - TLS_DANE_BASED(state->client_start_props->tls_level));
> > + TLS_DANE_HASTA(state->client_start_props->dane));
>
> This looks weird. I thought that the problem was with trust anchors, not DANE?
Yes, the problem is with trust anchors, but DANE is the general case of:
* Policy-based end-entity cert matching:
- DANE "_25._tcp.example.net. IN TLSA 3 ? ? ..."
- The Postfix "fingerprint" security level
* Policy-based issuer CA cert matching:
- DANE "_25._tcp.example.net. IN TLSA 2 ? ? ..."
- The Postfix verify/secure levels with a custom per-site
"tafile" .
Actual DANE TLSA RRsets can have either or both DANE-EE or DANE-TA
records, with verification ultimately matching either or both. The
"fingerprint" level is mapped to DANE-EE, while "tafile" support is
mapped to DANE-TA.
Thus actual DANE, fingerprint and secure/verify with a "tafile" are all
handled via the "general case" of "some sort of DANE-like policy".
In Postfix 3.6, the job of validating "some sort DANE-like policy" is
entirely delegated to OpenSSL. You'll be pleased to know, that in
Postfix 3.6 the TLS_DANE_HASTA() and TLS_DANE_HASEE() macros are gone.
We no longer need to treat the various DANE-like matching differently.
--
Viktor.
