Re: Client Certificates - re-opening discussion

"" <> Mon, 21 September 2015 08:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 568191A8969 for <>; Mon, 21 Sep 2015 01:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hHJ5JLlz1xJL for <>; Mon, 21 Sep 2015 01:16:45 -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 791351A8955 for <>; Mon, 21 Sep 2015 01:16:45 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZdwDc-0000wx-KC for; Mon, 21 Sep 2015 08:13:00 +0000
Resent-Date: Mon, 21 Sep 2015 08:13:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZdwDV-0000w7-7w for; Mon, 21 Sep 2015 08:12:53 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZdwDS-0001dO-Sp for; Mon, 21 Sep 2015 08:12:52 +0000
Received: by wicge5 with SMTP id ge5so104187338wic.0 for <>; Mon, 21 Sep 2015 01:12:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=PG9OvTX9dn+vzrFctsGkl31Q5fWN+axHCmc9AomYJjY=; b=aZukEgG8iNreKMgafsaot1dG9zB38oUf16yAcasyFO1JLYrwmaxTgDglLPyEK99zau VoZdR9TPIrisehiJTXb4ZSaeMSXYE83rJAhn44WrjCBU1It1/6tOGIW9kUDQnKAAXRNm jlF2mPXXkhk0ijVHiIaHAkyL0KWH74mlRCN/Dzbe5Ef9VoCEe950xkO87WomkFsnXEUI ztlWf4//Gci4dJ5a6NgmCNEgM51w3OAkVHi2H7UfWLKHUx3I1f0HlIiYTHoTbjRGuvNv COAqUsf4WzOr7+IlECde2x8zv7PSmlCvHJVIH7suY+SlkCSy3cpnspCdS3r9PH+EkjVg H8rw==
X-Gm-Message-State: ALoCoQlBKQ+arKwWFaEny/7biwF1ZUay/DapCY9M9gd6nD0X5tW5pq5dVhqP/sBMSk6B78L3k2qn
X-Received: by with SMTP id hk8mr11404858wib.47.1442823144252; Mon, 21 Sep 2015 01:12:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id pu6sm22763786wjc.34.2015. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Sep 2015 01:12:23 -0700 (PDT)
From: "" <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08556519-7A3D-48EA-95CC-47B57735CDBF"
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Date: Mon, 21 Sep 2015 09:12:21 +0100
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <> <>
To: HTTP Working Group <>
In-Reply-To: <>
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.462, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1ZdwDS-0001dO-Sp cc0bd32e08ab4a6e27867181b48ca144
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30242
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

First I am really thankful for this discussion as  I had not been able
to understand what exactly the problem with client certs and 
HTTP/2.0 were. This is very helpful.

> On 21 Sep 2015, at 07:09, Yoav Nir < <>> wrote:
>> On Sep 21, 2015, at 6:30 AM, Mike Bishop < <>> wrote:
>> Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.
> So if this working group rejected renegotiation (which worked), why would this new mechanism be acceptable?
>> Renegotiation, however, attempted to bring many functions together, some of which made the TLS WG uncomfortable.  This PR creates a more scoped feature targeted at only the presentation of client credentials to the server, which is the feature we actually need.
> That’s a good thing, but IMO it doesn’t matter to httpbis.
>> It sounds like, in part, we have different understandings of why renegotiation was prohibited in the first place.  You argue it was prohibited because there’s some inherent indeterminacy, particularly if the application layer doesn’t stall.  I’d argue that that indeterminacy can and should be handled by the application that knows what resources care about the client’s identity and which don’t.
> Having the application layer stall doesn’t help. The client requests resources A, B, and C. Resource B requires client authentication. By the time the application stalls, waiting for the client authentication, resources A and C may not have been noticed, or the requests may have been serviced, with A and C in a buffer waiting to be encrypted, or the requests may have been serviced and encrypted and on the way back to the client. A and C may be received in the authenticated or the non-authenticated context. Imagine, for example, that A is a bit of HTML that says “Hello, guest” in the unauthenticated context, or “Hello, Mike” after authentication. You can get the certificate picker and still see the “Hello, guest” on the page.
> What’s more, I think HTTP authentication has the same issue. If one request gets processed and generates a 401 with WWW-Authenticate, other resources may or may not have been serviced. You can fix this by carefully designing the application so that you don’t load resources that are different based on state at the same time as the authentication is going on.

This seems to show that this is not a client certificate problem but another problem.

In a data driven web, where the client generates the page in Single Pages apps (SPA), the 
identifying  information about the user would be in a seperate resource. As that information 
became available to the SPA would redraw itself, to take that into account.

The way you state the problem it seems to be related to a resource being both public
and protected simultaneously, with the protected version of the resource returning more 
information than the public one. How would a web server indicate to the client that
it should re-download certain resources that now contain more information? Is this even
good practice?  Those are interesting questions.

>> If multiple requests cause the server application to query the HTTP layer for the client’s certificate, then all those requests will wait until the client authentication has completed, just as they would have on a non-multiplexed connection.  Where multiplexing adds a new wrinkle is that, under HTTP/1.1, those connections that didn’t require authentication would proceed without interruption until they’re used for a protected request.

makes sense to me.

>> Perhaps the fundamental question is, when does the client need to know that the server had seen the certificate prior to generating the response?  In HTTP/1.1 over TLS 1.x, it could know that the server had seen it, but couldn’t know whether the server cared.
> Does it matter for the client?
> Yoav

Social Web Architect