Change:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?

Discussion:
skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. <del> 4.2.8. RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in EncryptedExtensions.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Note: This means that the certificate status appears prior to the certificates it applies to.  This is slightly anomalous but matches the existing behavior for SignedCertificateTimestamps RFC6962, and is more easily extensible in the handshake state machine. </del> 4.3. The next two messages from the server, EncryptedExtensions and

of certificate_request_context in that message.  Otherwise, in the case of server authentication this field SHALL be zero length. <del> This is a sequence (chain) of certificates.  The sender's certificate MUST come first in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> This is a sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. A set of extension values for the CertificateEntry.  The "Extension" format is defined in hello-extensions.  Valid extensions include OCSP Status extensions (RFC6066 and RFC6961) and SignedCertificateTimestamps (RFC6962).  Any extension presented in a Certificate message must only be presented if the corresponding ClientHello extension was presented in the initial handshake.  If an extension applies the the entire chain, it SHOULD be included in the first CertificateEntry. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it, however some

4.4.1.1. <ins> RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the assoiciated certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Similarly, RFC6962 provides a mechanism for a server to send a Signed Certificate Timestamp (SCT) as an extension in the ServerHello.  In TLS 1.3, the server's SCT information is carried in an extension in CertificateEntry. 4.4.1.2. </ins> The following rules apply to the certificates sent by the server: The certificate type MUST be X.509v3 RFC5280, unless explicitly

on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences). <del> 4.4.1.2. </del> <ins> 4.4.1.3. </ins> The following rules apply to certificates sent by the client:

that use algorithm combinations that cannot be currently used with TLS. <del> 4.4.1.3. </del> <ins> 4.4.1.4. </ins> In general, detailed certificate validation procedures are out of scope for TLS (see RFC5280).  This section provides TLS-specific

Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello <del> message, including any extensions in a ServerHello not first offered in the corresponding ClientHello. </del> <ins> message, including any extensions in a ServerHello or Certificate not first offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension

1.3" column with the following four values: "Client", indicating that the server shall not send them.  "Clear", indicating that they shall be in the ServerHello.  "Encrypted", indicating that <del> they shall be in the EncryptedExtensions block, and "No" </del> <ins> they shall be in the EncryptedExtensions block, "Certificate" indicating that they shall be in the Certificate block, and "No" </ins> indicating that they are not used in TLS 1.3.  This column [shall be/has been] initially populated with the values in this document.