FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-02.txt

Kudos to Nick for pulling much of these mechanics into a TLS draft instead; this update (changes also by Nick) deletes the pieces that were delegated to TLS and replaces them with references his draft.

The issue of getting an exporter larger than the HTTP/2 frame size is likely back in this version, and something we'll need to iron out.  However, I like the general direction of keeping the crypto in TLS where at all possible.

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Monday, October 31, 2016 4:49 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>; Martin Thomson <martin.thomson@gmail.com>
Subject: New Version Notification for draft-bishop-httpbis-http2-additional-certs-02.txt


A new version of I-D, draft-bishop-httpbis-http2-additional-certs-02.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:  draft-bishop-httpbis-http2-additional-certs
Revision: 02
Title:  Secondary Certificate Authentication in HTTP/2
Document date: 2016-10-31
Group:  Individual Submission
Pages:  21
URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-02.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-02

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


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 TLS exported authenticators [I-D.draft-
   sullivan-tls-exported-authenticator] can be used to provide proof of
   ownership of additional certificates to 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

Received on Tuesday, 1 November 2016 00:01:36 UTC