IETF Logo Mail Archive

Re: [certid] additional security consideration

Joe Orton <jorton@redhat.com> Thu, 18 March 2010 20:26 UTC

Return-Path: <jorton@redhat.com>
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 09AB53A6982 for <certid@core3.amsl.com>; Thu, 18 Mar 2010 13:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.094
X-Spam-Level:
X-Spam-Status: No, score=-108.094 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 IxqjhfSwjo8X for <certid@core3.amsl.com>; Thu, 18 Mar 2010 13:26:42 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 1A38F3A6BBB for <certid@ietf.org>; Thu, 18 Mar 2010 13:26:42 -0700 (PDT)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2IKQr53008910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Mar 2010 16:26:53 -0400
Received: from turnip.manyfish.co.uk (vpn-9-252.rdu.redhat.com [10.11.9.252]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2IKQpHq014181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Mar 2010 16:26:53 -0400
Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.69) (envelope-from <jorton@redhat.com>) id 1NsMIt-0000XV-8m; Thu, 18 Mar 2010 20:26:51 +0000
Date: Thu, 18 Mar 2010 20:26:51 +0000
From: Joe Orton <jorton@redhat.com>
To: Michael =?utf-8?Q?Str=C3=B6der?= <michael@stroeder.com>
Message-ID: <20100318202651.GB502@redhat.com>
References: <20100318040731.GA15227@eltex.net> <20100318195037.GA502@redhat.com> <4BA284FC.8060001@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4BA284FC.8060001@stroeder.com>
User-Agent: Mutt/1.5.20 (2009-08-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21
Cc: certid@ietf.org
Subject: Re: [certid] additional security consideration
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: Thu, 18 Mar 2010 20:26:44 -0000

On Thu, Mar 18, 2010 at 08:54:36PM +0100, 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 don't agree, wildcard certs are very useful in some circumstances.

In any case, I'd hope the goal for this draft is to document current 
best practice, not to move mountains.  Trying to impose a "no wildcards" 
rule without broad consensus from CAs and the browser vendors (good luck 
with that) would harm rather than improve interop.

Regards, Joe

v2.8.7 | Report a Bug | By Email