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

Sean Turner <turners@ieca.com> Wed, 12 May 2010 21:36 UTC

Return-Path: <turners@ieca.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 33D783A691E for <certid@core3.amsl.com>; Wed, 12 May 2010 14:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.67
X-Spam-Level:
X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_50=0.001, UNPARSEABLE_RELAY=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 yCM0MnH3XDgA for <certid@core3.amsl.com>; Wed, 12 May 2010 14:36:33 -0700 (PDT)
Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id B7EB53A6876 for <certid@ietf.org>; Wed, 12 May 2010 14:36:33 -0700 (PDT)
Received: (qmail 99821 invoked from network); 12 May 2010 21:36:21 -0000
Received: from thunderfish.local (turners@96.231.119.54 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 12 May 2010 14:36:20 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: PciQKCsVM1kZDKHZNbO_ZU1A9pejYBc_bjf6HnuSb0rdknCcRY.mx5LW8huXz2JuVKhfErrW.jkw6_pWUPcpacbU6wLHuTEro93puMXVeNHe3NRkQIrI8edY5T9.gmc_b1njXFE8JshtKL4vksxxoVqdFE_A6qkGXQp.bZHoGdfu.OlXLls7_PoLDnbhT4bmflwVJ33o_T0faDv7hOD4.8JVbhxUUVhgBfTQ7LS2xrTGdO79VX5fSKzj2f70XXb46r7iVta.YWeQZhGpVGwhvICQjv2899_SeIowonUmfUva5ieiWXodu64OgyK080OAIXxh62C44AL6k1umQTmYR.kxaNvdFNkkxFKd47GnCTPmhYHXVwiPPj1CkKSnSLT1vqIkhCdmnEqpIWYCITsdysdPTCmnEaqanwR6Yx1BoT_UDUy1FhMZDjbc3mR4GdDLzcCClmH5aHdS2k_QheYr9y2uDA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BEB1F54.2060905@ieca.com>
Date: Wed, 12 May 2010 17:36:20 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4BEB0FBF.5070502@KingsMountain.com>
In-Reply-To: <4BEB0FBF.5070502@KingsMountain.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF cert-based identity <certid@ietf.org>
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 21:36:35 -0000

=JeffH wrote:
>  > 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.

I think a lot of DNs got concocted because X.500 implementers assumed 
the examples in X.501 were normative.  That is c=, o=, (4) ou=, cn=. 
But, you're might be right about no descending ordering can be 
assumed.  If you look at the subjectName in the datatracker 
certificate it's:

CN = *.ietf.org
OU = Terms of use at www.verisign.com/rpa (c)05
OU = Internet Engineering Task Force
O = IETF Trust
L = Reston
ST = Virginia
C = US

Is an organization more or less specific than a location?

spt