Re: Client Certificates - re-opening discussion

Jason Greene <jason.greene@redhat.com> Mon, 21 September 2015 17:54 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37A1ACDB9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Sep 2015 10:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwpfueKqCR2S for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Sep 2015 10:54:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D7F1A916D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 21 Sep 2015 10:54:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ze5G0-0006Kw-UF for ietf-http-wg-dist@listhub.w3.org; Mon, 21 Sep 2015 17:52:04 +0000
Resent-Date: Mon, 21 Sep 2015 17:52:04 +0000
Resent-Message-Id: <E1Ze5G0-0006Kw-UF@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <jason.greene@redhat.com>) id 1Ze5Fv-0006KA-Ps for ietf-http-wg@listhub.w3.org; Mon, 21 Sep 2015 17:51:59 +0000
Received: from mx1.redhat.com ([209.132.183.28]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <jason.greene@redhat.com>) id 1Ze5Ft-0004tQ-Qb for ietf-http-wg@w3.org; Mon, 21 Sep 2015 17:51:58 +0000
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A95862589E; Mon, 21 Sep 2015 17:51:33 +0000 (UTC)
Received: from [10.3.225.1] (vpn-225-1.phx2.redhat.com [10.3.225.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8LHpUrM031298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2015 13:51:32 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B109476-26EF-4E7C-AC07-C30B4F377481"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jason Greene <jason.greene@redhat.com>
In-Reply-To: <CABaLYCs7qM92GNMrfHUG+e4eWv8H-Hhk6oYv3cBFnsDSP=DFRQ@mail.gmail.com>
Date: Mon, 21 Sep 2015 12:51:30 -0500
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Mark Nottingham <mnot@mnot.net>, Henry Story <henry.story@co-operating.systems>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8A87F40B-DD3B-4274-A692-4C87F364C3D4@redhat.com>
References: <63DECDF0-AB59-4AFD-8E48-8C2526FD6047@mnot.net> <42DDF1C6-F516-4F71-BAE0-C801AD13AA01@co-operating.systems> <2F3BD1CB-042D-48AB-8046-BB8506B8E035@mnot.net> <CABaLYCtZ_EAGKaW0ydcYoKSJjyv6=YXdLrry2LQyVTzcC_qt_w@mail.gmail.com> <BN3PR0301MB12490306AD3248F868D8B2B287590@BN3PR0301MB1249.namprd03.prod.outlook.com> <CABaLYCs7qM92GNMrfHUG+e4eWv8H-Hhk6oYv3cBFnsDSP=DFRQ@mail.gmail.com>
To: Mike Belshe <mike@belshe.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Received-SPF: pass client-ip=209.132.183.28; envelope-from=jason.greene@redhat.com; helo=mx1.redhat.com
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.027, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=0.001, SPF_HELO_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1Ze5Ft-0004tQ-Qb 45838dbc9653081794e7dbceaac38558
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <http://www.w3.org/mid/8A87F40B-DD3B-4274-A692-4C87F364C3D4@redhat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30252
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Sep 21, 2015, at 10:22 AM, Mike Belshe <mike@belshe.com> wrote:
> 
> 
> 
> On Fri, Sep 18, 2015 at 11:31 AM, Mike Bishop <Michael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>> wrote:
> 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.
> 
> 
> Thanks, this sounds about right.  The usability of browser-based client-auth was so awful, that unless "mandated" by some law, no real user or website would use it :-)  If anyone on this thread hasn't tried client auth, you should, and then imagine turning that on for any real website.

Hmm I always thought it was fairly straight-forward. Although the thing is, the major use-case for client certs is provisioned authorized equipment. So the end-user of the browser typically doesn’t interact with it at all.

> 
> I hope the legal requirement doesn't require that client auth be done in the HTTP protocol layer, just that the certificate based auth be done.  My own opinion is that HTTP/1.1/TLS's client auth was a mistake, and my evidence is the usability of both client-auth and basic-auth authentication schemes at the protocol layer.  Neither is used in significant amounts.  The latter was definitely moved by millions of websites into the application layer, and I see no reason why browsers shouldn't offer support for client-auth like primitives which will help customers move certificate-based client auth up a level too.

How does this help the usability of the browser? It seems to me that however you do it, the overall management of client certificates in the browser is roughly the same. You have to have a mapping of site to cert stored somewhere.

-Jason