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
- [certid] additional security consideration ArkanoiD
- Re: [certid] additional security consideration Peter Saint-Andre
- Re: [certid] additional security consideration Joe Orton
- Re: [certid] additional security consideration Michael Ströder
- Re: [certid] additional security consideration Joe Orton
- Re: [certid] additional security consideration Michael Ströder
- Re: [certid] additional security consideration Peter Saint-Andre
- [certid] open issue: wildcard certs Peter Saint-Andre
- Re: [certid] open issue: wildcard certs ArkanoiD