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)
