Original text:
case of server authentication), this field SHALL be zero length. This is a sequence (chain) of CertificateEntry structures, each <del> 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. </del>  A set of extension values for the CertificateEntry.  The "Extension" format is defined in extensions.  Valid extensions applies to the entire chain, it SHOULD be included in the first CertificateEntry.  Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility.  Servers sometimes TLS version, with the exception of the end-entity certificate which MUST be first.  The server's certificate_list MUST always be non-empty.  A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's

Reviewer comments:
Explicitly define RFC 7250 certificate support.
Seems reasonable. (I did not try to audit the rest of the text to see if there are other places that need updating.)
This captures what we talked about in Chicago.
Shucks, this hasn't landed yet, so I'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions.

Revised text:
case of server authentication), this field SHALL be zero length. This is a sequence (chain) of CertificateEntry structures, each  <ins> containing a single certificate and set of extensions. </ins> A set of extension values for the CertificateEntry.  The "Extension" format is defined in extensions.  Valid extensions applies to the entire chain, it SHOULD be included in the first CertificateEntry. <ins> If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  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. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility.  Servers sometimes TLS version, with the exception of the end-entity certificate which MUST be first. <ins> If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which contains an ASN1_subjectPublicKeyInfo value as defined in RFC7250, Section 3. </ins> The server's certificate_list MUST always be non-empty.  A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's