Viktor Dukhovni <[email protected]> (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
signature.asc
Description: Digital signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
