Draft: draft-ietf-tls-exported-authenticator

Commentary: A reference QUIC would also need to be 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 :  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   ! 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 .  : 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 .
An authenticator request message can be constructed by either the
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.
An authenticator request message can be constructed by either the
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.
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 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.
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.
The authenticator is a structured message that can be exported from
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
TLS as its underlying transport to keep the certificate confidential.
The application MAY use the existing TLS connection to transport the
authenticator.
The authenticator is a structured message that can be exported from
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
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
authenticator.
It returns an authenticator request, which is a sequence of octets
that comprises a CertificateRequest message.
It returns an authenticator request, which is a sequence of octets
that comprises a CertificateRequest or ClientCertificateRequest
message.