Re: Client Certificates - re-opening discussion

"" <> Mon, 21 September 2015 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9774B1AD34F for <>; Mon, 21 Sep 2015 11:10:26 -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 FVk3wzam3pyo for <>; Mon, 21 Sep 2015 11:10:24 -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 CA2821AD182 for <>; Mon, 21 Sep 2015 11:10:23 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Ze5UL-0000qv-9u for; Mon, 21 Sep 2015 18:06:53 +0000
Resent-Date: Mon, 21 Sep 2015 18:06:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Ze5UA-0000q9-Fg for; Mon, 21 Sep 2015 18:06:42 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Ze5U8-0005b1-G9 for; Mon, 21 Sep 2015 18:06:41 +0000
Received: by wicfx3 with SMTP id fx3so123378101wic.0 for <>; Mon, 21 Sep 2015 11:06:13 -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=z1CgYud9WczMGC/yOll7ykWlHogBHyQRUVspVNZBClo=; b=eMjqfVWw0fiYu/z860P24f8iOO9OfL7SZv7BbCADGt+HJVae20j9seJYW8mj8+VVMc I2RwcvGdfARSfhxqy8UYBykjG/qtuQASff8oNqY0yqS2g0vdWprC49x0GwsAVDGskuaJ dMvjaFODqKW6KT/Bl6JyI07NZyI8ot+dh9Xcj2+80+sIXPBqSH25dqy12oXByRTwlcN5 pBX0uODsUT/DTq/tiMDtgNMeZg/KehfBWAHqO5NJhi5FeOOuKWk549eHgxlKiAGrTWLV rboyw2FuC7SL790eig+C//5RHDlHgJlOPrxCSHW2atd+J6Kgib6vk9LQF9/590ZzfF3S aeoQ==
X-Gm-Message-State: ALoCoQmB2Tyob4oG4ZGoe5M7doZYq+YAasgS+WNcF5EyTM1N95s9qwEW/DEGkJyO0Z5sNYIcSt4J
X-Received: by with SMTP id da4mr28596416wjc.41.1442858773660; Mon, 21 Sep 2015 11:06:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id bs8sm25294861wjc.47.2015. for <> (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Sep 2015 11:06:12 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "" <>
In-Reply-To: <>
Date: Mon, 21 Sep 2015 19:06:11 +0100
Content-Transfer-Encoding: 7bit
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.2
X-W3C-Hub-Spam-Report: AWL=0.442, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1Ze5U8-0005b1-G9 4de79c643d998eb6c74a4be9ac843db3
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30253
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 21 Sep 2015, at 17:58, Kyle Rose <> wrote:
>> 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.
> Right, and the inability to support this leads to a bunch of
> kludgey-feeling solutions, like 421s. This situation was always
> possible with HTTP/1.1, but is a lot more likely with H2.

So there is another question: are the two incompatible? 

It may also be worth having the old solution for a transition period,
until new answers come up. Then as they prove themselves, which should
be easy as they will be a lot more flexible ( but also therefore in
danger of more misimplementations ), the older TLS certificate
system can go away.

> Pushing the authentication into the application layer seems like it
> could be cleaner. Provide browser support for setting a
> CertificateVerify header (e.g., based on a signature of the channel
> binding), something that can be cached by the client and server and
> reused on all relevant streams over the same connection.

The idea would be for example that a 401 with a 

 WWW-Authenticate: Certificate, upload="/certs" 

The client could then POST the (x509?) certificate to that location,
and receive a Location: header containing a URL that it could re-use
on future connections, and which it could use for authentication 
with something like draft-cavage-http-signatures [1]

The nice thing, is that this would allow one to also use URLs
of certificates  on remote servers, to avoid the whole process of 
certificate uploads. ( but the problem of people not having a
server would be solved by the POST described above )

Also this provides an easy way to disable certificates by removing
them from that URL.

You could then further do content negotiation on that URL and allow
many different formats to be returned, enabling a 
move to JSON certificate formats a la JOSE or based on

> Signalling
> for "you need to authenticate" and sending the client certificate to
> the server would then be entirely at the application layer, possibly
> with the support of HTTP status codes, and TLS client certificate
> authentication wouldn't be used in this case.
> This sort of application layer approach may also make a better client
> UX more natural, by moving the logic for prompting the user for a
> certificate into the web app UI.

Would that require the client to also be able to independently get
access to the channel binding? 

Wether the WebAPP UI can do this will depend on wether the WebApp
can intercept the 401's sent by the server. This is the type of thing
that could be done by ServiceWorkers [2] I am told, but figuring that
out from the spec is not really easy. I am going to send a message
to the WebApps group to verify that this is possible across origins.

Still even if WebApps were able to do this authentication across
origins, it would still be very useful for the browsers themselves
to be able to authenticate to a remote origin without going through
these WebApps, so that one could test out resources outside of an 
App. Ie. I think there will always be a need for browsers to provide
cross origin authentication mechanisms. WebApps will be more flexible
to innovate, but the successful ones should be rolled into the browser.



[2] Which just started gone into Candidate Recommendation and feedback is 

> Kyle

Social Web Architect