> On Oct 26, 2017, at 9:21 PM, Jim Fenton <fen...@bluepopcorn.net> wrote:
>
> 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?
This was discussed when the change was made, and again in response
to Ivan's questions just in the past week or so. The flexibility
in question allows the policy to specify that the certificate will
match (say) the recipient domain and not the MX hostname, or either,
or some unspecified hostname in a domain, leaving the match somewhat
fuzzy, which you describe as "wildcard to wildcard".
> 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).
At least one existing library, OpenSSL, widely used by MTAs, already
supports such matching. Granted other libraries may not yet
have equivalent functionality.
> 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.
Similarly, for DANE one forgoes the entire PKI matching route and
compares certificates against TLSA records from DNS, and for DANE-TA(2)
records the the names in the certificate against any element of the
triple (TLSA base domain, recipient domain, CNAME expansion of the
recipient domain). The triple may degenerate to a pair or singleton
for some domains.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
