IETF Logo Mail Archive

Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

Joe Orton <jorton@redhat.com> Thu, 13 May 2010 07:26 UTC

Return-Path: <jorton@redhat.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 426203A6BA7 for <certid@core3.amsl.com>; Thu, 13 May 2010 00:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.699
X-Spam-Level:
X-Spam-Status: No, score=-107.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 y4-2pLvsV1tR for <certid@core3.amsl.com>; Thu, 13 May 2010 00:26:04 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id C88433A6BB5 for <certid@ietf.org>; Thu, 13 May 2010 00:20:33 -0700 (PDT)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4D7KH2N007012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 03:20:17 -0400
Received: from turnip.manyfish.co.uk (vpn-9-55.rdu.redhat.com [10.11.9.55]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4D7KEEk022635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 May 2010 03:20:16 -0400
Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.69) (envelope-from <jorton@redhat.com>) id 1OCSiL-0000mT-Vq; Thu, 13 May 2010 08:20:14 +0100
Date: Thu, 13 May 2010 08:20:13 +0100
From: Joe Orton <jorton@redhat.com>
To: Love =?utf-8?Q?H=C3=B6rnquist_=C3=85strand?= <lha@apple.com>
Message-ID: <20100513072013.GA2725@redhat.com>
References: <4BEB0FBF.5070502@KingsMountain.com> <4BEB2DC7.5020409@stpeter.im> <B6E22FEA-57C7-46D9-B820-DA51936C6E71@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B6E22FEA-57C7-46D9-B820-DA51936C6E71@apple.com>
User-Agent: Mutt/1.5.20 (2009-08-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21
Cc: certid@ietf.org
Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03
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: Thu, 13 May 2010 07:26:05 -0000

On Wed, May 12, 2010 at 03:58:23PM -0700, Love Hörnquist Åstrand wrote:
> 
> 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre:
> 
> >> So I'm not sure right now what to say about that. I suspect we can still
> >> stipulate that the only RDN having attr type of CN that we'll pay
> >> attention to is the one at the far end of the RDN sequence comprising
> >> the DN.
> > 
> > We can stipulate that, but is it realistic?
> 
> Yes, since that's what RFC 2818 said.

RFC 2818 says that you use the most specific CN RDN.  Not the most 
specific RDN, iff it is a CN.  That is completely different.

The stats I ran said that maybe 10/20% of existing certs place the CN 
somewhere other than the most specific field.  Who out there is going to 
change their software to implement a CN matching algorithm which breaks 
interop with 10/20% of SSL servers?

Regards, Joe

v2.8.7 | Report a Bug | By Email