Re: [certid] Domain Components

Martin Rex <mrex@sap.com> Wed, 23 June 2010 01:02 UTC

Return-Path: <mrex@sap.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 6385B3A680F for <certid@core3.amsl.com>; Tue, 22 Jun 2010 18:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.902
X-Spam-Level:
X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 IWGsAO2rM+EY for <certid@core3.amsl.com>; Tue, 22 Jun 2010 18:02:44 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 866673A67EA for <certid@ietf.org>; Tue, 22 Jun 2010 18:02:40 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5N12jcE013881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jun 2010 03:02:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006230102.o5N12hwP011034@fs4113.wdf.sap.corp>
To: michael@stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 23 Jun 2010 03:02:43 +0200 (MEST)
In-Reply-To: <4C1FD3CD.8090009@stroeder.com> from "=?ISO-8859-1?Q?Michael_Str=F6der?=" at Jun 21, 10 11:04:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: phoffman@imc.org, certid@ietf.org
Subject: Re: [certid] Domain Components
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 23 Jun 2010 01:02:45 -0000

=?ISO-8859-1?Q?Michael_Str=F6der?= wrote:
> 
> Michael Ströder wrote:
> > Paul Hoffman wrote:
> >> 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.
> > 
> > That's fine for me too.
> 
> But to make that more clear in this context: The draft should not discourage
> completely using DCs in the subject-DN. It should only recommend not to encode
> the server's hostname in the DCs.

Nope.  It is important to strongly recommend to clients to _NOT_
check the server endpoint identity based on DC components, that is
the important issue.  There is no known sensible, consistent
and reasonably safe interpretation of DC name components
as the hostname for a server endpoint.

No implementation that doesn't have such code should add it,
and existing implementations with such code should think about
removing it or disabling it by default.

-Martin