Re: [certid] additional security consideration

Michael Ströder <michael@stroeder.com> Thu, 18 March 2010 20:50 UTC

Return-Path: <michael@stroeder.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 AF8023A6BD1 for <certid@core3.amsl.com>; Thu, 18 Mar 2010 13:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.169
X-Spam-Level:
X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3]
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 CSSIBJkJy40X for <certid@core3.amsl.com>; Thu, 18 Mar 2010 13:50:15 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id A96BC3A69F6 for <certid@ietf.org>; Thu, 18 Mar 2010 13:50:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 46ED24E085; Thu, 18 Mar 2010 21:50:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIIqk6MpBOan; Thu, 18 Mar 2010 21:50:22 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 99A844E073; Thu, 18 Mar 2010 21:50:20 +0100 (CET)
Message-ID: <4BA2920C.3030401@stroeder.com>
Date: Thu, 18 Mar 2010 21:50:20 +0100
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100205 Lightning/1.0b1 SeaMonkey/2.0.3
MIME-Version: 1.0
To: Joe Orton <jorton@redhat.com>
References: <20100318040731.GA15227@eltex.net> <20100318195037.GA502@redhat.com> <4BA284FC.8060001@stroeder.com> <20100318202651.GB502@redhat.com>
In-Reply-To: <20100318202651.GB502@redhat.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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:50:16 -0000

Joe Orton wrote:
> 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,

Whatever one considers to be best practice...

> 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.

Why do you assume that there is broad consensus from CAs and the browser
vendors for wildcard certs?

https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates

Ciao, Michael.