Re: [exim-dev] proposal: new smtp transport option "tls_cont…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Heiko Schlittermann
Datum:  
To: exim-dev
Betreff: Re: [exim-dev] proposal: new smtp transport option "tls_continue"
Viktor Dukhovni <viktor1dane@???> (Do 08 Mai 2014 17:23:43 CEST):
> On Thu, May 08, 2014 at 04:09:21PM +0100, Jeremy Harris wrote:
>
> > Since a simple expansion can call a custom ACL, which might be
> > given visibility of that certificate, we can get as complex
> > as we want. It would be able to do the checking of
> > SN/SAN against the peer name (hmm. Which one? The MX?) if
> > we didn't get around to hardwiring that (and apparently if
> > we did hardwire it we'd need an exception for DANE... is that
> > true?)
>
> You'd be inviting non-experts to mess with some of murkiest and
> dragon-infested parts of PKI. Don't go there.
>
> In DANE for SMTP the (RFC 6125 jargon) "reference identity" for
> the server is a set of up 3 names. Each of which may match any of
> the server's subjecAltName DNS names with support for single label
> wildcards, but this is ONLY for certificate usage 2 and not 3.
> With usage 3 non-leaf certs are ignored, as is the cert expiration
> and trust chain.
>
> DO NOT delegate this logic to users, they will get wrong, causing
> both security and interoperability issues.


I fully agree.
I'm thinking of something about that way (not sure, if I
got the ${acl{}} feature right…

    begin acl


        acl_check_dane:
            accept verify = dane
            deny



    begin transports


        remote_smtps:
            driver = smtp
            hosts_require_tls = *
            tls_continue = ${acl{acl_check_dane}}


This give the user the power to implement whatever he wants
as the condition.

--
Heiko