Re: [certid] Fwd: secdir review of

"Henry B. Hotz" <hotz@jpl.nasa.gov> Thu, 16 September 2010 16:55 UTC

Return-Path: <hotz@jpl.nasa.gov>
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 4DF393A68F6 for <certid@core3.amsl.com>; Thu, 16 Sep 2010 09:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.39
X-Spam-Level:
X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4KFd5tEBcigI for <certid@core3.amsl.com>; Thu, 16 Sep 2010 09:55:12 -0700 (PDT)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id ECC9E3A6832 for <certid@ietf.org>; Thu, 16 Sep 2010 09:55:10 -0700 (PDT)
Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8GGtYiv030158 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 16 Sep 2010 09:55:35 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp>
Date: Thu, 16 Sep 2010 09:55:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F42C835-3211-48A7-9375-CE45A9C53739@jpl.nasa.gov>
References: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp>
To: "mrex@sap.com" <mrex@sap.com>
X-Mailer: Apple Mail (2.1081)
X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: "certid@ietf.org" <certid@ietf.org>
Subject: Re: [certid] Fwd: secdir review of
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, 16 Sep 2010 16:55:15 -0000

On Sep 15, 2010, at 6:08 PM, Martin Rex wrote:

>> -- Page 19, sec 4.4.3, last graf:
>>   A specification that references the rules defined in this document
>>   can specify that the wildcard character is not allowed in
>>   certificates used by the relevant application protocol or community
>>   of interest.
> 
> To me this sounds awkward.  It implies that either the CA has a flawed CPS
> can not appropriately deal with wildcard reference identifiers in certs,
> or is in general not trustworthy or that the wildcard-scheme too dangerous
> (=too difficult to handle safely) for server admins.


<rant>
I believe wildcards are a misfeature, because a wildcard cert doesn't identify the server well enough that it should be trusted.  I believe that "Best Practice" is to never use the feature, and for clients to raise flags if presented with it.

Of course "Current" practice is to make maximal use of the feature because:

1)  nobody understands how to make the names match in real deployments.

2)  the CA's pricing model makes it cheaper to buy a wildcard cert than the full collection of multiple-alias certs you really need.
</rant>

Getting back to the point:  I think it's perfectly appropriate for a Practice document to restrict when and how much you use a Standard feature.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu