Re: [certid] Domain Components
Peter Sylvester <peter.sylvester@edelweb.fr> Mon, 21 June 2010 18:15 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 201EC3A6AB7 for <certid@core3.amsl.com>;
Mon, 21 Jun 2010 11:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.644
X-Spam-Level:
X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[AWL=-0.557,
BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6]
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 fJGej7BiQ0kH for
<certid@core3.amsl.com>; Mon, 21 Jun 2010 11:15:36 -0700 (PDT)
Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by
core3.amsl.com (Postfix) with ESMTP id 766283A6A8D for <certid@ietf.org>;
Mon, 21 Jun 2010 11:15:30 -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 A872997;
Mon, 21 Jun 2010 20:15:36 +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 967A317061;
Mon, 21 Jun 2010 20:15:36 +0200 (CEST)
Received: from [192.168.0.21] (unknown [82.227.163.182]) by smtps.on-x.com
(Postfix) with ESMTP id 17AD677D8; Mon, 21 Jun 2010 20:15:34 +0200 (CEST)
Message-ID: <4C1FAC2D.5000609@edelweb.fr>
Date: Mon, 21 Jun 2010 20:15:09 +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: Paul Hoffman <paul.hoffman@vpnc.org>
References: <4C12A27D.3070308@stpeter.im>
<p0624086ac8386db66483@[10.20.30.158]> <4C1CA2B8.9080103@isode.com>
<p0624082ac8427d3d733f@[10.20.30.158]> <4C1CD30B.4090200@isode.com>
<p0624082dc84286e8b770@[10.20.30.158]> <4C1F226F.1010408@stroeder.com>
<4C1F2947.9080001@edelweb.fr> <p0624081cc84531dd3cf8@[10.20.30.158]>
<4C1F9D94.8000304@edelweb.fr> <p06240821c84550806b0d@[10.20.30.158]>
In-Reply-To: <p06240821c84550806b0d@[10.20.30.158]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: certid@ietf.org
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: Mon, 21 Jun 2010 18:16:05 -0000
>> As I said in a previous message, the pb also occurs in a string form >> like cn=Paul, O=VPN Consortium >> > Quite true. > > >> I think one might want enhance the normative part of RFC 5280: >> >> The Name describes a hierarchical name composed of attributes, such >> as country name, and corresponding values, such as US. The type of >> the component AttributeValue is determined by the AttributeType; in >> general it will be a DirectoryString. >> >> without other texts of X5xx this is also ambiguous. It doesn't say >> how the hierarchy is encoded, etc for name constraints, what >> is a subtree (prefix or suffix)? I may have overlooked something? >> > You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why I think that this new document allowing constructs that are known security problems is a bad idea. > I didn't not overlook that this effort is to create a new doc. With what authority do you say that what the PKIX group "insists"? Indeed, it might be that you have a server "net.com" and another "com.net" ah well, the real problem is between Serbia and the UK computer science departments. Fortunately we have no top level domain www. I am not saying at all that one should allow an http client to accept DCs if neither DNS-ID is not present (and no CN-ID). Rather the contrary. The new document is destined to CAs that fill DNs, and for RPs that think about it. If both are reminded about the order defined by the X.500 base standards, this is an enhancement. Talking about DCs does not allow anything new that isn't allowed today. If this text "prohibits" the use of DCs in DNs, then RFC 5280 becomes somewhat funny because it uses them as examples. Would an answer to Alexey be: DCs MUST not be used since RFC 5280 does not define the order of the encoding of the hierarchy in the normative part of the text. ??? BTW: Should one speak about jurisdiction and country of jurisdiction attributes?
- [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