Subject: Re: [httpwg/http-extensions] Remove AUTOMATIC_USE (#480)

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 21:44:05 +0000 (UTC)

martinthomson commented on this pull request.

>  ~~~
 {: #ex-http2-server-requested title="Client-Requested Certificate"}
 
-Likewise, on each stream where certificate authentication is required,
-the server sends a `CERTIFICATE_NEEDED` frame, which the client
-answers with a `USE_CERTIFICATE` frame indicating the certificate to
-use. If the request parameters or the responding certificate are not
-already available, they will need to be sent as described in
-{{cert-available}} as part of this exchange.
+A server SHOULD provide certificates for an origin before pushing resources from
+it or supplying content referencing the origin. If a client receives a
+`PUSH_PROMISE` referencing an origin for which it has not yet received the
+server's certificate, the client SHOULD verify the server's possession of an

You use a lot of "SHOULD" here, and I think that they are for the wrong reason.

In this case, you are using SHOULD to avoid having to say *why* the client might want to verify that the server has a valid certificate.  Here, you can say that the verification is mandatory.  In many other cases, you can describe what goal the endpoint might have and how it can achieve that goal.

>  ~~~
 {: #ex-http2-server-requested title="Client-Requested Certificate"}
 
-Likewise, on each stream where certificate authentication is required,
-the server sends a `CERTIFICATE_NEEDED` frame, which the client
-answers with a `USE_CERTIFICATE` frame indicating the certificate to
-use. If the request parameters or the responding certificate are not
-already available, they will need to be sent as described in
-{{cert-available}} as part of this exchange.
+A server SHOULD provide certificates for an origin before pushing resources from
+it or supplying content referencing the origin. If a client receives a
+`PUSH_PROMISE` referencing an origin for which it has not yet received the
+server's certificate, the client SHOULD verify the server's possession of an
+appropriate certificate by sending a `CERTIFICATE_NEEDED` frame on the pushed
+stream to inform the server that progress is blocked until the request is
+satisfied.
+
+If the certificate is already available, the server SHOULD immediately

lazy SHOULD: If a client requests a certificate that is already available, the server can send a `USE_CERTIFICATE` frame to signal which certificate it assumes to be effective.

>  ~~~
 {: #ex-http2-client-requested title="Reactive Certificate Authentication"}
 
-A server SHOULD provide certificates for an origin before pushing resources from
-it or supplying content referencing the origin. If a client receives a
-`PUSH_PROMISE` referencing an origin for which it has not yet received the
-server's certificate, the client MUST verify the server's possession of an
-appropriate certificate by sending a `CERTIFICATE_NEEDED` frame on the pushed
-stream to inform the server that progress is blocked until the request is
-satisfied. The client MUST NOT use the pushed resource until an appropriate
-certificate has been received and validated.
+On subsequent requests, the client can proactively indicate that an existing
+certificate MAY be used by including a `USE_CERTIFICATE` frame as part of the
+request.  If the indicated certificate does not correspond to the request the

You need to explain what ordering you expect to have here.  After the header block, but before the request body.  Which implies an empty DATA frame rather than a HEADERS frame with FIN attached.

> @@ -470,6 +486,10 @@ authentication request identifier, `Request-ID`. A peer that receives a
 error of type `PROTOCOL_ERROR`. Frames with identical request
 identifiers refer to the same `CERTIFICATE_REQUEST`.
 
+The `CERTIFICATE_NEEDED` frame MUST NOT be sent by servers prior to seeing the
+end of the client's request, and then MUST NOT be sent if the client included a

We need to be very clear about what it means to say that the request is ended, because the client won't be able to send USE_CERTIFICATE on a half-closed stream.  (Do we have an issue for that?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/480#pullrequestreview-94151032

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 05 Feb 2018 23:15:32 +0000 (UTC)

MikeBishop commented on this pull request.

Yes, #482.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/480#discussion_r166143287

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 01 Mar 2018 01:29:54 +0000 (UTC)

kazuho commented on this pull request.

Aside from the point raised by @martinthomson, I think we should allow a server to send a `CERTIFICATE_NEEDED` frame before seeing the end of the request.

As stated in https://github.com/MikeBishop/http2-certs/pull/17#discussion_r151328990, CGI (and other APIs that have been designed based on CGI) require the properties of a certificate (e.g. DN) to be sent before the request body.

Unless we allow the `CERTIFICATE_NEEDED` to be sent while the request body is being transmitted, a server will be required to buffer entire request body when it needs to enforce the use of a client certificate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/480#discussion_r171440847