Re: [certid] Domain Components

Peter Sylvester <peter.sylvester@edelweb.fr> Sat, 19 June 2010 18:35 UTC

Return-Path: <peter.sylvester@edelweb.fr>
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 089473A68EA for <certid@core3.amsl.com>; Sat, 19 Jun 2010 11:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.045
X-Spam-Level:
X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 TqaPzv6k4cKJ for <certid@core3.amsl.com>; Sat, 19 Jun 2010 11:34:55 -0700 (PDT)
Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id CC86B3A687C for <certid@ietf.org>; Sat, 19 Jun 2010 11:34:54 -0700 (PDT)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 42492D4 for <certid@ietf.org>; Sat, 19 Jun 2010 20:35:00 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 219EF17139 for <certid@ietf.org>; Sat, 19 Jun 2010 20:35:00 +0200 (CEST)
Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 1882E77D8 for <certid@ietf.org>; Sat, 19 Jun 2010 20:35:00 +0200 (CEST)
Message-ID: <4C1D0DD3.2020907@edelweb.fr>
Date: Sat, 19 Jun 2010 20:34:59 +0200
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
References: <4C12A27D.3070308@stpeter.im> <p0624086ac8386db66483@[10.20.30.158]> <4C1CA2B8.9080103@isode.com> <p0624082ac8427d3d733f@[10.20.30.158]> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> <p0624082ec8428aeca84e@[10.20.30.158]>
In-Reply-To: <p0624082ec8428aeca84e@[10.20.30.158]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [certid] Domain Components
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: Sat, 19 Jun 2010 18:35:01 -0000

On 06/19/2010 04:56 PM, Paul Hoffman wrote:
> At 4:42 PM +0200 6/19/10, Michael Ströder wrote:
>    
>> Alexey Melnikov wrote:
>>      
>>> Paul Hoffman wrote:
>>>        
>>>> No, I'm saying that the order in which you are supposed to take the
>>>> DCs has historically been unclear. "Most significant" means different
>>>> things to different people.
>>>>
>>>>          
>>> I probably sound like a broken record, but the order is very clear for
>>> LDAP. I don't see why is this going to be different for X.509 certificates.
>>>        
>> Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500
>> names as well.
>>      
> ...and you think that all (or even typical) PKIX implementers read either of those documents?
>    
And there might be a chance that this gets worse with RFCs
full of unclear justifications. The order in domain components
is as unclear as the order in DNs, i.e. the same confusion can
occur IMO due to the two different string representions.
(openssl vs ldap)
There are two ways, I have seen a real CA having it DN
starting wit CN and ending with C, the whole in a certificate
issued from a Research Network PKI. Was rather simple to explain
and corrected.

Examples in various RFCs mentionned also contain CN. If (and
that might not be clear)  CN is regarded as more significant,
then the order of DCs is sufficiently clear IMO. I also wonder if
someone who understands the hierarchy of RDNs would
consider that the hierarchy in the DC sequence is the other
way around.  It is more likely that one doesn't think about
any order at all in name components (and implement
names with hash tables) which may be a reasonable
concept with named components.

With the text concerning DCs in RFC 5280 that a CA cannot
assume that a relying party is able to reconstruct a DNS name
from DC components, but the text does not exclude this, thus
one can assume that it is constructed correctly if present.

having said this, I agree with Alexey when he says (in particular
I like the many reasons for the first sentence).

 > I personally I don't care if DCs are allowed or not by this document. 
But if DCs are to be prohibited in this document, I want to make sure 
that the document gives the right reason for that.

Peter