On 2014-05-18 at 03:28 +0000, Viktor Dukhovni wrote: > 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"
Sounds good to me (and matches what I think I said we should do) -- we stick to what Jeremy has coded and avoid risking the whole glob class of attacks. > 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! Concur. Wildcards with '*' as the left-most label make sense to me, we should support them. I'm ambivalent about '*' as a non-terminal label; I could see someone wanting 'DNS:mail1.*.example.com, DNS:mail2.*.example.com' and more use-cases around certs which embed _proto prefices for some scenarios, but I don't feel strongly enough to argue for it, only to raise it as "huh, might be worth considering". I do not think that wildcards should be in non-terminal certificates, but host identities are not meaningful in anything but the terminal, so that should be a noop. (Although, if nameConstraints had taken off, I might have a different opinion). -- My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco: http://www.apcera.com/jobs/#operations-engineer (but all the mistakes in this email are made in my personal capacity) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
