Code change:
Because this draft permits certificates to be exchanged at the HTTP framing layer instead of the TLS layer, several certificate-related errors which are defined at the TLS layer might now occur at the HTTP <del> framing layer.  In this section, those errors are restated and added to the HTTP/2 error code registry. </del> <ins> framing layer. </ins> <del> A certificate was corrupt, contained signatures that did not verify correctly, etc. </del> <ins> There are two classes of errors which might be encountered, and they are handled differently. </ins> <del> A certificate was of an unsupported type or did not contain required extensions </del> <ins> 4.1. </ins> <del> A certificate was revoked by its signer </del> <ins> This category of errors could indicate a peer failing to follow restrictions in this document, or might indicate that the connection is not fully secure.  These errors are fatal to stream or connection, as appropriate. </ins> <del> A certificate has expired or is not currently valid </del> <ins> More certificates were used on a request than were requested </ins> <del> Any other certificate-related error </del> <ins> A CERTIFICATE_NEEDED frame was received by a peer which did not indicate support for this extension. </ins> <del> More certificates were used on a request than were requested </del> <ins> An exported authenticator could not be validated. 4.2. </ins> <del> As described in RFC7540, implementations MAY choose to treat a stream error as a connection error at any time.  Of particular note, a stream error cannot occur on stream 0, which means that implementations cannot send non-session errors in response to "CERTIFICATE_REQUEST", and "CERTIFICATE" frames.  Implementations which do not wish to terminate the connection MAY either send relevant errors on any stream which references the failing certificate in question or process the requests as unauthenticated and provide error information at the HTTP semantic layer. </del> <ins> Unacceptable certificates (expired, revoked, or insufficient to satisfy the request) are not treated as stream or connection errors. This is typically not an indication of a protocol failure.  Servers SHOULD process requests with the indicated certificate, likely resulting in a "4XX"-series status code in the response.  Clients SHOULD establish a new connection in an attempt to reach an authoritative server. </ins> 5.

Related discussion:
text: though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.