Re: [certid] Need to define "most specific RDN"

Kaspar Brand <ietf-certid@velox.ch> Mon, 19 July 2010 05:34 UTC

Return-Path: <ietf-certid@velox.ch>
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 664953A69DC for <certid@core3.amsl.com>; Sun, 18 Jul 2010 22:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.072
X-Spam-Level:
X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_05=-1.11]
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 xitytVPHebSd for <certid@core3.amsl.com>; Sun, 18 Jul 2010 22:34:27 -0700 (PDT)
Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id A5FE73A69DF for <certid@ietf.org>; Sun, 18 Jul 2010 22:34:16 -0700 (PDT)
Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o6J5XisY003655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <certid@ietf.org>; Mon, 19 Jul 2010 07:33:45 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1279517625; bh=wWnEYHyu3Uhvz74jYwunnL7fdEj0JjnkD9hazOqKuFo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ELL09vHSRxZ1M5ps9vXtoivMOaNlffd/pf5YgeQOgnV9eArw6xq+orU3NkzhkqDns JPCYYQbh3BLEK8ZbW+iBlMxoiMfmSlDlxYgedvoAO+JAFlOQK0eObr8DA5MgNoVuvi ECDmWcyVCtw/opiWOiOUCLMi7WTnZ6FKAR67qW8xu01a22NXW84eCXtAvdPAfUaAbA 7e+OqxhvCAFyPx3SfzPHwE1v/5J2dlydCGWCEs8Bw9+oyd55qmkCQpmHpLOj09iJXp TGHmvEBHl6XygjQWvSmo+LC1j/anHFyU2e0xZTpBwMDn5sEbhafaei2OUaZsbpG/+i GMJR0R+jXrFCw==
Message-ID: <4C43E3B9.6040004@velox.ch>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1279517623; bh=wWnEYHyu3Uhvz74jYwunnL7fdEj0JjnkD9hazOqKuFo=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=JUrFRNwA9ohGFh65TPjQXQWKTmjQYGOcH0k4AsjmoMPL/bIkMfUPexE/4nbBahwAI wtiPNKjEzH7pr4mkqA/UwqARqQNig5BlsMy9ObfcKRZ3mhgEvVnecivyw+68hJJz8S hMheGYSELLLBqmbo5V7q6r4IbHocouotoA7K3w1KZDmDrcx4WeURNqyIwxzqF1E2wE WawIDWfWyUSJD8eluHf7iNmFkr+6fxGWLdyym+zKnltkXIl5VfGxwDfpSOmuqFPKmA FwYNAiHpuNvpVs6msKaFyMgKU1HBPUNEXCPx/9bL0ydROtyf+EVbVkolms0M6YeIes brg80w6CChzyQ==
Date: Mon, 19 Jul 2010 07:33:45 +0200
From: Kaspar Brand <ietf-certid@velox.ch>
User-Agent: Thunderbird/3.x
MIME-Version: 1.0
To: certid@ietf.org
References: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp>
In-Reply-To: <201007170054.o6H0s28q023476@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [certid] Need to define "most specific RDN"
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, 19 Jul 2010 05:35:44 -0000

On 17.07.2010 02:54, Martin Rex wrote:
> I do _not_ like the idea to make multiple CN= matching part of the
> standard.  The clients that match on more than one CN= are quite few
> (mine does), it never was part of any standard or suggestion

Nor would I consider the wording "the (most specific) Common Name field
in the Subject field of the certificate" from RFC 2818 to be
authoritative or "part of a standard". Some implementers apparently
attached much importance to "(most specific)" in their reading of this
text, but I still wonder what the real intention was when that term was
added to / coined in RFC 2818. [1]

Just to be clear: I'm not advocating that CAs put multiple CNs into the
subject DN: I'm completely fine with having a strong recommendation in
section 3 ("Representation of Server Identity") for a single CN in the
subject only.

In section 4 ("Verification of Server Identity"), however, I think we
should expressly put an end to the debate of what "(most specific)" in
RFC 2818 really means, otherwise the confusion is perpetuated. Of the
two solutions - either explain at great length how it is to be
understood DER-encoding-wise, or just go loop over all CNs -, the latter
definitely seems preferrable to me.

Kaspar

[1] Looking through
http://www.imc.org/ietf-apps-tls/mail-archive/maillist.html didn't give
a clue, unfortunately.