Secondary Certificate Authentication in HTTP/2
draft-bishop-httpbis-http2-additional-certs-05
Document | Type |
Replaced Internet-Draft
(candidate for httpbis WG)
Expired & archived
|
|
---|---|---|---|
Authors | Mike Bishop , Nick Sullivan , Martin Thomson | ||
Last updated | 2017-11-27 (Latest revision 2017-10-30) | ||
Replaces | draft-thomson-http2-client-certs | ||
Replaced by | draft-ietf-httpbis-http2-secondary-certs | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Call For Adoption By WG Issued | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-httpbis-http2-secondary-certs | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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 how TLS exported authenticators [I-D.ietf-tls-exported-authenticator] can be used to provide proof of ownership of additional certificates to the HTTP layer to support both scenarios.
Authors
Mike Bishop
Nick Sullivan
Martin Thomson
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)