RE: Client Certificates - re-opening discussion

Mike Bishop <> Fri, 18 September 2015 18:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBF3A1B3148 for <>; Fri, 18 Sep 2015 11:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Y1hB2BeqyxqC for <>; Fri, 18 Sep 2015 11:34:44 -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 1361B1B313D for <>; Fri, 18 Sep 2015 11:34:44 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zd0SL-0000Dk-EU for; Fri, 18 Sep 2015 18:32:21 +0000
Resent-Date: Fri, 18 Sep 2015 18:32:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zd0SE-0000Cx-K3 for; Fri, 18 Sep 2015 18:32:14 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zd0SC-0004QY-JB for; Fri, 18 Sep 2015 18:32:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3jbG1RzlFJrGBoIRox6fCAiVbI3rNsZIudoa1G+plH8=; b=Ugv++TKrhDSr+8S7Ni8c9bjq8KBXjlMbUOXL5pGZh6XotvtYoRylAT4XYl7Qel225CzX1fZ2hGgWirrtX2s/7KN0Y1ZSa2AjgNqywqf45YDPWVC+WAuQqHUC6lbCMiS8VEsUlkJa+fstCcfZtRCtobxt2kAivZD+OFBqb1ouIRY=
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 18 Sep 2015 18:31:39 +0000
Received: from ([]) by ([]) with mapi id 15.01.0268.017; Fri, 18 Sep 2015 18:31:39 +0000
From: Mike Bishop <>
To: Mike Belshe <>, Mark Nottingham <>
CC: Henry Story <>, HTTP Working Group <>
Thread-Topic: Client Certificates - re-opening discussion
Thread-Index: AQHQ8ZZXEEnFRnQG4U+imwUG9Fc1t55ChnhKgAATo4CAAAFT4A==
Date: Fri, 18 Sep 2015 18:31:39 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:5::484]
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1249; 5:39qEZEy+lL04VLDNTXL0qup4DUUpAdH7BWVCChhJnEcyYoORvUrfufgy+kM89PNadN0aZCbe5tfgOk1Vm86ETOuUYEfx4Rg4fBge3DMGGjCnJZz7o5U1kMYK2JvC9lgXqsai7OIK2vwc3/lIuN4uIw==; 24:Z6nwyM7no7R+hJi387sKiewNrBy+D4h2ppBA4i6zWtSTjqXVINN2iMulGS7IZ4oEHU9lJvxkQFQErI+Uml9yg5bBu8lnY7SptQL4ROa7CP0=; 20:p05m2ax2klAmjEUoy6EwGK9zatUteJ9X2zBMglJZvRqj8POLnDk7yJbGqSY2z+fH8bDZl4WGnO6osPY1wl2yZw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425019)(601004)(2401001)(8121501046)(520078)(520075)(5005006)(3002001)(61426019)(61427019); SRVR:BN3PR0301MB1249; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249;
x-forefront-prvs: 0703B549E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(55674003)(199003)(24454002)(189002)(377454003)(19580405001)(5007970100001)(46102003)(19300405004)(106356001)(64706001)(87936001)(122556002)(86362001)(106116001)(5004730100002)(99286002)(105586002)(54356999)(92566002)(2950100001)(74316001)(19609705001)(76176999)(50986999)(5001830100001)(76576001)(33656002)(561944003)(189998001)(2900100001)(19580395003)(19625215002)(86612001)(40100003)(11100500001)(16236675004)(19617315012)(101416001)(102836002)(15975445007)(62966003)(97736004)(5005710100001)(8990500004)(10400500002)(5001770100001)(77096005)(77156002)(5001860100001)(5001960100002)(93886004)(10290500002)(68736005)(5002640100001)(4001540100001)(5003600100002)(81156007)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12490306AD3248F868D8B2B287590BN3PR0301MB1249_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2015 18:31:39.4475 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.407, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1Zd0SC-0004QY-JB 5000e3de6ecb9176060c2f1d3d679251
Subject: RE: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30221
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

We have historically had cases where customers were either legally mandated to use client certificate authentication specifically, or more generally had an IT requirement to use two-factor authentication to access enterprise resources.  I’ll research the details of some of these, and see whether I can share some details to frame this conversation in Yokohama.  Internally, we use it regularly – the certificate lives on a smartcard, the TPM, or was simply issued to the machine when it enrolled for device management.

