Re: [certid] Domain Components

Paul Hoffman <phoffman@imc.org> Mon, 21 June 2010 18:10 UTC

Return-Path: <phoffman@imc.org>
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 1425A28C129 for <certid@core3.amsl.com>; Mon, 21 Jun 2010 11:10:52 -0700 (PDT)
X-Quarantine-ID: <ONOvagwQnzzX>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Michael Str\366der <michael@st[...]
X-Spam-Flag: NO
X-Spam-Score: 0.725
X-Spam-Level:
X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3]
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 ONOvagwQnzzX for <certid@core3.amsl.com>; Mon, 21 Jun 2010 11:10:51 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 01D4628C134 for <certid@ietf.org>; Mon, 21 Jun 2010 11:10:46 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5LIAnNT024716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 11:10:52 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240828c8455b71fba1@[10.20.30.158]>
In-Reply-To: <4C1FA6F0.1040001@stroeder.com>
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]> <4C1FA6F0.1040001@stroeder.com>
Date: Mon, 21 Jun 2010 11:10:47 -0700
To: Michael Str�der <michael@stroeder.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: Mon, 21 Jun 2010 18:10:52 -0000

At 7:52 PM +0200 6/21/10, Michael Ströder wrote:
>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?
>
>Some of them do.
>
>If you dig in mailing list archives you will find that I know enough about
>deficiencies of real-world software. And I tracked down quite a few bugs in
>software of "major" PKI vendors some of them related to DN (string) handling.
>
>But what does that tell us? To give up writing or referencing RFCs?

It tells us that, when there are multiple ways to do things, and some of those ways are known to be insecure due to repeated poor implementations, we can say "don't do that" for the bad ways.