Re: [TLS] Summarizing identity change discussion so far

Kyle Hamilton <> Fri, 18 December 2009 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 592B43A69EA for <>; Thu, 17 Dec 2009 17:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r0dHOZzvqjD1 for <>; Thu, 17 Dec 2009 17:15:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8827E3A67A1 for <>; Thu, 17 Dec 2009 17:15:47 -0800 (PST)
Received: by pzk6 with SMTP id 6so1866397pzk.29 for <>; Thu, 17 Dec 2009 17:15:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=588WEU9dnbmwkAgI/b7cKuuooS5v2yq6dIW/u6N+2wc=; b=D9sm0gCtbFU4//rMHGTBlJChOVQV1o17HU4PsVnI9YGV2wQHr9qrg+xZ+ttxbQVo83 FtHQU9jkalfAmbhWY//KV+MQ75JX5xuvHJcIKYYvVe+FxNo2CZTIiaLbhAg0zbfJ6A69 9b1+ZGB6DDK7BaIWuqFUPBxCAVkBpbO4KykGw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m2Xayvp1PqvKmbv0WGGXV0LT1PQA5INshLL74V6hKgIYIH4veC4uVSn9VAedqNvKR/ t87fkg4DGUrK+AyfNXhDquoFrgE6NpiRFyH0Y06979jKZj8h2GRZwFamrHdvK9rBlKd6 ZqUK8SPsGjDRZB3xyXb7pL8RwGFu1mhLLb+mg=
MIME-Version: 1.0
Received: by with SMTP id 30mr2159901wfe.115.1261098930722; Thu, 17 Dec 2009 17:15:30 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 17 Dec 2009 17:15:30 -0800
Message-ID: <>
From: Kyle Hamilton <>
To: "Blumenthal, Uri - 0662 - MITLL" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] Summarizing identity change discussion so far
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2009 01:15:48 -0000

I'll just state this: I believe that defining the semantics of
identity credentials provided during the course of the TLS protocol's
execution is NOT within the legitimate realm of the design of the TLS
protocol.  TLS explicitly references PKIX, and PKIX is really the only
place that uses 'identity', but (on further reading) it doesn't
describe precisely what 'identity' is.

So, I'll take a stab at a potential guidance for those who don't have
the time to research in-depth, taking into account Pasi's and
everyone's ideas: If there is a match between ANY one of the new
certificate's Subject/sAN and the old certificate's Subject/sAN,
including all path components in the same order for that entity, AND
is issued by the same authority, it SHOULD be regarded as being the
same identity, though exceptions will undoubtedly exist.  Differences
in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as
well, to ensure that the new certificate is valid for the kind of
connection and transactions being performed.

The only thing that SHOULD modify the default behavior (defined as
"all 'MUST*' and 'SHOULD*' but no 'MAY*'") is the implementation of a
security policy.  If such a security policy exists but has no
information on this topic, the defaults SHOULD control (unless there's
a very, very good reason not to).

-Kyle H

On Thu, Dec 17, 2009 at 4:50 PM, Blumenthal, Uri - 0662 - MITLL
<> wrote:
> I'm jumping in late (what would you expect from somebody on vacation :-), but most of what I may want to say is already eloquently put by Kyle.
> I agree with him points - including (and especially!) those made about WG defining & hard-coding inflexible policies (stated in subsequent postings).
> ----- Original Message -----
> From: <>
> To: <>
> Cc: <>
> Sent: Thu Dec 17 16:37:15 2009
> Subject: Re: [TLS] Summarizing identity change discussion so far
> On Tue, Dec 8, 2009 at 1:13 AM,  <> wrote:
>> (wearing Area Director hat)
>> - We recommend that TLS libraries SHOULD provide identity matching
>> (with memcmp, abort handshake if changed) functionality to
>> applications, and SHOULD allow applications to enable/disable this
>> functionality.
> No, identity matching SHOULD be done in accordance with PKIX.  memcmp
> is not at all sufficient.
> However, I would support the following:
> - TLS libraries SHOULD provide identity matching services between and
> throughout renegotiation handshakes.  Libraries SHOULD implement this
> in accordance with PKIX [PKIX], but MAY do so with a direct memory
> comparison.  Implementors are cautioned that this latter approach does
> not provide for changing the cipher parameters -- such as a
> renegotiation with an EC or DH certificate after identification with
> an RSA certificate.  If the identity matching service fails to match
> the identity, implementations MUST abort the handshake with a fatal
> bad_certificate alert.
> -Kyle H
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list