On Sun, May 18, 2014 at 04:09:39AM +0100, Phil Pennock wrote: > There are rules for wildcard name matching in RFC 6125 section 6.4.3 which > beyond your code add support for the `*` not being the only component of a > label. Frankly, that's stupid and adds yet more complexity in an already > overly twisted area, especially since there's no statement around labels with > multiple wildcards in them (`f*b*r`) and handling that quickly leads into DoS > opportunities.
There are not cases in which the wildcard is in the middle of the label not cases with multiple wildcard characteres. RFC 6125 strongly recommends against wildcards other than "*" as the whole label, and also discourages wildcards (not as strongly). For SMTP existing MUA to MTA practice is to support only "*.example.com" as a wildcard, with no partial label matching. There is no definite precedent for name checks with MTA to MTA SMTP, but I'm also working with the UTA (Using TLS in Applications) IETF working group draft authors who are defining some conventions for MTA to MTA namechecks in the absense of DANE (even though this generally yields no security for lack of secure MX indirection)... Turns out people are doing silly things, so they may as well be insecure interoperably. So bottom line: - "*.example.com" should match "mx.example.com". - "m*.example.com" should not match "mx.example.com" > So I'm inclined to have the wildcard support only handle where a complete > label > is replaced by `*`, exactly as you have it, but we probably need to document > this as "how Exim handles wildcards in certificates". Fortunately Exim will soon have a couple of RFCs to lean on. > Viktor, any strong feelings on wildcards other than whole-label? Whole label only. And only because such wildcard certs continue to be popular, and we don't need to needlessly surprise their expectation that these should work. Both drafts are new ground, and we could define MTA to MTA as supporting no wildcards at all, but while this is a more "pure" approach, we'd annoy people more than help them? If you feel otherwise, speak up now! -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##