Re: [TLS] Summarizing identity change discussion so far

Marsh Ray <marsh@extendedsubset.com> Thu, 17 December 2009 22:53 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985943A69D4 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 14:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 tc4e8E-Gzy-h for <tls@core3.amsl.com>; Thu, 17 Dec 2009 14:53:33 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D0DDC3A67E5 for <tls@ietf.org>; Thu, 17 Dec 2009 14:53:33 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NLPDi-000K2E-GJ; Thu, 17 Dec 2009 22:53:18 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 352C26678; Thu, 17 Dec 2009 22:53:16 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX193z5kitAlA42mnclOul+6U7zk3jP7Y1Gs=
Message-ID: <4B2AB65B.6080704@extendedsubset.com>
Date: Thu, 17 Dec 2009 16:53:15 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Michael Gray <mickgray@au1.ibm.com>
References: <OF8FF151E8.A53BE95F-ON4A25768F.007B3729-4A25768F.007C7597@au1.ibm.com>
In-Reply-To: <OF8FF151E8.A53BE95F-ON4A25768F.007B3729-4A25768F.007C7597@au1.ibm.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Summarizing identity change discussion so far
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2009 22:53:34 -0000

Michael Gray wrote:
> 
> Yes the problem is defining what an identity change is precisely.  We know
> that CA's load all sorts of stuff in to certificates as part of the DN etc
> and the same identify could have multiple certificates, and could be
> identified by multiple CAs.  If we say that in TLS we are going to check
> identity then it has to be very precisely defined, or extremely vaguely
> defined so that the implementation can not be accused of non compliance or
> invalid/suspect identity matching.  Perhaps it needs to be a vague as
> possible so that TLS implementation can simply push it back to the
> application layer in practice

It does seem that in many cases a memcmp() of the certificates is
entirely appropriate. It's certainly a well-defined comparison and it
avoids getting the TLS spec overly wrapped up in the details of PKIX.

As long as people don't start claiming memcmp() is some "official TLS
definition of identity".

- Marsh