For us, at least, the “pain” is that we can’t support a legal requirement without falling back to HTTP/1.1 and generating even more round-trips.  Our HTTP/2 investments don’t apply as soon as we’re talking to the auth server.

From: Mike Belshe []
Sent: Friday, September 18, 2015 11:20 AM
To: Mark Nottingham <>
Cc: Henry Story <>; HTTP Working Group <>
Subject: Re: Client Certificates - re-opening discussion

In a strange twist of fate I find myself doing a lot of PKI work these days, and I've considered a fair bit about how client-certs might help with some of my application-level needs.

However, just like HTTP's basic-auth, I wonder HTTP or TLS level client-certs will just never be used?  My concern, of course, is that we build something that has a user experience similar to HTTP's basic-auth.  It's so bad that nobody can use it and authentication gets pulled into web pages (where ironically, it is less secure!).

Mark - you said there is "pain".  Is there a set of use cases to be solved here?  Let me know if I missed them - I may be able to contribute.

My suspicion is that we really need crypto features moved up a level from the protocol, as it will be very difficult to make satisfactory user interfaces from the protocol level alone.  Perhaps for machine-to-machine auth it would be okay.


On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <<>> wrote:
Hi Henry,

Thanks, but this is a much more narrowly-scoped discussion -- how to make client certs as they currently operate work in HTTP/2. At most, I think we'd be talking about incrementally improving client certs (e.g., clarifying / optimising the scope of their applicability -- and that really just is an example, not a statement of intent).


> On 18 Sep 2015, at 11:53 am, Henry Story <<>> wrote:
>> On 17 Sep 2015, at 23:10, Mark Nottingham <<>> wrote:
>> Hi,
>> We've talked about client certificates in HTTP/2 (and elsewhere) for a while, but the discussion has stalled.
>> I've heard from numerous places that this is causing Pain. So, I'd like to devote a chunk of our time in Yokohama to discussing this.
>> If you have a proposal or thoughts that might become a proposal in this area, please brush it off and be prepared. Of course, we can discuss on-list in the meantime.
>> Cheers,
>> --
>> Mark Nottingham
> Apart from the proposals as the proposal by Martin Thomson
> and the follow up work  referenced earlier in this thread
> by Mike Bishop [1], I'd like to mention more HTTP centric
> prototypes which would rely perhaps not so much on certificates,
> but on linked public keys, that build on existing HTTP
> mechanisms such as WWW-Authenticate, which if they pass security
> scrutiny would fit nicely it seems to me with HTTP/2.0 .
> • Andrei Sambra's first sketch authentication protocol
> • Manu Sporny's more fully fleshed out HTTP Message signature
> These and the more TLS centric protocols require the user
> agent to be able to use public/private keys generated by
> the agent, and signed  or published by that origin, to
> authenticate or sign documents across origins.
> This is where one often runs into the Same Origin Policy (SOP)
> stone wall. There was an important discussion on
><> [1] and<>
> entitled
>   "A Somewhat Critical View of SOP (Same Origin Policy)" [2]
> that I think has helped clarify the distinction between Same Origin
> Policy, Linkability, Privacy and User Control, and which I hope
> has helped show that this policy cannot be applied without
> care nor can it apply everywhere.
> The arguments developed there should be helpful in opening discussion
> here and elswhere too I think. In a couple of e-mails  in that
> thread, I went into great detail showing how SOP, linkability and User
> Control and privacy apply in very different ways to 4 technologies:
> Cookies, FIDO, JS Crypto API and client certificates [3]. This shows
> that the concepts don't overlap, two being technical and the two
> legal/philosophical, each technology enabling some aspect of the
> other, and not always the way one would expect.
> Having made those conceptual distinctions I think the path to
> acceptance of solutions proposed by this group will be much eased.
> Looking forward to following and testing work developed here,
> All the best,
>       Henry
> [1] • starting:
>    • most recent by Mike Bishop
> [2]
> [3]
>  which is in part summarised with respect to FIDO in a much shorter
>  email
Mark Nottingham