Original text:
Abstract This document describes a mechanism in Transport Layer Security (TLS) <del> for peers to provide a proof of ownership of a certificate.  This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. </del>  1. This document provides a way to authenticate one party of a Transport <del> Layer Security (TLS) connection to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </del>  This mechanism provides two advantages over the authentication that TLS natively provides: party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use TLS or a protocol with comparable security properties as its <del> underlying transport to keep the certificate confidential.  The </del>  application MAY use the existing TLS connection to transport the authenticator. An authenticator message can be constructed by either the client or <del> the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server. </del>  5.1. 5.2.1. <del> The Certificate message contains the certificate to be used for authentication and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </del>  <del> The certificate message contains an opaque string called </del>  certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer. <del> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS.  In particular, the certificate chain MUST be valid for the a </del>  signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of TLS13 for TLS 1.3 or the 5.2.2. This message is used to provide explicit proof that an endpoint <del> possesses the private key corresponding to its certificate.  The </del>  definition for TLS 1.3 is: The algorithm field specifies the signature algorithm used (see Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this <del> construction (that is, it is zero length). </del>  If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the 6. If, given an authenticator request, the endpoint does not have an <del> appropriate certificate or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is a </del>  Finished message sent without a Certificate or CertificateVerify. This message is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the a reference to an active connection <del> a set of certificate chains and associated extensions (OCSP, SCT, etc.) </del>  <del> a signer (either the private key associated with the certificate, or interface to perform private key operations) for each chain </del>  an authenticator request or certificate_request_context (from 0 to 255 bytes) an authenticator <del> It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not.  If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Well-formed empty authenticators are returned as valid. </del>  8. certificate_request_context. This property makes it difficult to formally prove that a server <del> is jointly authoritative over multiple certificates, rather than </del>  individually authoritative over each. There is no indication in the TLS layer about which point in time

Reviewer comments:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME

Revised text:
Abstract This document describes a mechanism in Transport Layer Security (TLS)  <ins> for peers to provide a proof of ownership of an identity, such as an X509 certificate.  This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. </ins> 1. This document provides a way to authenticate one party of a Transport  <ins> Layer Security (TLS) connection to its peer using a Certificate message after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </ins> This mechanism provides two advantages over the authentication that TLS natively provides: party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use TLS or a protocol with comparable security properties as its  <ins> underlying transport to keep the Certificate confidential.  The </ins> application MAY use the existing TLS connection to transport the authenticator. An authenticator message can be constructed by either the client or  <ins> the server given an established TLS connection, an identity, such as an X509 certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server. </ins> 5.1. 5.2.1.  <ins> The Certificate message contains the identity to be used for authentication, such as the end-entity certificate and any supporting certificates in the chain.  This structure is defined in TLS13, Section 4.4.2. </ins>  <ins> The Certificate message contains an opaque string called </ins> certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer.  <ins> Certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS.  In particular, the certificate chain MUST be valid for the a </ins> signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of TLS13 for TLS 1.3 or the 5.2.2. This message is used to provide explicit proof that an endpoint  <ins> possesses the private key corresponding to its identity.  The </ins> definition for TLS 1.3 is: The algorithm field specifies the signature algorithm used (see Where Hash is the authenticator hash defined in section 4.1.  If the authenticator request is not present, it is omitted from this  <ins> construction, i.e., it is zero length. </ins> If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the 6. If, given an authenticator request, the endpoint does not have an  <ins> appropriate identity or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is a </ins> Finished message sent without a Certificate or CertificateVerify. This message is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the a reference to an active connection  <ins> an identity, such as a set of certificate chains and associated extensions (OCSP, SCT, etc.) </ins>  <ins> a signer (either the private key associated with the identity, or interface to perform private key operations) for each chain </ins> an authenticator request or certificate_request_context (from 0 to 255 bytes) an authenticator  <ins> It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is valid or not.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator.  Well-formed empty authenticators are returned as valid. </ins> 8. certificate_request_context. This property makes it difficult to formally prove that a server  <ins> is jointly authoritative over multiple identities, rather than </ins> individually authoritative over each. There is no indication in the TLS layer about which point in time