Original text:
authenticator. An authenticator request message can be constructed by either the <del> client or the server.  This authenticator request uses the CertificateRequest message structure from Section 4.3.2 of TLS13, even if the TLS connection protocol is TLS 1.2.  The CertificateRequest is used to define the parameters in a request for an authenticator.  This message does not include any TLS framing and is not encrypted with a handshake key. </del>  <del> The uniqueness requirements of the certificate_request_context apply only to CertificateRequest messages that are used as part of authenticator requests.  There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message.  The structure is defined to be: </del>  An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A temporary access to the peer's private key from pre-computing valid authenticators. <del> The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in Section 4.2. of TLS13 and the server_name RFC6066 extension, which is allowed for client-generated authenticator requests. </del>  5. either party of a TLS connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use <del> TLS as its underlying transport to keep the certificate confidential. The application MAY use the existing TLS connection to transport the </del>  authenticator. An authenticator message can be constructed by either the client or signature_algorithms) It returns an authenticator request, which is a sequence of octets <del> that comprises a CertificateRequest message. </del>  7.2.

Reviewer comments:
A reference QUIC would also need to be added to the references section If it's an informative draft maybe not a thing, but if it's a normative reference then this draft will sit in the queue until QUIC transport gets published. Maybe that's okay, but just an FYI.
I may be missing some follow-on discussions, but: Ben suggested that we mention that QUIC is also an option, even if informatively, in addition to the “SHOULD use TLS” statement. I think we left my question re: back-fitting this protocol into the IANA TLS registry open. Quoting: YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allowing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. NS: This is a good point and one that we struggled a bit with during design. We needed to allow SNI in the CertificateRequest message because it can be client-generated in this context. I'd be ok with creating a different extension for this, but it's rather elegant to re-use it in this context. I'd like to hear some opinions from the working group on this point BK: Or, since extension codepoints are cheap, just use a new codepoint.
Addressed by .

Revised text:
authenticator. An authenticator request message can be constructed by either the  <ins> client or the server.  Server-generated authenticator requests use the CertificateRequest message from Section 4.3.2 of TLS13.  Client- generated authenticator requests use a new message, called the ClientCertificateRequest, which uses the same structure as CertificateRequest.  These messages structures are used even if the TLS connection protocol is TLS 1.2. </ins>  <ins> The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These messages do not include any TLS framing and are not encrypted with a handshake key. The structures are defined to be: </ins> An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A temporary access to the peer's private key from pre-computing valid authenticators.  <ins> The set of extensions allowed in the CertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column.  The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column, along with the server_name RFC6066 extension. The uniqueness requirements of the certificate_request_context apply only to CertificateRequest and ClientCertificateRequest messages that are used as part of authenticator requests.  There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message. </ins> 5. either party of a TLS connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use  <ins> TLS or a protocol with comparable security properties as its underlying transport to keep the certificate confidential.  The application MAY use the existing TLS connection to transport the </ins> authenticator. An authenticator message can be constructed by either the client or signature_algorithms) It returns an authenticator request, which is a sequence of octets  <ins> that comprises a CertificateRequest or ClientCertificateRequest message. </ins> 7.2.