Re: [certid] open issue: wildcards in component fragments

"Jeffrey A. Williams" <jwkckid1@ix.netcom.com> Wed, 13 October 2010 21:54 UTC

Return-Path: <jwkckid1@ix.netcom.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 40B623A69DF for <certid@core3.amsl.com>; Wed, 13 Oct 2010 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.728
X-Spam-Level:
X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599]
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 kLxm8m2SNj+Y for <certid@core3.amsl.com>; Wed, 13 Oct 2010 14:54:05 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id BCA0A3A69CE for <certid@ietf.org>; Wed, 13 Oct 2010 14:54:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RB2G5p+6ecgIsMFqsS51ZXYR6ppM4RBzaa0NkG1loovYo21nqi7wHZvtSJM22sl1; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1P69IB-0001Fj-3o; Wed, 13 Oct 2010 17:55:23 -0400
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 13 Oct 2010 17:55:22 -0400
Message-ID: <31141027.1287006922964.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Wed, 13 Oct 2010 16:55:22 -0500 (GMT-05:00)
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, certid@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b3a026eb20ec7ddbb827fe8c44f41e74350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Subject: Re: [certid] open issue: wildcards in component fragments
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
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: Wed, 13 Oct 2010 21:54:07 -0000

Peter, Rex, and all,


-----Original Message-----
>From: Peter Saint-Andre <stpeter@stpeter.im>
>Sent: Oct 13, 2010 4:52 PM
>To: certid@ietf.org
>Subject: Re: [certid] open issue: wildcards in component fragments
>
>On 10/13/10 3:39 PM, =JeffH wrote:
>>> Note that at least two technology communities have forbidden wildcard
>>> certificates:
>>>
>>> 1. RFC 5992 forbids wildcard certificates in the SIP community.
>>>
>>> 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates
>>> under its "Extended Valuation Certificates" profile.
>>>
>>> So there is some precedent for forbidding wildcard certificates. Is that
>>> a best current practice? Should this I-D state that wildcard
>>> certificates (of whatever variety) are NOT RECOMMENDED?
>> 
>> 
>> I'm thinking that the latter is the way to go wrt wildcards. RFC2119 sez..
>> 
>> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>>    there may exist valid reasons in particular circumstances when the
>>    particular behavior is acceptable or even useful, but the full
>>    implications should be understood and the case carefully weighed
>>    before implementing any behavior described with this label.
>> 
>> ..which certainly sounds reasonable for this situation.
>> 
>> Our working copy of -tls-server-id-check (which are trying to pub by end
>> of this week) has further clarifications wrt the spec's not outright
>> forbidding current practice and various other current specifications,
>> thus present wildcard use does not necessarily conflict with such a "NOT
>> RECOMMENDED" stance. Plus such a stance aligns better with the EV
>> Guidelines, RFC5992, and perhaps other specs going forward.
>
>Jeff and I have been thinking about this independently today, and it
>seems we're going in the same direction. Following Martin Rex's argument
>to its logical conclusion has led me to believe that wildcards deserve
>to be NOT RECOMMENDED in a best current practice document.

  I agree completely.
>
>Peter
>
>-- 
>Peter Saint-Andre
>https://stpeter.im/
>
>
>_______________________________________________
>certid mailing list
>certid@ietf.org
>https://www.ietf.org/mailman/listinfo/certid

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827