Draft: draft-ietf-tls-exported-authenticator

Commentary: 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  messages in the OPAQUE EA flow ? Section 6 discusses the possibility of an empty  , 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 ] 
 cc
This document describes a mechanism in Transport Layer Security (TLS)
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.
This document provides a way to authenticate one party of a Transport
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.
This document describes a mechanism in Transport Layer Security (TLS)
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.
This document provides a way to authenticate one party of a Transport
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.
An authenticator message can be constructed by either the client or
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.
An authenticator message can be constructed by either the client or
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.
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.
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
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
"signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
RFC5246 for TLS 1.2.
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.
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
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
"signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
RFC5246 for TLS 1.2.
Where Hash is the authenticator hash defined in section 4.1.  If the
authenticator request is not present, it is omitted from this
construction (that is, it is zero length).
Where Hash is the authenticator hash defined in section 4.1.  If the
authenticator request is not present, it is omitted from this
construction, i.e., it is zero length.
If, given an authenticator request, the endpoint does not have an
appropriate certificate or does not want to return one, it constructs
an authenticated refusal called an empty authenticator.  This is a
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
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message is encoded as a TLS handshake message, including length and
type field.  It does not include TLS record layer framing.
If, given an authenticator request, the endpoint does not have an
appropriate identity or does not want to return one, it constructs an
authenticated refusal called an empty authenticator.  This is a
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
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message is encoded as a TLS handshake message, including length and
type field.  It does not include TLS record layer framing.
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.
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.
This property makes it difficult to formally prove that a server
is jointly authoritative over multiple certificates, rather than
individually authoritative over each.
This property makes it difficult to formally prove that a server
is jointly authoritative over multiple identities, rather than
individually authoritative over each.