Stream-linking frames can reference Stream Zero

draft-ietf-httpbis-http2-secondary-certs.md

@@ -377,9 +377,10 @@ Client                                      Server
 
 Likewise, either party can supply a `CERTIFICATE_REQUEST` that outlines
 parameters of a certificate they might request in the future.  Upon receipt of a
-`CERTIFICATE_REQUEST`, servers SHOULD provide a corresponding certificate.
-Clients MAY wait for a `CERTIFICATE_NEEDED` frame to assist in associating the
-certificate request with a particular HTTP transition.
+`CERTIFICATE_REQUEST`, endpoints SHOULD provide a corresponding certificate in
+anticipation of a request shortly being blocked. Clients MAY wait for a
+`CERTIFICATE_NEEDED` frame to assist in associating the certificate request with
+a particular HTTP transaction.
 
 ## Requiring certificate authentication {#cert-challenge}
 
@@ -394,19 +395,26 @@ the connection.
 If the TLS certificate does not contain the new origin, but the server has
 claimed support for that origin (with an ORIGIN frame, see {{?RFC8336}}) and
 advertised support for HTTP-layer certificates (see {{setting}}), the client MAY
-send a `CERTIFICATE_REQUEST` frame describing the desired origin.  Servers
-SHOULD provide a corresponding certificate if one is available.
-
-If the server does not have the desired certificate, it MUST \[see issue #564].
-In this case, or if the server has not advertised support for HTTP-layer
-certificates, the client MUST NOT send any requests for resources in that origin
-on the current connection.
+send a `CERTIFICATE_REQUEST` frame describing the desired origin.  The client
+then sends a `CERTIFICATE_NEEDED` frame for stream zero referencing the request,
+indicating that the connection cannot be used for that origin until the
+certificate is provided.
+
+If the server does not have the desired certificate, it MUST send an Empty
+Authenticator, as described in Section 5 of
+[I-D.ietf-tls-exported-authenticator], in a `CERTIFICATE` frame in response to
+the request, followed by a `USE_CERTIFICATE` frame for stream zero which
+references the Empty Authenticator.  In this case, or if the server has not
+advertised support for HTTP-layer certificates, the client MUST NOT send any
+requests for resources in that origin on the current connection.
 
 ~~~ drawing
 Client                                      Server
    <----------------------- (stream 0) ORIGIN --
    -- (stream 0) CERTIFICATE_REQUEST ---------->
+   -- (stream 0) CERTIFICATE_NEEDED (S=0) ----->
    <------------------ (stream 0) CERTIFICATE --
+   <-------- (stream 0) USE_CERTIFICATE (S=0) --
    -- (stream N) GET /from-new-origin --------->
    <----------------------- (stream N) 200 OK --
 ~~~
@@ -509,7 +517,9 @@ required certificate). To reduce the risk of client confusion, servers SHOULD
 NOT have multiple outstanding `CERTIFICATE_NEEDED` frames for the same stream at
 any given time.
 
-Clients MUST NOT send multiple `CERTIFICATE_NEEDED` frames for the same stream.
+Clients MUST only send multiple `CERTIFICATE_NEEDED` frames for stream zero.
+Multiple `CERTIFICATE_NEEDED` frames on any other stream MUST be considered
+a stream error of type `PROTOCOL_ERROR`.
 
 The `CERTIFICATE_NEEDED` frame MUST NOT be sent to a peer which has not
 advertised support for HTTP-layer certificate authentication.
@@ -872,6 +882,8 @@ this document.
 
 ## Since draft-ietf-httpbis-http2-secondary-certs-01:
 
+- Clients can send `CERTIFICATE_NEEDED` for stream 0 rather than speculatively
+  reserving a stream for an origin.
 - Use SETTINGS to disable when a TLS-terminating proxy is present (#617,#651)
 
 ## Since draft-ietf-httpbis-http2-secondary-certs-00: