From d2c772029aed536cd4c6640d16257a6df7c8f9e4 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 9 Apr 2018 13:32:30 -0700 Subject: [PATCH 1/2] Abstracts are small --- draft-ietf-httpbis-http2-secondary-certs.md | 30 ++++++++------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 929139e1d..901f41558 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -45,24 +45,10 @@ informative: --- 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 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 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 can be used to provide -proof of ownership of additional certificates to the HTTP layer to support both -scenarios. +A use of TLS Exported Authenticators is described which enables HTTP/2 clients +and servers to offer additional certificate-based credentials after the +connection is established. The means by which these credentials are used with +requests is defined. --- note_Note_to_Readers @@ -80,7 +66,7 @@ code and issues list for this draft can be found at HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from. The traditional form of -server authentication in HTTP has been in the form of X.509 certificates +server authentication in HTTP has been in the form of the single X.509 certificate provided during the TLS [RFC5246][I-D.ietf-tls-tls13] handshake. Many existing HTTP [RFC7230] servers also have authentication requirements for @@ -93,6 +79,12 @@ TLS 1.2 [RFC5246] supports one server and one client certificate on a connection. These certificates may contain multiple identities, but only one certificate may be provided. +Many HTTP servers host content from several origins. HTTP/2 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 handshake. In many cases, +servers choose to maintain separate certificates for different origins but +still desire the benefits of a shared HTTP connection. + ## Server Certificate Authentication Section 9.1.1 of [RFC7540] describes how connections may be used to make From 85db40982524c37386eb24525f2c7752fac21d94 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 13 Apr 2018 10:13:38 -0700 Subject: [PATCH 2/2] a single --- draft-ietf-httpbis-http2-secondary-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 901f41558..d95c9d2ea 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -66,7 +66,7 @@ code and issues list for this draft can be found at HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from. The traditional form of -server authentication in HTTP has been in the form of the single X.509 certificate +server authentication in HTTP has been in the form of a single X.509 certificate provided during the TLS [RFC5246][I-D.ietf-tls-tls13] handshake. Many existing HTTP [RFC7230] servers also have authentication requirements for