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
- [certid] Domain Components Peter Saint-Andre
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Alexey Melnikov
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Alexey Melnikov
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Peter Sylvester
- [certid] CN-ID in version 6 Peter Sylvester
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Bruno Harbulot
- Re: [certid] Domain Components Martin Rex
- Re: [certid] Domain Components Martin Rex
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Martin Rex