Re: [certid] open issue: wildcard certs

ArkanoiD <ark@eltex.net> Fri, 09 April 2010 21:44 UTC

Return-Path: <ark@eltex.net>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8E73A69F9 for <certid@core3.amsl.com>; Fri, 9 Apr 2010 14:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjjUU1kua+K5 for <certid@core3.amsl.com>; Fri, 9 Apr 2010 14:44:11 -0700 (PDT)
Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id D1EDA3A69C0 for <certid@ietf.org>; Fri, 9 Apr 2010 14:44:10 -0700 (PDT)
Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o39Li3Tm006196; Sat, 10 Apr 2010 01:44:03 +0400 (MSD)
Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o39Li1rP022584; Sat, 10 Apr 2010 01:44:01 +0400 (MSD)
X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f
Date: Sat, 10 Apr 2010 01:44:00 +0400
From: ArkanoiD <ark@eltex.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <20100409214400.GA11843@eltex.net>
References: <20100318040731.GA15227@eltex.net> <20100318195037.GA502@redhat.com> <4BA284FC.8060001@stroeder.com> <4BB3C966.6010003@stpeter.im> <4BBF5C06.8030505@stpeter.im>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <4BBF5C06.8030505@stpeter.im>
User-Agent: Mutt/1.4.2.3i
Cc: certid@ietf.org
Subject: Re: [certid] open issue: wildcard certs
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 21:44:12 -0000

There are EV certificates as well, for which wildcards are strongly disallowed.

On Fri, Apr 09, 2010 at 10:55:34AM -0600, Peter Saint-Andre wrote:
> Regarding wildcard certs, we had the following exchange...
> 
> On 3/31/10 4:15 PM, Peter Saint-Andre wrote:
> > On 3/18/10 1:54 PM, Michael Str??der wrote:
> >> Joe Orton wrote:
> >>> On Thu, Mar 18, 2010 at 07:07:31AM +0300, ArkanoiD wrote:
> >>>> Second level domain MUST NOT be wildcarded, thus *.com is invalid and should
> >>>> never match. (as well as "*", of course)
> >>>
> >>> I don't think it's appropriate for the draft to specify any requirement 
> >>> beyond the "left-most label" rule, so far as wildcards go.  I could 
> >>> imagine a "*.local" or similar could be useful to allow, and *.com is 
> >>> really little more dangerous than *.co.uk.
> >>
> >> Good point with *.co.uk but I'd draw the opposite conclusion from it:
> >> I'd rather like to see wildcards forbidden completely or at least strongly
> >> discouraged.
> > 
> > I would, too. There are significant security concerns with them (related
> > to phishing attacks and such).
> > 
> > However, some CAs will issue wildcard certs to certificate holders who
> > are more highly verified (e.g., Class 2 certificates requiring identity
> > verification of some kind). So I think this is an open issue.
> 
> This issue is still open. :)
> 
> The general approach I would take is to say this:
> 
> 1. If the wildcard character is included in a cert, it MUST be the
> entire left-most domain label (per IESG position).
> 
> 2. A certification authority SHOULD NOT include the wildcard character
> in certificates unless it has appropriate safeguards, strong identity
> checking, or high trust in the recipient (e.g., "Class 2" or "Class 3"
> certificates -- speaking of which, are these terms defined anywhere?).
> 
> 3. We need to clearly document the security problems with wildcard certs
> so that CAs can intelligently decide whether to issue them.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> 
> email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com 
> 
> 



> _______________________________________________
> certid mailing list
> certid@ietf.org
> https://www.ietf.org/mailman/listinfo/certid