Re: [certid] Comments on draft-saintandre-tls-server-id-check-04

Nelson B Bolyard <nelson@bolyard.me> Thu, 03 June 2010 21:53 UTC

Return-Path: <nelson@bolyard.me>
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 44A8228C140 for <certid@core3.amsl.com>; Thu, 3 Jun 2010 14:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 ME5cBLQnw+ao for <certid@core3.amsl.com>; Thu, 3 Jun 2010 14:53:32 -0700 (PDT)
Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 528CE28C12C for <certid@ietf.org>; Thu, 3 Jun 2010 14:53:32 -0700 (PDT)
Received: (qmail 9784 invoked from network); 3 Jun 2010 21:53:18 -0000
Received: from unknown (74.121.22.10) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 03 Jun 2010 21:53:18 -0000
Message-ID: <4C08244D.9010809@bolyard.me>
Date: Thu, 03 Jun 2010 14:53:17 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
References: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp>
In-Reply-To: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04
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, 03 Jun 2010 21:53:33 -0000

On 2010/05/31 08:18 PDT, Martin Rex wrote:

> While there have been few implementations checking for multiple
> CN= parts, the guideline in rfc-2818 for subjectAltNames seems
> to be much clearer, that there can be more than one, and more
> than one needs to be checked.

That is precisely what it says NOT to do.  It says

>    If a subjectAltName extension of type dNSName is present, that MUST
>    be used as the identity. Otherwise, the (most specific) Common Name
>    field in the Subject field of the certificate MUST be used.

The phrease "the (most specific) Common Name field in the subject field"
is not plural.  There is at most one Common Name attribute in the name
that is *the* most specific one.  The words "most specific" refer to its
position in the list of RDNs, which are arranged (as encoded in the
certificate Name field) from most general (first) to most specific
(last).  So, the most specific Common Name is the last of the Common
Name attributes in the sequence of RDNs, as encoded in the certificate.