Draft: draft-ietf-tls-tls13

Commentary: 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 
 this seems ready to land from my side modulo the rename I propose . Do you have any changes to make ?
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
Sent by endpoints receiving any hello message containing an
extension known to be prohibited for inclusion in the given hello
message, including any extensions in a ServerHello not first
offered in the corresponding ClientHello.
Paragraph (version B):
Sent by endpoints receiving any hello message containing an
extension known to be prohibited for inclusion in the given hello
message, including any extensions in a ServerHello or Certificate
not first offered in the corresponding ClientHello.
Paragraph (version A):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, and "No"
indicating that they are not used in TLS 1.3.  This column [shall
be/has been] initially populated with the values in this document.
Paragraph (version B):
IANA [shall update/has updated] this registry to include a "TLS
that the server shall not send them.  "Clear", indicating that
they shall be in the ServerHello.  "Encrypted", indicating that
they shall be in the EncryptedExtensions block, "Certificate"
indicating that they shall be in the Certificate block, and "No"
indicating that they are not used in TLS 1.3.  This column [shall
be/has been] initially populated with the values in this document.