Re: Client Certificates - re-opening discussion

"" <> Fri, 18 September 2015 16:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F3F51A0015 for <>; Fri, 18 Sep 2015 09:01:18 -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 5xLxtlkbfYxM for <>; Fri, 18 Sep 2015 09:01:16 -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 AAEE11A03A1 for <>; Fri, 18 Sep 2015 09:01:16 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zcy2W-0003VY-IK for; Fri, 18 Sep 2015 15:57:32 +0000
Resent-Date: Fri, 18 Sep 2015 15:57:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zcy2O-0003Uh-H3 for; Fri, 18 Sep 2015 15:57:24 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zcy2L-0003Ig-V4 for; Fri, 18 Sep 2015 15:57:24 +0000
Received: by wicgb1 with SMTP id gb1so38338401wic.1 for <>; Fri, 18 Sep 2015 08:56:55 -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=YJKMhTjaWHBhYrfyORLn8aa5VSq5NiPIWhpep3kKJp8=; b=eDhtYGaVR4rwqiB/M708h2y/AezVypKPra3boME66kny47m8cIkrNQqlOh6Cai6XBQ EbmmACqmtVkiJRZq90vcQQP9QXle1VvWuZvF7PewVOpRzjXtXsrc4NOEk07tGvcfQiFo 9WNRLUQs98v3SgYWeXp5r2DdWB7w0Jn1IveRNpPTI1G8AhXAzEY0dWiBOOp7acudcgsi E6MfFbvtRJ5lqOpS5665GuaXMuMemOrpiPfY04yLJYTRrMYI1piPdLaYnumnc/GygBgM VkCj8OazLAWhMo7auo2MqkWE++YdEgyHsWTDDGeLl1U+90wMmLdcOmiobUsqF9KEz7eN swiA==
X-Gm-Message-State: ALoCoQkwjR6kJb4ne+ad3I73qXe5uwFDHuBlA8tE8FnaHClIc2LRUct/64o1cciMEsvTYfW8yqY9
X-Received: by with SMTP id e7mr17121704wiy.19.1442591815196; Fri, 18 Sep 2015 08:56:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id wc12sm3541127wic.18.2015. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Sep 2015 08:56:54 -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: Fri, 18 Sep 2015 16:56:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
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: 1Zcy2L-0003Ig-V4 83afdd968f8c1b5786f17497d91472eb
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30214
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> 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 

  "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,


[1] • starting:
     • most recent by Mike Bishop
 which is in part summarised with respect to FIDO in a much shorter

Social Web Architect