New Version Notification for draft-bishop-httpbis-http2-additional-certs-01.txt

Mike Bishop <Michael.Bishop@microsoft.com> Tue, 17 May 2016 18:52 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96C712DC9C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 May 2016 11:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.436
X-Spam-Level:
X-Spam-Status: No, score=-8.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 newyHSVtyHT2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 May 2016 11:52:46 -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 7A74312DD0F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 17 May 2016 11:52:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1b2k2b-0003sT-B4 for ietf-http-wg-dist@listhub.w3.org; Tue, 17 May 2016 18:48:25 +0000
Resent-Date: Tue, 17 May 2016 18:48:25 +0000
Resent-Message-Id: <E1b2k2b-0003sT-B4@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 <Michael.Bishop@microsoft.com>) id 1b2k2S-0003oQ-MV for ietf-http-wg@listhub.w3.org; Tue, 17 May 2016 18:48:16 +0000
Received: from mail-bl2on0112.outbound.protection.outlook.com ([65.55.169.112] helo=na01-bl2-obe.outbound.protection.outlook.com) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1b2k2Q-0001qi-GD for ietf-http-wg@w3.org; Tue, 17 May 2016 18:48:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U9JxUxRV+bS28FAch6J0jJgT0r5RxotBGTwLGW1EDFY=; b=NyeEbJCeWsh1mi/xiyvzFwG/cGmVWMqJuDmrNxKIP3b/ofImLsI8YMGLI7qTtu/1UF1CfK8JZFLjETrCXwbjN3pI3efQ35HxsQUcZsMUSjYdQeq0GAkNERgKGV89I8fEVT3+kTS3lO1GQjhyxu8LzztvbzYnLgp1F6qvV4PwBVY=
Received: from BL2PR03MB1905.namprd03.prod.outlook.com (10.164.115.25) by BL2PR03MB1907.namprd03.prod.outlook.com (10.164.115.27) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 17 May 2016 18:47:47 +0000
Received: from BL2PR03MB1905.namprd03.prod.outlook.com ([10.164.115.25]) by BL2PR03MB1905.namprd03.prod.outlook.com ([10.164.115.25]) with mapi id 15.01.0492.020; Tue, 17 May 2016 18:47:46 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: Martin Thomson <martin.thomson@gmail.com>, Nick Sullivan <nick@cloudflare.com>
Thread-Topic: New Version Notification for draft-bishop-httpbis-http2-additional-certs-01.txt
Thread-Index: AQHRsGqMTdiRlSAZbEmKiYihJ5YIxJ+9dG+Q
Date: Tue, 17 May 2016 18:47:46 +0000
Message-ID: <BL2PR03MB1905F4053776F97911440B6787480@BL2PR03MB1905.namprd03.prod.outlook.com>
References: <20160517183302.24832.67842.idtracker@ietfa.amsl.com>
In-Reply-To: <20160517183302.24832.67842.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: w3.org; dkim=none (message not signed) header.d=none;w3.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8::16c]
x-ms-office365-filtering-correlation-id: 822b2e72-630c-42a4-423b-08d37e83bd22
x-microsoft-exchange-diagnostics: 1; BL2PR03MB1907; 5:DYGOU9ZexPvyV5ipqrD2l3XzIh6c/UFWx7bnAdoVNnSYaO7CaT6H0ff0jp5pkQFm5O1MjXs/rXM3TRR9yWtw7g1xNowBcWg0x8LNqvHOJhG49IjFulaKiVPmefZHZAvZJW4r6wAYKOT75b60IA8Qtw==; 24:GmWbE9DJuAMpQwEz7ywypaDQg/BlDfuJ2aUtmR5YrkGtrYUZJR38AUlymgUUzdaF76mJPw8sIBKIaUviw1JJnH8+I3vZCwFRu1Bco+qgZZY=; 7:zSZsKltWaNw8pNUZbB9GHR9RKRo4/tXGglIYA2qHtRqwlBkaDNOLgvgZ9U6HXMi0tGdpmWZ07RxQOaXQS/ftV20u6a97pc3LNRf60HVW01Jy3bZqjEPsX46FdnisouyH6AGU5kQdDQ5JmpMD49VK1SEd39rfCyQPzuVtCRW99fyse3HQQ3C7OOJ6AaZ2i2f/u0w2DEiFxaLkJmFIW16r1Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB1907;
x-microsoft-antispam-prvs: <BL2PR03MB19074D2F6D92689CA45917D787480@BL2PR03MB1907.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BL2PR03MB1907; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB1907;
x-forefront-prvs: 0945B0CC72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(377454003)(377424004)(74316001)(86362001)(230783001)(8936002)(5005710100001)(8990500004)(5008740100001)(10290500002)(10400500002)(2950100001)(33656002)(106116001)(2900100001)(81166006)(19625215002)(19580405001)(189998001)(15650500001)(19300405004)(7110500001)(9686002)(2906002)(10710500007)(77096005)(76576001)(15975445007)(8676002)(76176999)(19580395003)(10090500001)(586003)(54356999)(92566002)(50986999)(6116002)(122556002)(790700001)(102836003)(229853001)(19617315012)(16236675004)(4326007)(110136002)(5003600100002)(86612001)(1220700001)(2420400007)(87936001)(5004730100002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB1907; H:BL2PR03MB1905.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL2PR03MB1905F4053776F97911440B6787480BL2PR03MB1905namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 18:47:46.6295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB1907
Received-SPF: pass client-ip=65.55.169.112; envelope-from=Michael.Bishop@microsoft.com; helo=na01-bl2-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.441, 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: lisa.w3.org 1b2k2Q-0001qi-GD 36de630015d20e961b0e462470f5b2b8
X-Original-To: ietf-http-wg@w3.org
Subject: New Version Notification for draft-bishop-httpbis-http2-additional-certs-01.txt
Archived-At: <http://www.w3.org/mid/BL2PR03MB1905F4053776F97911440B6787480@BL2PR03MB1905.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31646
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>

Per the consensus in Buenos Aires, Martin and I have been working on merging the client-cert draft and the additional-server-cert drafts to a bidirectional method for either peer on an HTTP/2 connection to present/require certificates at the HTTP/2 framing layer before proceeding.



Key changes from what we saw in B-A:

·         Exchanges work the same in both directions – that means clients send a CERTIFICATE_REQUIRED before making a request if they’re blocking requests waiting on a particular certificate.

·         Unsolicited presentation of certificates is permitted (though the recipient isn’t required to consume them) to enable the server to offer certificates as soon as it can speak (“0.5 RTT data” in TLS 1.3)

·         Supported signature types carried in SETTINGS to support proffers of certificates

·         CERTIFICATE frame now includes a Supplemental-Data section – we’re currently envisioning this for bundling SCT and OCSP, though Nick has proposed making this even more flexible.  Added a registry so we can add more data types later (e.g. DNSSec records)



GitHub repo for this is at https://github.com/MikeBishop/http2-client-certs.  Discussion and issues welcome.



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, May 17, 2016 11:33 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>; Martin Thomson <martin.thomson@gmail.com>
Subject: New Version Notification for draft-bishop-httpbis-http2-additional-certs-01.txt





A new version of I-D, draft-bishop-httpbis-http2-additional-certs-01.txt

has been successfully submitted by Mike Bishop and posted to the IETF repository.



Name:                  draft-bishop-httpbis-http2-additional-certs

Revision:              01

Title:                      Secondary Certificate Authentication in HTTP/2

Document date:               2016-05-17

Group:                  Individual Submission

Pages:                   27

URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-01.txt

Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/

Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01

Diff:           https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additional-certs-01



Abstract:

   TLS provides fundamental mutual authentication services for HTTP,

   supporting up to one server certificate and up to one client

   certificate associated to the session to prove client and server

   identities as necessary.  This draft provides mechanisms for

   providing additional such certificates at the HTTP layer when these

   constraints are not sufficient.



   Many HTTP servers host content from several origins.  HTTP/2

   [RFC7540] permits clients to reuse an existing HTTP connection to a

   server provided that the secondary origin is also in the certificate

   provided during the TLS [I-D.ietf-tls-tls13] handshake.



   In many cases, servers will wish to maintain separate certificates

   for different origins but still desire the benefits of a shared HTTP

   connection.  Similarly, servers may require clients to present

   authentication, but have different requirements based on the content

   the client is attempting to access.



   This document describes a how such certificates can be provided at

   the HTTP layer to support both scenarios.









Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat