From d969b48298e6faaffd6d6f0df9fa0d6854b3f736 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 15 Nov 2017 18:56:37 +0800 Subject: [PATCH 1/5] Incorporate exported authenticator requests --- draft-ietf-httpbis-http2-secondary-certs.md | 65 ++++++++++----------- 1 file changed, 31 insertions(+), 34 deletions(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 21712227a..4d531a8f2 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -520,10 +520,7 @@ necessary frames have been received on stream zero MUST also result in a stream error of type `PROTOCOL_ERROR`. The referenced certificate chain MUST conform to the requirements expressed in -the `CERTIFICATE_REQUEST` to the best of the sender's ability. Specifically, if -the `CERTIFICATE_REQUEST` contained a non-empty `Cert-Extensions` element, the -end-entity certificate MUST match with regard to the extensions recognized by -the sender. +the `CERTIFICATE_REQUEST` to the best of the sender's ability. If these requirements are not satisfied, the recipient MAY at its discretion either return an error at the HTTP semantic layer, or respond with a stream @@ -532,11 +529,10 @@ defines certificate-related error codes which might be applicable. ## The CERTIFICATE_REQUEST Frame {#http-cert-request} -TLS 1.3 defines the `CertificateRequest` message, which prompts the client to -provide a certificate which conforms to certain properties specified by the -server. This draft defines the `CERTIFICATE_REQUEST` frame (0xFRAME-TBD2), -which uses the same set of extensions to specify a desired certificate, but -can be sent over any TLS version and can be sent by either peer. +The `CERTIFICATE_REQUEST` frame (id=0xFRAME-TBD2) provides a exported +authenticator request message from the TLS layer that specifies a desired +certificate. This describes the certificate the sender wishes to have +presented. The `CERTIFICATE_REQUEST` frame SHOULD NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. @@ -549,9 +545,7 @@ stream error of type `PROTOCOL_ERROR`. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ - | Request-ID (16) | Extension-Count (16) | - +-------------------------------+-------------------------------+ - | Extensions(?) ... + | Request-ID (16) | Request (?) ... +---------------------------------------------------------------+ ~~~~~~~~~~~~~~~ {: #fig-cert-request title="CERTIFICATE_REQUEST frame payload"} @@ -563,20 +557,22 @@ Request-ID: certificate-related frames with this request. The identifier MUST be unique in the session for the sender. -Extension-Count and Extensions: -: A list of certificate selection criteria, represented in a series of - `Extension` structures (see [I-D.ietf-tls-tls13] section 4.2). This criteria - MUST be used in certificate selection as described in {{I-D.ietf-tls-tls13}}. - The number of `Extension` structures is given by the 16-bit `Extension-Count` - field, which MAY be zero. +Request: +: An exported authenticator request, generated using the `request` API described + in [I-D.ietf-tls-exported-authenticator]. See {{exp-auth}} for more details on + the input to this API. + +### Exported Authenticator Request Characteristics {#exp-req} -Some extensions used for certificate selection allow multiple values (e.g. -oid_filters on Extended Key Usage). If the sender has included a non-empty -Extensions list, the certificate MUST match all criteria specified by extensions -the recipient recognizes. However, the recipient MUST ignore and skip any -unrecognized certificate selection extensions. +The Exported Authenticator `request` API defined in +[I-D.ietf-tls-exported-authenticator] takes as input a set of desired +certificate characteristics and a `certificate_request_context`. When generating +exported authenticators for use with this extension, the +`certificate_request_context` MUST be the two-octet Cert-ID. -Servers MUST be able to recognize the `server_name` extension ([RFC6066]) at a +The TLS library on the authenticating peer will provide mechanisms to select an +appropriate certificate to respond to the transported request. TLS libraries on +servers MUST be able to recognize the `server_name` extension ([RFC6066]) at a minimum. Clients MUST always specify the desired origin using this extension, though other extensions MAY also be included. @@ -640,16 +636,17 @@ received on any other stream MUST be rejected with a stream error of type ### Exported Authenticator Characteristics {#exp-auth} The Exported Authenticator API defined in [I-D.ietf-tls-exported-authenticator] -takes as input a certificate, supporting information about the certificate -(OCSP, SCT, etc.), and an optional `certificate_request_context`. When -generating exported authenticators for use with this extension, the -`certificate_request_context` MUST be the two-octet Cert-ID. - -Upon receipt of a completed authenticator, an endpoint MUST check that: - - - the `validate` API confirms the validity of the authenticator itself - - the `certificate_request_context` matches the Cert-ID of the frame(s) in - which it was received +takes as input a request, a set of certificates, and supporting information +about the certificate (OCSP, SCT, etc.). + +Upon receipt of a completed authenticator, an endpoint MUST perform the +following steps: + - Using the `get context` API, retrieve the `certificate_request_context` used + to generate the authenticator, if any. + - Verify that the `certificate_request_context` is one previously generated or, + when processed by a client, is absent. + - Use the `validate` API to confirm the validity of the authenticator with + regard to the generated request. Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. From 42f69c806671885e80c191e101d1a2821d6cd31c Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 15 Nov 2017 19:27:32 +0800 Subject: [PATCH 2/5] Partially address Nick's comments --- draft-ietf-httpbis-http2-secondary-certs.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 4d531a8f2..987e1b940 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -568,7 +568,7 @@ The Exported Authenticator `request` API defined in [I-D.ietf-tls-exported-authenticator] takes as input a set of desired certificate characteristics and a `certificate_request_context`. When generating exported authenticators for use with this extension, the -`certificate_request_context` MUST be the two-octet Cert-ID. +`certificate_request_context` MUST be the two-octet Request-ID. The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request. TLS libraries on @@ -643,10 +643,11 @@ Upon receipt of a completed authenticator, an endpoint MUST perform the following steps: - Using the `get context` API, retrieve the `certificate_request_context` used to generate the authenticator, if any. - - Verify that the `certificate_request_context` is one previously generated or, - when processed by a client, is absent. + - Verify that the `certificate_request_context` is the Request-ID of a + previously-sent `CERTIFICATE_REQUEST` frame. Alternatively, on clients the + `certificate_request_context` MAY also be empty. - Use the `validate` API to confirm the validity of the authenticator with - regard to the generated request. + regard to the generated request (if any). Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. From c6e13064908d915e428d56fdcd0630c83cd4f4b4 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 5 Feb 2018 14:15:11 -0800 Subject: [PATCH 3/5] Martin's feedback; fixes #483 --- draft-ietf-httpbis-http2-secondary-certs.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 987e1b940..5c1c45893 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -66,7 +66,7 @@ scenarios. --- note_Note_to_Readers -Discussion of this draft takes place on the HTTP working group mailing list +Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; source @@ -566,9 +566,10 @@ Request: The Exported Authenticator `request` API defined in [I-D.ietf-tls-exported-authenticator] takes as input a set of desired -certificate characteristics and a `certificate_request_context`. When generating -exported authenticators for use with this extension, the -`certificate_request_context` MUST be the two-octet Request-ID. +certificate characteristics and a `certificate_request_context`, which needs to +be unpredictable. When generating exported authenticators for use with this +extension, the `certificate_request_context` MUST be the two-octet Request-ID, +followed by at least six random octets. The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request. TLS libraries on @@ -637,15 +638,15 @@ received on any other stream MUST be rejected with a stream error of type The Exported Authenticator API defined in [I-D.ietf-tls-exported-authenticator] takes as input a request, a set of certificates, and supporting information -about the certificate (OCSP, SCT, etc.). +about the certificate (OCSP, SCT, etc.). The result is an opaque token which is +used when generating the `CERTIFICATE` frame. -Upon receipt of a completed authenticator, an endpoint MUST perform the -following steps: +Upon receipt of a `CERTIFICATE` frame, an endpoint MUST perform the following +steps to validate the token it contains: - Using the `get context` API, retrieve the `certificate_request_context` used to generate the authenticator, if any. - - Verify that the `certificate_request_context` is the Request-ID of a - previously-sent `CERTIFICATE_REQUEST` frame. Alternatively, on clients the - `certificate_request_context` MAY also be empty. + - Verify that the `certificate_request_context` is either empty (clients only) + or the Request-ID of a previously-sent `CERTIFICATE_REQUEST` frame. - Use the `validate` API to confirm the validity of the authenticator with regard to the generated request (if any). From b42dc03ca17e590388b824f6d27f6461f0b84045 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 5 Feb 2018 15:57:25 -0800 Subject: [PATCH 4/5] More feedback from @martinthomson --- draft-ietf-httpbis-http2-secondary-certs.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-httpbis-http2-secondary-certs.md b/draft-ietf-httpbis-http2-secondary-certs.md index 5c1c45893..237e890e1 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -519,13 +519,13 @@ preceding `CERTIFICATE` frame. Receipt of a `USE_CERTIFICATE` frame before the necessary frames have been received on stream zero MUST also result in a stream error of type `PROTOCOL_ERROR`. -The referenced certificate chain MUST conform to the requirements expressed in -the `CERTIFICATE_REQUEST` to the best of the sender's ability. - -If these requirements are not satisfied, the recipient MAY at its discretion -either return an error at the HTTP semantic layer, or respond with a stream -error {{RFC7540}} on any stream where the certificate is used. {{errors}} -defines certificate-related error codes which might be applicable. +The referenced certificate chain needs to conform to the requirements expressed +in the `CERTIFICATE_REQUEST` to the best of the sender's ability, or the +recipient is likely to reject it as unsuitable despite properly validating the +authenticator. If the recipicent considers the certificate unsuitable, it MAY +at its discretion either return an error at the HTTP semantic layer, or respond +with a stream error {{RFC7540}} on any stream where the certificate is used. +{{errors}} defines certificate-related error codes which might be applicable. ## The CERTIFICATE_REQUEST Frame {#http-cert-request} @@ -568,8 +568,8 @@ The Exported Authenticator `request` API defined in [I-D.ietf-tls-exported-authenticator] takes as input a set of desired certificate characteristics and a `certificate_request_context`, which needs to be unpredictable. When generating exported authenticators for use with this -extension, the `certificate_request_context` MUST be the two-octet Request-ID, -followed by at least six random octets. +extension, the `certificate_request_context` MUST contain both the two-octet +Request-ID as well as at least 96 bits of additional entropy. The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request. TLS libraries on @@ -646,7 +646,7 @@ steps to validate the token it contains: - Using the `get context` API, retrieve the `certificate_request_context` used to generate the authenticator, if any. - Verify that the `certificate_request_context` is either empty (clients only) - or the Request-ID of a previously-sent `CERTIFICATE_REQUEST` frame. + or contains the Request-ID of a previously-sent `CERTIFICATE_REQUEST` frame. - Use the `validate` API to confirm the validity of the authenticator with regard to the generated request (if any). From 9cfbb2c2dfb5d8453191b2e664e9e6c46b1e4f6d Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 5 Feb 2018 16:03:43 -0800 Subject: [PATCH 5/5] Typo --- 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 237e890e1..10148b407 100644 --- a/draft-ietf-httpbis-http2-secondary-certs.md +++ b/draft-ietf-httpbis-http2-secondary-certs.md @@ -522,7 +522,7 @@ error of type `PROTOCOL_ERROR`. The referenced certificate chain needs to conform to the requirements expressed in the `CERTIFICATE_REQUEST` to the best of the sender's ability, or the recipient is likely to reject it as unsuitable despite properly validating the -authenticator. If the recipicent considers the certificate unsuitable, it MAY +authenticator. If the recipient considers the certificate unsuitable, it MAY at its discretion either return an error at the HTTP semantic layer, or respond with a stream error {{RFC7540}} on any stream where the certificate is used. {{errors}} defines certificate-related error codes which might be applicable.