Re: [TLS] HTTPS client-certificate-authentication in browsers

Henry Story <henry.story@bblfish.net> Wed, 27 July 2011 21:02 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 0F7CD11E80DD for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.435
X-Spam-Level:
X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 T1K-n9Y8Lxg5 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:02:37 -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 9B59C11E8082 for <tls@ietf.org>; Wed, 27 Jul 2011 14:02:37 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1274329wyj.31 for <tls@ietf.org>; Wed, 27 Jul 2011 14:02:29 -0700 (PDT)
Received: by 10.227.173.204 with SMTP id q12mr213855wbz.86.1311800549744; Wed, 27 Jul 2011 14:02:29 -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 gd1sm230132wbb.10.2011.07.27.14.02.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 14:02:28 -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: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp>
Date: Wed, 27 Jul 2011 23:02:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3D95433-BDC2-45CB-A32D-0908D9B618A6@bblfish.net>
References: <201107272029.p6RKTFNA008101@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:02:39 -0000

On 27 Jul 2011, at 22:29, Martin Rex wrote:

> Anders Rundgren wrote:
>> 
>>> If you want to do application-level session management, then you
>>> ought to do application level session management, and NOT try to
>>> mess around and interfere with Single Sign-On functionality at the
>>> transport layer.
>> 
>> Sure, but the question was to use client-side PKI in such an application.
> 
> TLS does *NOT* provide any PKI functionality to applications,
> never did, never will.
> 
> If you need that, you'll have to newly build it form ground up,
> potentially re-using existing technologies and protocols
> (such as PKCS#7/CMS).

Yes, you can for example use X509 as such legacy technology, and with
simple WebArchitecture build a distributed public key infrastructure.
You do this by tying public keys to URIs and building a web of trust through
links between documents, using insights from the work done around the world in
the semantic web space.  When this is done it turns out that one can
magically re-use all the existing technology, including Client Certificates
to ones advantage. All that is explained quickly at http://webid.info/ 
Though if you want the philosophical background to this in detail you can
see the third presentation on my home page.

Henry

Social Web Architect
http://bblfish.net/