Re: [certid] [cabfman] fyi: newly revised version: draft-saintandre-tls-server-id-check

[Peter Saint-Andre <[e-mail]>]

On 10/21/10 3:46 AM, Eddy Nigg (StartCom Ltd.) wrote:
> 
> On 10/20/2010 08:28 PM, From Hodges, Jeff:
>
>>    o  Move away from the issuance of so-called wildcard certificates
>>       (e.g., a certificate containing an identifier for
>>       "*.example.com").
> 
> However I'm not sure why wild cards should be prohibited, since this is
> perfectly standard compliant. There are valid use-cases for wild cards
> and in fact some of the biggest companies on the Internet are prevented
> from using EV certificates exactly because of this prohibition (to use
> wild cards with EV). I suggest to reconsider this recommendation.

Hi Eddy, the security considerations currently read as follows:

###

5.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 existing
   infrastructure); as a result, the rules provided in this document are
   more restrictive than the rules for many existing application
   technologies (see Appendix A).  Several security considerations
   justify tightening the rules:

   o  The inclusion of the wildcard character in certificates has led to
      homograph attacks involving non-ASCII characters that look similar
      to characters commonly included in HTTP URLs, such as "/" and "?";
      for discussion, see for example [Defeating-SSL] (beginning at
      slide 91).

   o  The ability to obtain a certificate containing the wildcard
      character might broaden the range of applications services that an
      attacker could forge, thus increasing (a) the chances that
      attackers would attempt to steal credentials needed for obtaining
      certificates and (b) the potential damage that would result from a
      successful attack.

   o  Specifications for existing application technologies are not clear
      about whether the wildcard character is allowed only as the
      complete left-most label (e.g., *.example.com), some fragment of
      the left-most label (e.g., foo*.example.com, f*o.example.com, or
      *oo.example.com), or even all or part of a label other than the
      left-most label (e.g., www.*.example.com or www.foo*.example.com);
      nor are they clear about whether a presented identifier can
      include more than one instance of the wildcard character (e.g.,
      f*b*r.example.com or *.*.example.com).  These ambiguities might
      introduce exploitable differences in identity checking behavior
      among client implementations and necessitate overly complex and
      inefficient identity checking algorithms.

   Notwithstanding the foregoing security considerations, profiles of
   this specification can legitimately encourage continued support for
   the wildcard character if they have good reasons to do so, such as
   backward compatibility with deployed infrastructure.

###

Do you think that those justifications are not compelling? On the client
side we've moved from SHOULD NOT to MAY, and I would be open to saying
that wildcards are truly optional on the CA side as well, if we think
that (1) they are valuable and (2) they do not have undesirable security
properties.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/