Draft: draft-ietf-tls-exported-authenticator

Commentary: There are lots of changes here . I did stage this as separate commits to some extent , so feel free to cherry - pick . There is one maybe - technical change here . It was n't clear about the precedence between handshake and authenticator request for extensions . I 've chosen to be clear about this and say that if the authenticator request exists , then it is the only thing that matters . That 's . I can drop that from the CL and do that separately if you prefer . 
 Thanks for the comments . The technical clarification you made is the correct one , the request supersedes the handshake for extension choices if present .
This message is used to define the parameters in a request for an
authenticator.
This message is used to provide explicit proof that an endpoint
possesses the private key corresponding to its certificate.
The algorithm field specifies the signature algorithm used (see
Section 4.2.3 of TLS13 for the definition of this field).  The
signature is a digital signature using that algorithm.  The signature
scheme MUST be a valid signature scheme for TLS 1.3.  This excludes
all RSASSA-PKCS1-v1_5 algorithms and ECDSA algorithms that are not
supported in TLS 1.3.  If an authenticator request is present, the
signature algorithm MUST be chosen from one of the signature schemes
in the authenticator request.  Otherwise, the signature algorithm
used should be chosen from the "signature_algorithms" extension of
the ClientHello used in the connection handshake.
An authenticator is formed from the concatenation of TLS 1.3 TLS13
Certificate, CertificateVerify, and Finished messages.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  If there is no authenticator request, the extensions are
chosen from the TLS handshake.  That is, the extensions received in a
ClientHello (for servers), ServerHello (for clients in TLS 1.2), or
EncryptedExtensions (for clients in TLS 1.3).
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 MUST be valid for the a
signature algorithm indicated by the peer in a "signature_algorithms"
extension, as described in Section 4.2.3 of TLS13 and Sections 7.4.2
and 7.4.6 of RFC5246.
In addition to "signature_algorithms", the "server_name" RFC6066,
"certificate_authorities" (Section 4.2.4. of TLS13), or "oid_filters"
(Section 4.2.5. of TLS13) extensions are used to guide certificate
selection.  These extensions are taken from the authenticator request
if present, or the TLS handshake if not.
Alternative certificate formats such as RFC7250 Raw Public Keys are
not supported in this version of the specification.
If an authenticator request was provided, the Certificate message
MUST contain only extensions present in the authenticator request.
Otherwise, the Certificate message MUST contain only extensions
present in the TLS handshake.
The algorithm field specifies the signature algorithm used (see
Section 4.2.3 of TLS13 for the definition of this field).  The
signature is a digital signature using that algorithm.
The signature scheme MUST be a valid signature scheme for TLS 1.3.
This excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of
ECDSA and hash algorithms that are not supported in TLS 1.3.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes in the authenticator
request.  Otherwise, the signature algorithm used should be chosen
from the "signature_algorithms" extension sent by the peer in the TLS
handshake.
where Hash is the hash function for the handshake.
A HMAC over the value Hash(Handshake Context || Certificate ||
CertificateVerify) if an authenticator is present, or
Hash(Handshake Context || authenticator request || Certificate ||
CertificateVerify) where Hash is the hash function for the
handshake, and the HMAC is computed using the hash function from
the handshake and the Finished MAC Key as a key.
The certificates chosen in the Certificate message MUST conform to
the requirements of a Certificate message in the version of TLS
negotiated.  If an authenticator request is present, the signature
algorithms used to choose the algorithm are taken from the
"signature_algorithms" in the from the authenticator.  If there is no
authenticator request, the signature algorithms are chosen from the
"signature_algorithms" extension from the ClientHello used in the
connection.  This is described in Section 4.2.3 of TLS13 and Sections
RFC7250 Raw Public Keys are not supported.  The "server_name"
RFC6066, "certificate_authorities" (Section 4.2.4. of TLS13), or
"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide
certificate selection, with the extensions provided in the
authenticator request taking precedence over the extensions provided
in the connection handshake.
If an authenticator request was provided, the Certificate message
MUST contain only extensions present in the authenticator request.
Otherwise, the Certificate message MUST contain only extensions
present in the ClientHello.
Where Hash is the hash function negotiated by TLS.  If the
authenticator request is not present, it is omitted from this
construction (that is, it is zero length).
The HMAC is computed using the same hash function using the Finished
MAC Key as a key.
The following sections describes APIs that are considered necessary
to implement exported authenticators.  These are informative only.
It returns the exported authenticator as output.  It is RECOMMENDED
that the logic for selecting the certificates and extensions to
include in the exporter is implemented in the TLS library.
Implementing this in the TLS library lets the implementer take
advantage of existing extension and certificate selection logic.
It returns the exported authenticator as a sequence of octets.  It is
RECOMMENDED that the logic for selecting the certificates and
extensions to include in the exporter is implemented in the TLS
library.  Implementing this in the TLS library lets the implementer
take advantage of existing extension and certificate selection logic.