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
