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

[Jeffrey Walton <[e-mail]>]

Below is the current language (thanks TS). It clearly allows matching
*.COM if the wildcard is in the leftmost label.

And it may allow match just "*", if that is interpreted as the
leftmost label (but not the center label or rightmost label). Stranger
things have happened....

Jeff

(6.4.3. Checking of Wildcard Certificates)

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].


On Fri, Jun 5, 2015 at 1:55 AM, Jeffrey Walton <[e-mail]> wrote:
> This issue came up on the DBOUND list.
>
> Relevant RFCs like 5280 and 6125, allow wildcards and don't restrict
> them. Some folks have taken the lack of restriction to allow matching
> of *.COM, *.NET and *.ORG. It seems like a logical leap since there is
> no restriction placed on them (or even '*' or '*.*').
>
> When questioned, they state the RFCs don't prohibit them. See, for
> example, "Overly permissive hostname matching" for Wget and GnuTLS
> (https://lists.gnu.org/archive/html/bug-wget/2014-03/msg00093.html and
> https://lists.gnupg.org/pipermail/gnutls-devel/2014-March/006833.html).
> From the GnuTLS reply:
>
>     That's a very interesting point, but I am not sure there is an easy
>     fix. GnuTLS follows RFC2818 for hostname verification, and that
>     document is pretty clear on the scope of the wildcards. It mentions
>     for example: "f*.com matches foo.com". Maybe we can forbid a first
>     level wildcard, but is that practice documented somewhere? I don't see
>     any IETF documents updating RFC2818.
>
> The list is actually larger than those two projects, and includes
> others, like Ruby, Java, .Net, Cocoa/CocoaTouch and PERL. Its quite an
> impressive list of offenders. Some offenders, like Ruby, have fixed
> their validators
> (https://www.ruby-lang.org/en/news/2015/04/13/ruby-openssl-hostname-matching-vulnerability/).
> Others have not.
>
> In case its not obvious, no one organization or entity controls some
> of the gTLDs, like *.COM, *.NET and *.ORG. It makes no sense to allow
> a match on them in a CN or SAN.
>
> The CA/Browser Forums, Baseline Requirements document does not allow
> them under Section 3.2.2. But the CA/B is a different set of issuing
> policies, and IETF conforming implementations don't use the CA/B.
>
> Please address this issue in the RFCs.