[SSL Observatory] wildcarded Domain Names in certs (was: Name constraints: a reasonable idea that hasn't...)

[=JeffH]

Erwann ABALEA <erwann at abalea.com> responded:
 >
 > 2011/5/5 Daniel Veditz <dveditz at mozilla.com>:
 >>
 >> On 4/22/11 4:44 PM, Erwann ABALEA wrote:
 >>>
 >>> Wildcard certificates were verified with different rules wether
 >>> IE/CAPI or FF/NSS was used, if memory serves right; I think
 >>> FF/NSS considered that something like "*.domain.com" could match
 >>> "very.secure.domain.com", for example, but IE didn't. Lack of
 >>> standardization.
 >>
 >> The wildcard rules are very clearly spelled out in the standards,
 >
 > Which standard? X.509 doesn't talk about this, RFC2459/3280/5280
 > leaves such considerations outside of its scope, RFC2818 covers only
 > HTTPS and is of "Informational" level, RFC2595, covers TLS with IMAP
 > and POP3. Both RFCs have a definition of wildcard, but not the same.

Yes, every protocol layered over TLS has historically specified its own version 
of what some call "name matching" -- the comparison of the domain name with 
which the interaction was initiated, and the domain names embedded in the 
returned End Entity cert (in the TLS/SSL handshake).

In RFC6125 we informationally reference all such RFCs we could identify (11 of 
'em) and include relevant excerpts in appendix B.


 > RFC6125's purpose is exactly on identity check,

yes, tho we term it "application service identity" (as denoted by a DNS domain 
name). And the hope is that, going forward, protocol specs that intentionally 
layer over TLS will reference RFC6125 for their application service identity 
name matching, rather than specifying it themselves (in yet a different 
permutation).


 > and paragraph 7.2
 > explains that wildcard is not clearly specified at all. Earlier in
 > this document, wildcard usage is not recommenced.

Yes, Sec 7.2 explains that and a bunch more. I've included it below fyi/fwiw..

HTH,

=JeffH
-------

from http://tools.ietf.org/html/rfc6125:


7.  Security Considerations

...

7.2.  Wildcard Certificates

    This document states that the wildcard character '*' SHOULD NOT be
    included in presented identifiers but MAY be checked by application
    clients (mainly for the sake of backward compatibility with deployed
    infrastructure).  As a result, the rules provided in this document
    are more restrictive than the rules for many existing application
    technologies (such as those excerpted under Appendix B).  Several
    security considerations justify tightening the rules:

    o  Wildcard certificates automatically vouch for any and all host
       names within their domain.  This can be convenient for
       administrators but also poses the risk of vouching for rogue or
       buggy hosts.  See for example [Defeating-SSL] (beginning at slide
       91) and [HTTPSbytes] (slides 38-40).

    o  Specifications for existing application technologies are not clear
       or consistent about the allowable location of the wildcard
       character, such as whether it can be:

       *  only the complete left-most label (e.g., *.example.com)

       *  some fragment of the left-most label (e.g., fo*.example.com,
          f*o.example.com, or *oo.example.com)

       *  all or part of a label other than the left-most label (e.g.,
          www.*.example.com or www.foo*.example.com)

       *  all or part of a label that identifies a so-called "public
          suffix" (e.g., *.co.uk or *.com)

       *  included more than once in a given label (e.g.,
          f*b*r.example.com

       *  included as all or part of more than one label (e.g.,
          *.*.example.com)

       These ambiguities might introduce exploitable differences in
       identity checking behavior among client implementations and
       necessitate overly complex and inefficient identity checking
       algorithms.

    o  There is no specification that defines how the wildcard character
       may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
       internationalized domain name [IDNA-PROTO]; as a result,
       implementations are strongly discouraged from including or
       attempting to check for the wildcard character embedded within the
       A-labels or U-labels of an internationalized domain name (e.g.,
       "xn--kcry6tjko*.example.org").  Note, however, that a presented
       domain name identifier MAY contain the wildcard character as long
       as that character occupies the entire left-most label position,
       where all of the remaining labels are valid NR-LDH labels,
       A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").

    Notwithstanding the foregoing security considerations, specifications
    that reuse this one can legitimately encourage continued support for
    the wildcard character if they have good reasons to do so, such as
    backward compatibility with deployed infrastructure (see, for
    example, [EV-CERTS]).

---
end