> On 13 Apr 2016, at 10:38, Daniel Margolis <dmargo...@google.com> wrote: > > > On Wed, Apr 13, 2016 at 11:34 AM, Neil Cook <neil.c...@noware.co.uk > <mailto:neil.c...@noware.co.uk>> wrote: > Well, both need to work independently as you say below. But I might still > have an STS policy (using a different, CA-signed cert) where I have a > self-signed cert for DANE, because I want to support clients who only support > one or the other. Forcing clients to validate both doesn’t seem to be a good > idea. > > I don't really understand how you would do this, though. Wouldn't this > necessitate having different MX records (some of which have matching TLSA > records and serve self-signed certs but aren't included in the STS policy, > and some of which are in the STS policy and have CA-signed certs) and > counting on sending MTAs falling back to the subset of (from their > perspective) valid MXs? > > I'm just trying to understand the setup here a bit better.
Yeah, that would suck. I didn’t think enough about how you would make this work practically. However this does bring up a good point - if I want to support STS *and* DANE as a receiver, and have a homogeneous MX/MTA setup, i.e. not something like the above, I would have to support the common subset of both specifications, at least as far as MTA configuration is concerned, e.g. no self-signed certs. That is a consequence we haven’t discussed before. Neil
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
