Re: [TLS] Summarizing identity change discussion so far
Kyle Hamilton <aerowolf@gmail.com> Thu, 17 December 2009 23:16 UTC
Return-Path: <aerowolf@gmail.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 F3AD528C180 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 PbH6jRp9HNod for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:16:54 -0800 (PST)
Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id C29233A6A10 for <tls@ietf.org>; Thu, 17 Dec 2009 15:16:41 -0800 (PST)
Received: by pzk6 with SMTP id 6so1813018pzk.29 for <tls@ietf.org>; Thu, 17 Dec 2009 15:15:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=yz7LLTfs11pq1kHBBA0tgGoZY+2C2s027Nr4dCycZUw=; b=HDSvf8ifYbVduRB/oD2s/4L2JjlVXKWO4Xo+vGNO/EbKS450XB3uiDIAvpeFoI3Ej5 onMfjOmSbA96vPBSAgSCt3blukQmm6Ztl6X0v+cie7HQqCrTDfBo8FCeieWRgX3a0KQU Xt3tzLuhqmL/QhHYJNI2zX4znhIr9FdEvymPA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JiF7dLmgZO1k5yknBArXCcwJmaN4AyzrS0fmpyYybscODCJZIeLnW9SGlRWtKtQ1ss 0TdOiKBkx+BW2uj0OAuzzLTVNaXgCQnohgJ4GEPrbWYNsL2fvuSbs+DCeMFtMB6FrOJJ mzCRU8pFxIJcNG9kA4fP6xqk0p1Kic8x+edZg=
MIME-Version: 1.0
Received: by 10.143.153.38 with SMTP id f38mr2092851wfo.27.1261091759347; Thu, 17 Dec 2009 15:15:59 -0800 (PST)
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Thu, 17 Dec 2009 15:15:59 -0800
Message-ID: <6b9359640912171515t1ef6f336id71c2ee3baec5c83@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: Pasi.Eronen@nokia.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
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:16:57 -0000
On Thu, Dec 17, 2009 at 2:06 PM, <Pasi.Eronen@nokia.com> wrote: > Well, the text I proposed just said "different certificate", not > "memcmp". I know that's a bit vague, but "in accordance with PKIX > [PKIX]" is not very precise either, and would need a more specific > reference to where exactly the details are (for example, it can't mean > comparing the Subject field, since PKIX allows leaving it empty). PKIX allows (and, actually, encourages) Subject to be empty, but only in the case where subjectAlternativeName isn't. There are also cases where subjectAlternativeName can contain the old Subject, and a new Subject nym is included in the certificate. > And the certificate might have extensions (certificate policies, > subject directory attributes, extended key usage, etc.) where changes > between API calls could surprise the application. Then, for those applications, they should be rewritten to terminate the active session when the policies associated with the certificate change (more specifically, when a particular eKU that the application requires in the certificate associated with the connection is no longer asserted by the peer, when the certificate policies change, or whenever some condition set by the application developer is no longer met). Or, the underlying libraries should enforce this (if asked). Either way, terminating the connection and invalidating the session is the easiest way to enforce that all certificate changes come through the "initial request authenticator/authorizer" code path, which is where all of those policies are verified. > Here's another shot at that paragraph (also including suggestions > from Marsh's email): > > TLS implementations SHOULD offer the applications the option to > disable renegotiation completely. > > To make life simpler for applications that do not expect the peer's > certificate to change once it's been authenticated, TLS > implementations may also wish to offer the applications the option > abort the renegotiation if the peer tries to authenticate with a > different certificate and/or different server name (in the > server_name extension) than was used earlier. However, enabling > this option by default for all applications could break existing > applications that depend on using renegotiation to change from one > certificate to another. (For example, long-lived TLS connections > could change to a renewed certificate; or renegotiation could > select a different cipher suite that requires using a different > certificate.) I'd agree with that, if it were simply a matter of "certificate" or "server name". But, it's not. This is a matter of identity, and the identity matching rules of PKIX -- since PKIX is what defines the content and schema of the X.509 certificates presented by both pairs -- are what must control, not simply any arbitrary decision by the TLS WG. Nor can even any decision made by the TLS WG chair control. (Certificate type 0 is X.509/PKIX. Certificate type 1 is OpenPGP -- oh, but wait, we don't have anyone here to advocate the matching rules for its particular IANA assignment... Each type, 0 and 1, has different matching rules. The rule for verifying the token that is presented MUST be defined, in TLS, as the rule defined by the document that defines the format of the token, or else the TLS WG is once again putting a policy decision into a technical specification, restricting the kinds of authentication which can be used.) -Kyle H
- [TLS] Summarizing identity change discussion so f… Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Eric Rescorla
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Stefan Santesson
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- [TLS] OpenPGP Certs for TLS [was: Re: Summarizing… Daniel Kahn Gillmor
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Nelson B Bolyard
- Re: [TLS] Summarizing identity change discussion … Nasko Oskov
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)