On 10/24/2017 11:59 AM, Viktor Dukhovni wrote: > >> On Oct 24, 2017, at 2:48 PM, Jim Fenton <[email protected]> wrote: >> >> Regarding a) above: I apparently missed this. Is there any other >> circumstance where the certificate presented is matched against anything >> other than the hostname? >> >> If we go forward with REQUIRETLS, this would require that it match against >> the STS >> policy if one is present, or against the hostname if one isn’t present. > No. If/when REQUIRETLS implies authenticated TLS and not just mandatory, > but possibly unauthenticated encryption, then the authentication mechanism > needs to be left to the sending MTA's choice, it might use DANE, STS, or > some future technology, and what exactly gets checked depends on the > mechanism. So REQUIRETLS must NOT specify how authentication is done.
I understand that's your position on REQUIRETLS but let's table that for now and stick with MTA-STS. The question I have is: Why are we matching the certificate against the policy rather than against the hostname, and is that done in any other context? Does that offer any additional flexibility? The draft introduces a new wildcard-to-wildcard matching algorithm in section 3.5 that needs to be implemented, rather than more conventionally matching certificate against hostname (and potentially using libraries that already exist). While client MTAs don't typically fail to negotiate TLS if there is a certificate mismatch, at least some do check the certificate and log a warning, so we're talking about requiring two different matching algorithms depending on whether there is an STS policy or not. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
