Draft: draft-ietf-tls-exported-authenticator

Commentary: Request for review ,
This document describes a mechanism in Transport Layer Security (TLS)
to provide an exportable proof of ownership of a certificate that can
be transmitted out of band and verified by the peer.
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.
For simplicity, the mechanisms described in this document require TLS
(or DTLS) version 1.2 or later.
TLS (or DTLS) version 1.2 or later are REQUIRED to implement the
mechanisms described in this document.
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.
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.  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.
Exported Authenticators MUST NOT be generated or accepted on
connectons not using the extended master secret RFC7627 extension, to
avoid key synchronization attacks.
To avoid key synchronization attacks, Exported Authenticators MUST
NOT be generated or accepted on TLS 1.2 connectons that did not
negotiate the extended master secret RFC7627.
If the peer creating the certificate_request_context has already
created or correctly validated an authenticator with the same value,
then no authenticator should be constructed.  If there is no
authenticator request, the extensions are chosen from the TLS
handshake.  Only servers can provide an authenticator without a
corresponding request.
If the peer creating the certificate_request_context has already
created or correctly validated an authenticator with the same value,
then no authenticator should be constructed.  If there is no
authenticator request, the extensions are chosen from those presented
in the TLS handshake's ClientHello.  Only servers can provide an
authenticator without a corresponding request.
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 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 HMAC is computed using the authenticator hash, using the Finished
MAC Key as a key.
A HMAC HMAC over the hashed authenticator transcript, which is the
concatenated Handshake Context, authenticator request (if present),
Certificate, and CertificateVerify.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.
The HMAC is computed using the authenticator hash, using the Finished
MAC Key as a key.  This message does not include any TLS framing.
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 does not include any TLS 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 MUST
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 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.