* Viktor Dukhovni <postfix-us...@dukhovni.org>: > On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote: > > - make sure the submission server at mail.example.com has certificates > > for mail.example.com as well as example.com, with example.com being > > the certificate that's displayed when the client does't support SNI, > > at least according to draft-fanf-dane-mua-00 > > No need. One certificate is enough. With certificate usage 2 TLSA > RRs, just point the SRV record at the same name that users who > don't rely on zeroconf via RFC 6186 are told to set as their SMTP > server. With certificate usage 3 TLSA RRs, the name in the > certificate is irrelevant. > > > from an ops PoV, the requirement of having two certificates, one for > > the server hostname and one for the mail domain, with the need of > > obtaining both from a CA that has widepread support amongst MUAs, with > > the further need to provide two endpoints, one for old and one for new > > clients, is a real PITA. > > There is no such need, the draft RFC allows server operators to use > *either* name (whichever they prefer), and requires clients to support > both. There is NO requirement for server operators to publish both.
To be honest, that's not what I read from section 4 of draft-fanf-dane-mua-00: | A mail server that is the target of an [RFC6186] SRV record MUST have | a TLS certificate that authenticates the SRV owner domain (i.e. the | user's mail domain). This is necessary for clients that cannot | perform DNSSEC validation. This certificate MUST be the default that | is presented if the client does not use the TLS Server Name Indication | extension (TLS SNI) [RFC6066]. | In order to support this specification, the mail server MUST also have | a certificate that authenticates the SRV target domain (the mail | server hostname). This can be done using a multi-name certificate or | by using the client's TLS SNI to select the appropriate certificate. | The mail server's TLSA record MUST correspond to this certificate. Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01? Stefan P.S: I feel that we might be stretching what's considered on-topic on this mailing list - perhaps we should take this off-list, or to a more appropriate (read: DANE related) list?
signature.asc
Description: Digital signature
