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

And per Issue #1, the GitHub repo is now

From: Mike Bishop []
Sent: Tuesday, May 17, 2016 11:48 AM
To: HTTP Working Group <>
Cc: Martin Thomson <>; Nick Sullivan <>
Subject: New Version Notification for draft-bishop-httpbis-http2-additional-certs-01.txt

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  Discussion and issues welcome.

-----Original Message-----
From:<> []
Sent: Tuesday, May 17, 2016 11:33 AM
To: Mike Bishop <<>>; Martin Thomson <<>>
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






   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

The IETF Secretariat

Received on Tuesday, 17 May 2016 21:20:53 UTC