Re: [TLS] HTTPS client-certificate-authentication in browsers
Henry Story <henry.story@bblfish.net> Wed, 27 July 2011 21:56 UTC
Return-Path: <henry.story@bblfish.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B55E8004 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level:
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7txhmpmPXZa for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:56:53 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F85E8001 for <tls@ietf.org>; Wed, 27 Jul 2011 14:56:53 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1304113wyj.31 for <tls@ietf.org>; Wed, 27 Jul 2011 14:56:52 -0700 (PDT)
Received: by 10.227.55.67 with SMTP id t3mr269230wbg.90.1311803812412; Wed, 27 Jul 2011 14:56:52 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id fn12sm257642wbb.38.2011.07.27.14.56.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 14:56:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
Date: Wed, 27 Jul 2011 23:56:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6030F823-5D49-40FD-B619-3C9FCF9E2260@bblfish.net>
References: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1244.3)
Cc: tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 27 Jul 2011 21:56:54 -0000
On 27 Jul 2011, at 23:29, Martin Rex wrote: >> >> >> They find HTTPS' way of doing that intrusive. >> >> On the web you logoff from (or by) the server. >> >> Naturally logoffs must trickle down to clients >> if they have logged-in using HTTPS CCA otherwise >> they are de-facto logged-in due to the TLS caching. > > "Logoff" is a pure server-side concept with respect to server-side > state. A logoff concept that requires cooperation from the client > is technical nonsense. Any server-side destruction of backend-state > associated with particular clients must work completely independent > of what the client does. Early consensual destruction of backend > state if the client explicitly asks for it is OK. But any > server-initiated "logoff" concept that involves the client > amounts to technical cluelessness. why is that? Why can't the client log itself off. That would be much better for the user, as he would be in control of his identity. This could be done easily by a browser both with cookies and with TLS: - with cookies: the browser should tie every cookie and state to a user identity. When the user switches identity, the cookies stop getting sent. For the server that ends up being the equivalent of a log-off. - with TLS the client breaks the connection, and re-established a completely new one. Henry Social Web Architect http://bblfish.net/
- [TLS] HTTPS client-certificate-authentication in … Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Saint-Andre
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Paul Wouters
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Daniel Kahn Gillmor
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Matt McCutchen
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Stefan Winter
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Nikos Mavrogiannopoulos
- Re: [TLS] EU cards Yoav Nir
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Wan-Teh Chang
- Re: [TLS] EU cards Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… t.petch
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex