On 11/1/17 3:59 AM, Daniel Margolis wrote: > The decision to use policy-to-SAN matching instead of > policy-to-hostname matching was discussed here > (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I > think the WG was at the time largely in consensus (or we misread the > consensus). I thought we also discussed this at IETF95, but at this > point my memory is hazy. > > To be clear, I think you are right that this affects a small number of > users. RFC 7672 also allows this "nexthop" matching, but I think it's > OK for STS to enforce a "must match the hostname" policy. On the flip > side, I believe SAN matching is also fairly easy to implement (~10 > lines of pseudocode in the Appendix--hopefully correct!--and Viktor > says OpenSSL already exposes such a function). > > My understanding is that while you and Jim would prefer hostname > matching and Viktor (and others?) would prefer SAN matching, nobody > has said that if their non-preferred option is chosen this is a > blocker for implementation. Am I right? It looks like this is conflating a couple of different things: (1) matching CN vs. SAN on the certificate, and (2) matching whatever on the certificate against hostname vs. STS policy.
For (1) I favor doing whatever browsers do, which I thought was to match against either CN or any of the names listed in the SAN. (2) I favor matching the certificate against hostname rather than policy, because MTAs that already verify TLS certificates (even if it's only advisory info for log files and Received header fields) do it this way currently. Otherwise, certificates are matched against different things depending on whether there's an STS policy or not, and I don't see a reason to change current behavior. What's the advantage of matching against policy? If this is already decided, it's already decided, but I wanted to at least frame the issue correctly. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
