Re: [TLS] Summarizing identity change discussion so far

Michael Gray <mickgray@au1.ibm.com> Thu, 17 December 2009 23:13 UTC

Return-Path: <mickgray@au1.ibm.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 DC9E63A69D4 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level:
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4]
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 gf3xfGT7v3RW for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:13:35 -0800 (PST)
Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by core3.amsl.com (Postfix) with ESMTP id D5DC83A682F for <tls@ietf.org>; Thu, 17 Dec 2009 15:13:33 -0800 (PST)
Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBHNAABj027071 for <tls@ietf.org>; Fri, 18 Dec 2009 10:10:10 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHNDHHo1855684 for <tls@ietf.org>; Fri, 18 Dec 2009 10:13:17 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBHNDHXd001405 for <tls@ietf.org>; Fri, 18 Dec 2009 10:13:17 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBHNDH8n001398; Fri, 18 Dec 2009 10:13:17 +1100
In-Reply-To: <4B2AB65B.6080704@extendedsubset.com>
To: Marsh Ray <marsh@extendedsubset.com>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF7CF5C573.88CEBD1C-ON4A25768F.007E6CCE-4A25768F.007F8A5A@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Fri, 18 Dec 2009 09:13:04 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 18/12/2009 10:20:22
MIME-Version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: base64
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 23:13:52 -0000

Marsh Ray <marsh@extendedsubset.com> wrote:
> 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".

Yes I think I will flip-flop on this as on second thought I do not see how
identify matching can be -simply- precisely defined in this case with PKIX
and what many will feel is a notion of identity.  If we stick to simply
matching the TLS Session Parameter of “peer certificate” as Pasi has
suggested then that might be the best we can do.

Anything that involves [PKIX] would be an appropriate place to use the term
-magic-  :-)

- Mick