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

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

On Fri, June 5, 2015 12:18 pm, Jeffrey Walton wrote:
>  OK, to be clear... the result of inaction is going to result in more
>  CVEs, like CVE-2015-1855.
>
>  Where the rubber meets the road, we have problems in practice. The
>  problems in practice point back to lack of clear direction.

No, this isn't correct.

CVE-2015-1855 has nothing to do with the domain boundary issue. It's all t
do with behaviours documented already in 6125.

The handling of domain boundaries is one of those "defense in depth"
things that depends on your application space and your threat model. In
the event it's "publicly trusted CAs" (e.g. the now shuttered WebPKI
group), then adding a check for "not wildcard TLD" is a defense against a
CA improperly implementing the Baseline Requirements. However, it's a
defense with tradeoffs - as noted on the Bugzilla discussions pointed to
elsewhere, we don't even have a solution for browsers yet.

Other elements of CVE-2015-1855 - things like "Don't allow wildcards for
IDNA", are treated by 6125 but weren't treated by 2616 because it wasn't
even a consideration for 2616.

Further still, elements of CVE-2015-1855 such as "Only allow one wildcard
label" are a judgement decision based on what type of certificates such a
client will expect to see. In the Web PKI, you should only ever see one
wildcard, and thus it's a sensible defense in depth check to add. However,
for internal CAs, it's not at all uncommon - I know, because I got yelled
at by users when I broke them by ensuring Chrome enforced the
one-wildcard-label rule. Even Google was serving some public
"*.*.domain.com" certificates (prior to the BRs notes about wildcard),
because "it just worked".

So I do want to stress that there's an element of policy in place here.
2616 defined how to match, but not what was acceptable. 5280 didn't
describe what was acceptable, because that's a matter of policy. The CA/B
Forum's Baseline Requirements detail what is acceptable, but _only_ in the
case of publicly trusted CA certificates used for TLS (implicitly and
primarily HTTPS, but not exclusively)

Disconnects like the one in Ruby come from when an implementation deals
with the technical aspect, but without touching upon the policy aspect for
the problem space. The IETF can't and doesn't know all the potential
policies that deployments may have - but tries to leave the right hooks
for policies to apply. The other thing to note is that policies change
over time, and sometimes rapidly so - for example, the CA/B Forum allowing
wildcards in EV certs iff that cert is for a .onion domain (and, for that
matter, allowing .onion domains as a temporary exception for CAs to
issue).

Finally, things like policy documents are somehow inherently
controversial. See the TLS BIS discussions. Or see the discussions of RFC
4158, which describes common algorithms that many implementations use in
satisfying the RFC 3280/5280 goals (although, notably, not Ruby or OpenSSL
:)

I don't think it's inherently wrong to put together something about "How
should publicly trusted certificates used for TLS" be validated by
clients, but I think it'd be a mistake to consider it normative
(implementations will/should do what's right for their users and security,
regardless of what a spec says), or permanent (threats change over time).
But sure, it could be helpful.

But I don't think that's what you want.