Re: [pkix] Please clarify when and where wildcards should be matched in PKIX certificates

["Ryan Sleevi" <[e-mail]>]

On Fri, June 5, 2015 3:42 am, Jeffrey Walton wrote:
>  Tough problem in general.
>
>  (1) At the second label (with the leftmost as a wildcard), there are
>  three top levels to consider.
>
>      (A) Traditional Top Level Domains (call them gTLDs). *.COM, *.NET,
>  *.MIL,etc
>      (B) Country Top Level Domains (call them ccTLDs). *.UK, *.CN, etc
>      (C) Vanity Top level Domains (call them vTLDS). *.GOOLGE and friends

These are called Brand TLDs.

>  We can remediate (A) because its an exhaustive list. We just say NO.

Except it isn't an exhaustive list by any means, it is fluid. And you've
incorrectly lumped ".mil" in here, which is handled by the DoD Network
Information Center. .mil is a sponsored TLD fully operated by DISA/DOD
NIC, and as such, it's entirely reasonable for the DoD root CAs (which are
trusted as a matter of local policy by DoD machines, although not widely
trusted publicly) to issue *.mil, should they so wish.

>  I think (A) and (B) could (and should) be called out in PKIX
>  validation because validation is within purview of PKIX and the rules
>  are obvious.

The rules aren't obvious for a second. They change and have changed over
time.

>  We need the rules now, so there's probably no reason to wait for
>  DBOUND to deliver something. Plus, there's no guarantees DBOUND will
>  be delivering anything useful for any of these case (including (1)(A)
>  and (1)(B)). Finally, we already have some rules in RFC 6125, so
>  validation is within purview of PKIX.

That's specious logic. What you're describing is application trust policy
- "How do we determine X is authorized to say Y?" - and that's dependent
on local trust policies and configurations.

A locally installed trust anchor (which I know you're on record as being
opposed to) could totally determine that they're duly authorized to issue
for *.whatevertheywant, because that's what local policy means.

This isn't academic or theoretical - this is actively in use by
deployments today. No amount of handwringing here will fundamentally
change that.

If there is going to be something to express policy-by-default, and that
policy-by-default isn't expressed via the present Public Suffix List
(which I wouldn't advocate for a second standardizing upon as a MUST; at
best, a MAY), then it will presumably be through the activities of DBOUND.
So yes, waiting for DBOUND, and then waiting to see reception from actual
application software vendors from DBOUND, is an entirely reasonable step.