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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 10:15:44 +0800

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/

---

From: "Eddy Nigg (StartCom Ltd.)" <[email-masked]>
Date: Tue, 23 Nov 2010 02:49:48 +0200

Hi Peter,

> that (1) they are valuable and (2) they do not have undesirable security

I apologize for the huge delay as I'm fighting a flu and a huge backlog. 
I believe the wording is still a bit strong since "SHOULD NOT" means you 
really should *not* except in very specific circumstances exceptionally.

My opinion is, that with good constraints in place (that is contractual, 
proper validations of the applicant etc.) wild cards should be 
legitimate in every respect and there are many good examples for those 
(remember XMPP?). From the CA perspective, the CA really MUST have 
controls in place to prevent misuse, however if the CA will issue 
certificates for paypal.domain.com the argument against wild cards is 
obviously moot.

Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	[email-masked] <xmpp:[email-masked]>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>