Re: [certid] Need to define "most specific RDN"

Peter Saint-Andre <stpeter@stpeter.im> Thu, 05 August 2010 21:02 UTC

Return-Path: <stpeter@stpeter.im>
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 579373A6A08 for <certid@core3.amsl.com>; Thu, 5 Aug 2010 14:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 wh3Zi0k3JA5i for <certid@core3.amsl.com>; Thu, 5 Aug 2010 14:02:42 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7CEE73A69E5 for <certid@ietf.org>; Thu, 5 Aug 2010 14:02:42 -0700 (PDT)
Received: from squire.local (ip-216-17-182-116.rev.frii.com [216.17.182.116]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAF9140074; Thu, 5 Aug 2010 15:03:48 -0600 (MDT)
Message-ID: <4C5B2710.6030202@stpeter.im>
Date: Thu, 05 Aug 2010 15:03:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: mrex@sap.com
References: <201007191612.o6JGCEnr008883@fs4113.wdf.sap.corp>
In-Reply-To: <201007191612.o6JGCEnr008883@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: certid@ietf.org
Subject: Re: [certid] Need to define "most specific RDN"
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, 05 Aug 2010 21:02:43 -0000

On 7/19/10 10:12 AM, Martin Rex wrote:

> One thing that I find particularly irritating in -08 is that
> it completely ignores a much more secure authentication
> scheme for servers, by clients knowing the entire subject DName
> of a certificate rather than matching only a single
> name component.

Good point.

To make these (and other) matters clearer, I have written a new section
on the applicability of this document:

***

1.2.  Applicability

   This document does not supersede the rules for certificate validation
   provided in [PKIX]; specifically, in order to ensure proper
   authenticationm application clients need to verify the entire
   certification path (this document addresses only the DNS domain name
   of the application service itself, not the entire trust chain).  This
   document also does not supersede the rules for verifying server
   identity provided in existing application protocol specifications,
   such as those mentioned under Appendix A.  However, it is the intent
   of the authors that the best current practices described here can be
   referenced by future specifications.  It is also expected that this
   document will be updated or obsoleted in the future as best practices
   for issuance and verification of PKIX certificates continue to evolve
   through more widespread implementation and deployment of TLS-
   protected application services over the Internet.

***

/psa