Re: Client Certificates - re-opening discussion

"" <> Mon, 21 September 2015 15:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E684C1B333C for <>; Mon, 21 Sep 2015 08:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BHby0B9K7v5Q for <>; Mon, 21 Sep 2015 08:47:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65C001B3336 for <>; Mon, 21 Sep 2015 08:47:48 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Ze3GS-0007Gp-VF for; Mon, 21 Sep 2015 15:44:24 +0000
Resent-Date: Mon, 21 Sep 2015 15:44:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Ze3GN-0007F5-JU for; Mon, 21 Sep 2015 15:44:19 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Ze3GM-000765-21 for; Mon, 21 Sep 2015 15:44:19 +0000
Received: by wicge5 with SMTP id ge5so121763196wic.0 for <>; Mon, 21 Sep 2015 08:43:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=hNlBlthBMguqbzPoGvCsUz9rSlp/F5Oj2VPGVXmML4U=; b=NB0QliKKFptO6r3d23znRrUUXO1slJ5WRLZCmz7yUNsiRYnEhAwGmWRNhGr4J1BjmJ SsKfHgc1omsJKU0Xjq9P4FwzX2SmIZ7WSKVMzKLffoezpoq57JKFD+vvKhPTA+xwWeem 2vV+eW5kxReI1QZRzr9zfuhAmxAzr26CwiASq64Tx4ft91FakGRPVbKxGYCm4wkVg0Sj RKtlO6erOzgxhC1asLPzWOEgkF8NXjnPl42qddr0iBs32NljFxQYqOUrlZpiivgv1rzz JgnLPLNJyaDMIHnIyKK2X4wlJ4A4uXHwpdUCKeEnw/KYBsPNRX67HfSF6qrWKQjiU6E+ yVNA==
X-Gm-Message-State: ALoCoQkhXpaIZDld5PI1lo7DTV1fL1GYp52EaEyi9mYhrRtBPqDV+HCg/n6eKwtDq6dKbSIDDi9x
X-Received: by with SMTP id ef8mr18346945wjd.103.1442850231352; Mon, 21 Sep 2015 08:43:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id lb10sm5205618wjc.9.2015. for <> (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Sep 2015 08:43:50 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "" <>
In-Reply-To: <>
Date: Mon, 21 Sep 2015 16:43:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <> <> <> <> <> <>
To: HTTP Working Group <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.1
X-W3C-Hub-Spam-Report: AWL=0.463, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1Ze3GM-000765-21 08c12ef4eb6b2085296cf1936a21a63f
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30249
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 21 Sep 2015, at 15:28, Kyle Rose <> wrote:
>>> The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication
>> Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both require different client certs. Depending on which tab the browser load first, the one or the other cert gets loaded in, leading the other site to fail since the cert is not accepted.
> Yeah, this is a huge issue that doesn't appear in HTTP/1.1. It sounds
> to me like the real problem is trying to shoehorn application-layer
> client authentication into the transport layer.

How is this different from say if one authenticated to each resource
using public keys at the HTTP layer [1]. We could imagine here A, B and C,
being resources on the same server even with A only accessible by somone 
who can prove he is over 18, the other by someone how is a member of this 
working group, ( provable using either a WebID or an OpenID ), etc.... 

There are two signals the server can set up to help the user agent select
a certificate: A 401 not Authorized, and perhaps a link to an access
control resource that would describe who can have access [2].  The client
needs some logic to help select a certificates or credential to respond 
to the request while putting the user in control, and without being too
much of a pain.

As I understand Martin Thomson  suggested an HTTP header

WWW-Authenticate: Certificate

sent at the HTTP layer, that could then start the certificate 
connection at the TLS layer.  The client could also try to narrow 
down from the ACL list to see if it is even worth bothering the 
user to ask him for a Certificate, and perhaps warn him that some 
links cannot be  followed, because of the lack of access.

It is true that authentication at the TLS layer is much rougher, as 
I think the client can only authenticate with 1 certificate not more,
per connection.

But part of the problem you mention has more to do with the logic of
the user agents credential selection and the problems of protected
resources across origins ( which everybody is familiar when looking
at YouTube links that are viewable in one country but not in another ).


[1] As suggested by one of the following 

• Andrei Sambra's first sketch authentication protocol   
• Manu Sporny's more fully fleshed out HTTP Message signature

[2] Following work described here for example

> Kyle

Social Web Architect