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

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 12 May 2010 20:30 UTC

Return-Path: <Jeff.Hodges@KingsMountain.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 768123A6937 for <certid@core3.amsl.com>; Wed, 12 May 2010 13:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.546
X-Spam-Level:
X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
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 XQV-3xYc4pJB for <certid@core3.amsl.com>; Wed, 12 May 2010 13:30:04 -0700 (PDT)
Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id E65123A6924 for <certid@ietf.org>; Wed, 12 May 2010 13:30:03 -0700 (PDT)
Received: (qmail 1997 invoked by uid 0); 12 May 2010 20:29:54 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 12 May 2010 20:29:53 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TzQDuJiNd6yX8NDmLhbjPtilUZerc8iBCzkDMPk2uYVLhP1e9Hno5UMNnrPNn5Ct2cwnLA24L8Zt4b7wjkoDGets+UMSqErYDpzIP7xXyOp1XVuldFqdGbHHb8GbDJpu;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.49.154]) by box514.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OCIYz-0003Cz-Dl for certid@ietf.org; Wed, 12 May 2010 14:29:53 -0600
Message-ID: <4BEB0FBF.5070502@KingsMountain.com>
Date: Wed, 12 May 2010 13:29:51 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: IETF cert-based identity <certid@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03
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: Wed, 12 May 2010 20:30:08 -0000

 > Is this text more accurate?
 >
 >    The subject field of a PKIX certificate is defined as a X.501 type
 >    Name and known as a Distinguished Name (DN) -- see [X.501] and
 >    [PKIX].  A DN is an ordered sequence of Relative Distinguished Name
 >    (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
 >    value pairs [LDAP-DN], each of which asserts some attribute about the
 >    subject of the certificate.

yes, IMV.


 > BTW I don't see any evidence for the following claim in RFC 4514:
 >
 >    The RDNs are ordered in the DN sequence from
 >    most general to most specific.

It is in X.501 (V3 (4th edition) section 9.7)..

   The distinguished name of a given object is defined as that name which
   consists of the sequence of the RDNs of the entry which represents the
   object and those of all of its superior entries (in descending order).


However, various (many? most?) CAs don't have an actual X.500 / LDAP directory 
with actual entries for the subjects of the certs they issue, and so concoct 
their subjectName DNs outta thin air (more or less) and so the notion that the 
RDNs in such DNs are ordered from most general to most specific doesn't 
necessarily hold (from what I understand).

So I'm not sure right now what to say about that. I suspect we can still 
stipulate that the only RDN having attr type of CN that we'll pay attention to 
is the one at the far end of the RDN sequence comprising the DN.

=JeffH