Viktor Dukhovni:
> 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.
As discussed offlist, I would have structured the code in a different
manner, such that trust-anchor support does not call into the DANE
stack, but DANE and trust anchors are entirely separate features that
call into a common infrastructure.
In any case most of that code is gone with Postfix 3.6.
Wietse
