Re: [certid] Domain Components
Alexey Melnikov <alexey.melnikov@isode.com> Sat, 19 June 2010 14:24 UTC
Return-Path: <alexey.melnikov@isode.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 C80793A6A17 for <certid@core3.amsl.com>;
Sat, 19 Jun 2010 07:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=1.197,
BAYES_00=-2.599]
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 PdcYCx3UYYHI for
<certid@core3.amsl.com>; Sat, 19 Jun 2010 07:24:36 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by
core3.amsl.com (Postfix) with ESMTP id 7ADC23A6A16 for <certid@ietf.org>;
Sat, 19 Jun 2010 07:24:36 -0700 (PDT)
Received: from [92.40.172.205] (92.40.172.205.sub.mbb.three.co.uk
[92.40.172.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA
id <TBzTJwAJf6cj@rufus.isode.com>; Sat, 19 Jun 2010 15:24:41 +0100
Message-ID: <4C1CD30B.4090200@isode.com>
Date: Sat, 19 Jun 2010 15:24:11 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Paul Hoffman <phoffman@imc.org>
References: <4C12A27D.3070308@stpeter.im>
<p0624086ac8386db66483@[10.20.30.158]> <4C1CA2B8.9080103@isode.com>
<p0624082ac8427d3d733f@[10.20.30.158]>
In-Reply-To: <p0624082ac8427d3d733f@[10.20.30.158]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF cert-based identity <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: Sat, 19 Jun 2010 14:24:37 -0000
Paul Hoffman wrote: >At 11:58 AM +0100 6/19/10, Alexey Melnikov wrote: > > >>Hi Paul, >> >>Paul Hoffman wrote: >> >> >>>At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >>> >>> >>>>Version -05 of draft-saintandre-tls-server-id-check has some warning >>>>text about Domain Components (DCs). However, the more I delve the matter >>>>the less I think that we need to warn people away from using DCs from a >>>>security perspective. The problem with them would arise from confusion >>>>about the order of DCs based on the string representation, however that >>>>kind of confusion is possible for any RDNs and is not limited to DCs (so >>>>follow the DER order, not the string order). There might be other >>>>reasons to discourage DCs, but so far I have not heard them, so I'm >>>>inclined to remove the warnings from -06. >>>> >>>>Do speak up if you're concerned about this proposal. >>>> >>>> >>>Finally decloaking after being off this topic for a while. >>> >>>I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. >>> >>>For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. >>> >>> >>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. >> >>The order of RDNs in a DN is fixed. So you are saying that there are buggy implementations (and maybe most of them are buggy) which don't read RDNs in the correct order, that is why we need to prohibit use of DCs in subjectName? >> >> >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.
- [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